FR3105682A1 - Procede et systeme de gestion d’echange de donnees dans le cadre d’un examen medical - Google Patents

Procede et systeme de gestion d’echange de donnees dans le cadre d’un examen medical Download PDF

Info

Publication number
FR3105682A1
FR3105682A1 FR1915204A FR1915204A FR3105682A1 FR 3105682 A1 FR3105682 A1 FR 3105682A1 FR 1915204 A FR1915204 A FR 1915204A FR 1915204 A FR1915204 A FR 1915204A FR 3105682 A1 FR3105682 A1 FR 3105682A1
Authority
FR
France
Prior art keywords
terminal
probe
platform
key
message
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.)
Granted
Application number
FR1915204A
Other languages
English (en)
Other versions
FR3105682B1 (fr
Inventor
Claude Cohen-Bacrie
Adrien BESSON
Frederic WINTZENRIETH
Luc Bertrand
Eric GUIFFARD
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.)
E Scopics
Original Assignee
E Scopics
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
Priority to FR1915204A priority Critical patent/FR3105682B1/fr
Application filed by E Scopics filed Critical E Scopics
Priority to US17/786,195 priority patent/US20230016828A1/en
Priority to EP20829945.3A priority patent/EP4079018A1/fr
Priority to PCT/EP2020/087458 priority patent/WO2021123431A1/fr
Priority to CN202080094825.8A priority patent/CN115136545B/zh
Priority to JP2022538167A priority patent/JP2023507651A/ja
Priority to KR1020227024603A priority patent/KR20220134751A/ko
Publication of FR3105682A1 publication Critical patent/FR3105682A1/fr
Application granted granted Critical
Publication of FR3105682B1 publication Critical patent/FR3105682B1/fr
Priority to IL294053A priority patent/IL294053A/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/06Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823Network architectures or network communication protocols for network security for authentication of entities using certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/009Security arrangements; Authentication; Protecting privacy or anonymity specially adapted for networks, e.g. wireless sensor networks, ad-hoc networks, RFID networks or cloud networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03Protecting confidentiality, e.g. by encryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041Key generation or derivation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • H04W12/069Authentication using certificates or pre-shared keys
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/50Secure pairing of devices

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Biomedical Technology (AREA)
  • Public Health (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Primary Health Care (AREA)
  • General Business, Economics & Management (AREA)
  • Business, Economics & Management (AREA)
  • Power Engineering (AREA)
  • Storage Device Security (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Ultra Sonic Daignosis Equipment (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L’invention concerne un procédé de gestion des échanges de données durant une procédure d’examen médical d’un patient, le procédé permettant la gestion des échanges de données entre : une sonde (1) d’acquisition de données, un terminal (2) apte à communiquer avec la sonde par l’intermédiaire de moyens de communication avec ou sans fil, une plateforme (3) distante apte à communiquer avec le terminal par l’intermédiaire d’un réseau informatique tel qu’Internet, remarquable en ce que le procédé comprend, préalablement à la mise en œuvre de la procédure d’examen, la mise en œuvre d’une procédure d’authentification dans laquelle une clé de session générée par la plateforme pour le chiffrement symétrique des données échangées est transmise à la sonde et au terminal, alors que la clé de séquence est connue uniquement de la sonde (1) et de la plateforme (3). Figure à publier avec l’abrégé : Fig. 1

Description

PROCEDE ET SYSTEME DE GESTION D’ECHANGE DE DONNEES DANS LE CADRE D’UN EXAMEN MEDICAL
DOMAINE DE L'INVENTION
La présente invention concerne le domaine technique général de la sécurité des services.
En particulier, la présente invention concerne un procédé permettant :
  • l’authentification d’entités échangeant des données – par exemple des données de nature médicale et/ou des données de commande et/ou des données de contrôle – dans un réseau de communication, et
  • le chiffrement des données échangées afin de garantir d’une part leur confidentialité et d’autre part leur fiabilité.
L'invention concerne également un système d’authentification et de chiffrement associé.
Plus précisément, l’invention concerne une application avancée des solutions d’acquisition et de transfert de données : l’échographie dématérialisée.
ARRIERE PLAN DE L'INVENTION
L’imagerie par ultrasons est utilisée dans de nombreuses procédures de diagnostic en raison de sa nature non invasive, de son coût relativement bas et de l’absence d’exposition du patient à des rayonnements ionisants nocifs.
Depuis quelques années, de nouvelles solutions d’échographie dites « ultra-portables » ont été développées dans lesquelles des données acquises par une sonde – et éventuellement traitées – sont transmises sur une plateforme de stockage et/ou de traitement distante – connue sous le nom de « cloud » – en utilisant un réseau de communication – tel que le réseau Internet.
En effet, le cloud permet de mutualiser les structures de conservation et de traitement des données, et dispose d’une puissance de calcul très importante.
Toutefois, la transmission de données – données médicales acquises, données médicales traitées, données système représentatives de données de commande/contrôle de la sonde etc. – par l'intermédiaire d’un réseau informatique (tel qu’Internet) pose le problème crucial de l'intégrité, de l'authenticité et de l'inviolabilité de ces données, afin d'assurer:
  • l’intégrité des données système : par exemple les instructions de pilotage de la sonde ne doivent pas pouvoir être modifiées par un tiers malveillant afin d’éliminer les risques sur la santé du patient,
  • la confidentialité des données médicales qui ne doivent pas être accessibles par un tiers malveillant : seul le personnel autorisé (médecin, etc.) doit avoir accès à ces données médicales, et
  • la fiabilité des données médicales : toutes les composantes (i.e. données acquises, données traitées, mesures, etc.) de l’examen doivent être cohérentes (par exemple des données médicales d’un examen précédent ne doivent pas interférer avec les données médicales d’un examen en cours / toutes les données médicales acquises d’un examen en cours doivent être traitées / etc.).
Un but de la présente invention est de proposer un procédé et un système permettant de réaliser un examen échographique en situation de mobilité et intégrant une solution aux problèmes d’intégrité, de fiabilité et de confidentialité précités liés à l'échange de données par l'intermédiaire d’un réseau informatique tel qu’Internet.
BREVE DESCRIPTION DE L'INVENTION
A cet effet, l’invention concerne un procédé de gestion des échanges de données durant une procédure d’examen médical d’un patient, le procédé permettant la gestion des échanges de données entre : une sonde d’acquisition de données, un terminal apte à communiquer avec la sonde par l’intermédiaire de moyens de communication avec ou sans fil, une plateforme distante apte à communiquer avec le terminal par l’intermédiaire d’un réseau informatique tel qu’Internet, remarquable en ce que le procédé comprend, préalablement à la mise en œuvre de la procédure d’examen, la mise en œuvre d’une procédure d’authentification dans laquelle :
  • une clé de session générée par la plateforme est transmise à la sonde et au terminal, ladite clé de session permettant le chiffrement/déchiffrement symétrique de données de session échangées entre la sonde, le terminal et la plateforme durant la procédure d’examen médical, et
  • une clé de séquence générée par la plateforme est transmise à la sonde, ladite clé de séquence permettant le chiffrement/déchiffrement symétrique de données de séquence échangées entre la plateforme et la sonde durant la procédure d’examen médical.
Dans le cadre de la présente invention, les données de session échangées peuvent consister en :
  • des données système incluant :
    • des données de commande (i.e. instructions de pilotage) de la sonde et/ou du terminal et/ou de la plateforme, et/ou
    • des données de contrôle de la sonde et/ou du terminal et/ou de la plateforme ;
  • des données médicales incluant :
    • des données médicales acquises (et/ou prétraitées) par la sonde, et/ou
    • des données médicales traitées par le terminal et/ou la plateforme distante.
Ces données de session peuvent être chiffrées/déchiffrées par la sonde ou le terminal ou la plateforme distante. L’information contenue dans ces données de session est donc accessible par les trois entités du système.
Dans le cadre de la présente invention, les données de séquence peuvent consister en :
  • des données de commande (i.e. instructions de pilotage) générées par la plateforme, et permettant de définir un paramétrage de la sonde en fonction du type d’examen à réaliser,
  • des données de contrôle (généralement) générées par la sonde et destinées à être transmises à la plateforme (pour permettre un suivi ultérieur des paramètres d’acquisition de données, etc.).
Ces données de séquence ne peuvent être chiffrées/déchiffrées que par la sonde ou la plateforme distante. Ainsi, le terminal n’est pas adapté pour extraire l’information contenue dans ces données de séquence. Le terminal peut être utilisé pour stocker ces données de séquence chiffrées (la capacité de stockage de la sonde étant limitée) avant leur transfert vers la sonde ou la plateforme, mais ne peut pas accéder à l’information contenue dans ces données de séquence. Le fait que la clé de séquence soit uniquement connue de la sonde et de la plateforme permet de garantir l’intégrité des données pilotant la dépose d’énergie ultrasonore aux tissus biologiques du patient.
Des aspects préférés, mais non limitatifs de l’invention sont les suivants :
  • la procédure d’authentification peut comprendre une première phase d’échange entre le terminal et la plateforme par l’intermédiaire du réseau informatique, ladite première phase comportant :
    • l’émission par le terminal d’une requête d’examen vers la plateforme,
    • l’émission par la plateforme d’un message de réponse vers le terminal, le message de réponse incluant :
      • des données accessibles au terminal, et
      • des informations de vérification accessibles uniquement par la sonde, les informations de vérification étant chiffrées par chiffrement asymétrique en utilisant une clé publique de sonde, et incluant :
        • la clé de session et
        • la clé de séquence (pour un échange sécurisé des données de séquence entre la plateforme et la sonde);
  • l’étape d’émission d’une requête d’examen vers la plateforme peut comprendre une sous-étape consistant à chiffrer asymétriquement la requête en utilisant une clé publique de plateforme, le procédé comprenant en outre une étape de réception par la plateforme de la requête chiffrée, ladite étape de réception incluant une sous-étape consistant à déchiffrer la requête chiffrée en utilisant une clé privée de plateforme ;
  • l’étape d’émission par la plateforme d’un message de réponse peut comprendre une sous-étape consistant à chiffrer asymétriquement le message de réponse en utilisant une clé publique de terminal, le procédé comprenant en outre une étape de réception par le terminal du message de réponse chiffré, ladite étape de réception incluant :
    • une sous-étape consistant à déchiffrer le message de réponse chiffré en utilisant une clé privée de terminal, et
    • éventuellement, une sous-étape consistant à stocker en mémoire les informations de vérification chiffrées contenues dans le message de réponse ;
  • la requête d’examen peut comprendre un identifiant de sonde associé à la sonde et un identifiant de terminal associé au terminal, l’étape d’émission du message de réponse comprenant les sous-étapes consistant à :
    • rechercher dans une table de sonde la clé publique de sonde à partir de l’identifiant de sonde,
    • rechercher dans une table de terminal la clé publique de terminal à partir de l’identifiant de terminal,
    • générer la clé de session, et la clé de séquence,
    • intégrer la clé de session, la clé de séquence, la clé publique de terminal et l’identifiant de terminal aux informations de vérification, et
    • chiffrer asymétriquement les informations de vérification en utilisant la clé publique de sonde ;
  • la procédure d’authentification peut comprendre une deuxième phase d’échange entre la sonde et le terminal par l’intermédiaire des moyens de communication avec ou sans fil, ladite deuxième phase incluant :
    • l’émission par le terminal d’un message de transfert vers la sonde, le message de transfert comportant :
      • une demande d’appairage à la sonde pour permettre l’échange de données médicales entre la sonde et le terminal,
      • les informations de vérification chiffrées par chiffrement asymétrique en utilisant la clé publique de sonde,
    • l’émission par la sonde d’un message de contrôle vers le terminal, le message de contrôle comprenant la clé de session chiffrée par chiffrement asymétrique en utilisant une clé publique de terminal ;
  • l’étape d’émission d’un message de transfert vers la sonde peut comprendre une sous-étape consistant à chiffrer asymétriquement le message de transfert en utilisant une clé publique de sonde, le procédé comprenant en outre une étape de réception par la sonde du message de transfert chiffré, ladite étape de réception incluant une sous-étape consistant à déchiffrer le message de transfert chiffré en utilisant une clé privée de sonde ;
  • avantageusement :
    • la demande d’appairage peut comprendre l’identifiant du terminal renseigné par le terminal, et
    • les informations de vérification peuvent comprendre l’identifiant du terminal renseigné par la plateforme,
l’étape de réception par la sonde du message de transfert incluant, postérieurement à l’étape consistant à déchiffrer le message de transfert, les sous-étapes consistant à :
  • déchiffrer les informations de vérification en utilisant la clé privée de sonde,
  • extraire, des informations de vérification déchiffrées, l’identifiant de terminal renseigné par la plateforme,
  • extraire, de la demande d’appairage, l’identifiant de terminal renseigné par le terminal,
  • comparer l’identifiant de terminal renseigné par la plateforme et l’identifiant de terminal renseigné par le terminal,
  • émettre une alarme si les identifiants de terminal sont différents,
  • passer à l’étape d’émission d’un message de contrôle sinon ;
  • la deuxième phase peut comprendre en outre une étape de réception par le terminal du message de contrôle, ladite étape de réception incluant :
    • une sous-étape consistant à déchiffrer la clé de session chiffrée en utilisant une clé privée de terminal, et
    • une sous-étape consistant à extraire du message de contrôle la clé de session ;
  • la deuxième phase peut comprendre en outre une étape d’émission par le terminal vers la sonde, d’un message de confirmation incluant la clé de session, ledit message de confirmation étant chiffré par chiffrement asymétrique en utilisant une clé publique de sonde ;
  • la deuxième phase peut comprendre en outre une étape de réception du message de confirmation par la sonde, ladite étape de réception incluant les sous-étapes consistant à :
    • déchiffrer le message de confirmation en utilisant une clé privée de sonde,
    • extraire la clé de session du message de confirmation et la comparer à la clé de session contenue dans les informations de vérification,
    • émettre une alarme si la clé de session du message de confirmation est différente de la clé de session contenue dans les informations de vérification,
    • émettre un message de validation vers le terminal sinon, pour permettre la mise en œuvre de la procédure d’examen.
L’invention concerne également un système pour l’échange de données lors d’une procédure d’examen d’un patient, le système comprenant : une sonde d’acquisition de données, un terminal apte à communiquer avec la sonde par l’intermédiaire de moyens de communication avec ou sans fil, une plateforme distante apte à communiquer avec le terminal par l’intermédiaire d’un réseau informatique tel qu’Internet, remarquable en ce que la sonde, le terminal et la plateforme comprennent des moyens pour la mise en œuvre d’une procédure d’authentification (préalablement à la mise en œuvre de la procédure d’examen) dans laquelle une clé de session et une clé de séquence sont générées par la plateforme :
  • la clé de session étant transmise à la sonde et au terminal durant la procédure d’authentification, et permettant le chiffrement/déchiffrement symétrique de données de session échangées entre la sonde, le terminal et la plateforme durant la procédure d’examen,
  • la clé de séquence étant transmise à la sonde durant la procédure d’authentification, et permettant le chiffrement/déchiffrement de données de séquence échangées entre la sonde et la plateforme durant la procédure d’examen .
Avantageusement, la sonde, le terminal et la plateforme comprennent des moyens pour la mise en œuvre des phases, étapes et sous-étapes du procédé de gestion défini ci-dessus.
L’invention concerne également une sonde d’acquisition de données médicales lors d’une procédure d’examen d’un patient, ladite sonde étant apte à communiquer avec un terminal par l’intermédiaire de moyens de communication avec ou sans fil, ledit terminal étant apte à communiquer avec une plateforme distante par l’intermédiaire d’un réseau informatique tel qu’Internet, remarquable en ce que la sonde comprend des moyens pour la mise en œuvre d’une procédure d’authentification (préalablement à la mise en œuvre de la procédure d’examen) dans laquelle une clé de session et une clé de séquence sont générées par la plateforme :
  • la clé de session étant transmise à la sonde et au terminal durant la procédure d’authentification et permettant le chiffrement/déchiffrement symétrique de données de session échangées entre la sonde, le terminal et la plateforme durant la procédure d’examen,
  • la clé de séquence étant transmise à la sonde durant la procédure d’authentification, et permettant le chiffrement/déchiffrement de données de séquence échangées entre la sonde et la plateforme durant la procédure d’examen.
L’invention concerne également un terminal apte, lors d’une procédure d’examen d’un patient, à communiquer avec : une sonde d’acquisition de données médicales par l’intermédiaire de moyens de communication avec ou sans fil, et avec une plateforme distante par l’intermédiaire d’un réseau informatique tel qu’Internet, remarquable en ce que le terminal comprend des moyens pour la mise en œuvre d’une procédure d’authentification, préalablement à la mise en œuvre de la procédure d’examen, dans laquelle une clé de session et une clé de séquence sont générées par la plateforme :
  • la clé de session étant transmise à la sonde et au terminal durant la procédure d’authentification, et permettant le chiffrement/déchiffrement symétrique de données de session échangées entre le terminal, la sonde et la plateforme durant la procédure d’examen,
  • la clé de séquence étant transmise à la sonde durant la procédure d’authentification, et permettant le chiffrement/déchiffrement symétrique de données de séquence échangées entre la sonde et la plateforme durant la procédure d’examen.
L’invention concerne également une plateforme distante pour le traitement et/ou le stockage de données lors d’une procédure d’examen médical d’un patient, ladite plateforme étant apte à communiquer avec un terminal par l’intermédiaire d’un réseau informatique tel qu’Internet, ledit terminal étant apte à communiquer avec une sonde d’acquisition de données médicales par l’intermédiaire de moyens de communication avec ou sans fil, remarquable en ce que la plateforme comprend des moyens pour la mise en œuvre d’une procédure d’authentification, préalablement à la mise en œuvre de la procédure d’examen, dans laquelle une clé de session et une clé de séquence sont générées par la plateforme :
  • la clé de session étant transmise à la sonde et au terminal durant la procédure d’authentification, et permettant le chiffrement/déchiffrement symétrique de données de session échangées entre la sonde, le terminal et la plateforme durant la procédure d’examen,
  • la clé de séquence étant transmise (uniquement) à la sonde durant la procédure d’authentification, et permettant le chiffrement/déchiffrement symétrique de données de séquence échangées entre la sonde et la plateforme durant la procédure d’examen.
D'autres caractéristiques, buts et avantages de la présente invention ressortiront encore de la description qui suit, laquelle est purement illustrative et non limitative et doit être lue en regard des dessins annexés, sur lesquels :
est une représentation schématique d’un système pour l’échange de données (i.e. données de commande, données de contrôle et/ou données de nature médicale) lors d’une procédure d’examen d’un patient,
est une représentation schématique d’une première phase d’échange entre un terminal et une plateforme, ladite première phase étant mise en œuvre lors d’une procédure d’authentification,
est une représentation schématique d’une deuxième phase d’échange entre une sonde et le terminal, la deuxième phase étant mise en œuvre lors de la procédure d’authentification.
DESCRIPTION DETAILLEE DE L'INVENTION
1. Généralités
1.1. Chiffrement
L’invention décrite dans la suite utilise la technique de cryptographie des données qui permet à une entité émettrice, de chiffrer les données transmises de sorte que seule une entité réceptrice authentique puisse déchiffrer ces données afin de les interpréter.
De façon connue, on distingue la cryptographie symétrique, où une même clé secrète sert à chiffrer et déchiffrer les données échangées, et la cryptographie asymétrique, où un couple de clés distinctes – dites« clé publique »et« clé privée »– sont utilisées.
La cryptographie symétrique est adaptée pour un dialogue au sein d'un couple émetteur/récepteur unique avec confiance réciproque car l'émetteur et le récepteur partagent secrètement la même clé. La cryptographie asymétrique est mieux adaptée pour établir un dialogue avec de nombreux intervenants potentiels.
Dans le cadre de la présente invention, le procédé et le système décrits dans la suite sont basés sur la technique de cryptographie asymétrique qui est mieux adaptée aux besoins de l’application visée. En effet, comme il ressortira dans la suite, l’invention met en œuvre des échanges de données entre au moins trois entités distinctes, l’authenticité de l’une de ces entités devant être validée par les deux autres entités préalablement à l’échange de toute donnée.
Pour mémoire, il est rappelé à titre indicatif que lorsque la clé privée est détenue par l’entité réceptrice, tout système émetteur peut chiffrer une donnée au moyen de la clé publique et la transmettre à l’entité réceptrice : seule l’entité réceptrice peut déchiffrer la donnée au moyen de la clé privée. Ceci assure la confidentialité du document transmis.
A l’inverse, lorsque la clé privée est détenue par l’entité émettrice, elle est la seule à pouvoir chiffrer la donnée. Toute entité réceptrice peut déchiffrer la donnée à l’aide de la clé publique : ceci avec l’assurance que l’entité émettrice qui a transmis la donnée est celle qui possède la clé privée.
1. 2. Architecture matérielle
En référence à la figure 1, on a illustré un exemple de système dans lequel le procédé d’authentification décrit dans la suite peut être mis en œuvre préalablement à l’échange de données entre les différentes entités du système.
Le système comprend trois entités séparées :
  • une sonde d’acquisition 1,
  • un terminal 2 local connecté à la sonde par des moyens de communication avec ou sans fil, et
  • une plateforme 3 distante connectée au terminal 2 par l’intermédiaire d’un réseau informatique tel qu’Internet.
1.2.1. Sonde
La sonde 1 permet l’enregistrement de données médicales représentatives d’une région d’intérêt d’un patient (structures internes, organe, etc.).
La sonde 1 est par exemple une sonde échographique incluant :
  • une pluralité de transducteurs ultrasonores pour l’émission d’ondes ultrasonores, la réception d’échos ultrasonores et la conversion des échos ultrasonores reçus en signaux électriques formant les données,
  • un calculateur pour l’éventuel prétraitement des données,
  • une unité de communication (avec ou sans fil) pour l’émission des données acquises vers le terminal externe.
Le traitement des données acquises par la sonde 1 permet l’extraction d’informations relatives au patient et/ou l’affichage d’une image de la région d’intérêt, etc.
1.2.2. Terminal
Le terminal 2 permet l’éventuel traitement de certaines données médicales acquises par la sonde 1 et/ou l’affichage d’images de la région d’intérêt.
Le terminal 2 est par exemple un terminal mobile tel qu’un téléphone portable notamment de type Smartphone, un assistant personnel (ou« PDA », sigle de l’expression anglo-saxonne« Personal Digital Assistant »), ou tout type de terminal mobile connu de l’homme du métier, tel qu’une montre connectée de type Apple Watch®.
En variante, le terminal 2 peut être un terminal virtuel, c’est-à-dire une émulation d’un terminal mobile physique. Dans le cadre de la présente invention, le terme« terminal virtuel »englobe toute ressource virtualisée, et/ou une partie d'une entité réelle. Par exemple, le terminal virtuel peut être un programme d’ordinateur, une machine virtuelle, une instance implémentées dans un environnement de« cloud computing », un sous-système d'appareil physique tel qu’un écran d’affichage, etc.
Outre l’éventuel traitement de données acquises par la sonde 1 et/ou l’affichage de la région d’intérêt, le terminal 2 permet le transfert :
  • des données émises par la sonde (données médicales, données de contrôle, etc.) vers la plateforme 3 et le transfert
  • de données émises par la plateforme 3 (données de commande, etc.) vers la sonde 1.
Les échanges de données entre le terminal 2 et la plateforme 3 sont mis en œuvre en utilisant un réseau informatique tel qu’Internet.
1.2.3. Plateforme distante
La plateforme 3 permet :
  • la mise en œuvre de traitements nécessitant une puissance de calcul dépassant les capacités du terminal 2, et/ou
  • le stockage des données reçues (données médicales, données de contrôle, etc.), et/ou
  • le pilotage de la sonde 1 en lui transmettant des instructions de commande par l’intermédiaire du terminal 2.
La plateforme 3 comprend une unité de traitement comportant par exemple un/des ordinateur(s), un/des micro-ordinateur(s), une/des stations de travail, et/ou d'autres dispositifs connus de l’homme du métier incluant un/des processeur(s), un/des microcontrôleur(s), un/des automate(s) programmable(s), un/des circuit(s) intégré(s) spécifique(s) d'application, et/ou d'autres circuits programmables.
La plateforme 3 comprend également une unité de stockage comportant une (ou plusieurs) mémoire(s) qui peu(ven)t être une mémoire ROM/RAM, une clé USB, une mémoire d’un serveur central.
L’unité de traitement peut être intégrée ou séparée de l’unité de stockage. Par ailleurs, les différents éléments constituant l’unité de traitement (respectivement l’unité de stockage) peuvent être situés à des positions physiquement différentes à l’échelle d’un bâtiment, d’une ville, d’un pays ou d’un ou plusieurs continents.
Outre la conservation de données associées à l’examen médical (données de nature médicale, données de contrôle, etc.), l’unité de stockage permet également de stocker des instructions de code de programmation destinées à exécuter certaines étapes du procédé d’authentification décrit dans la suite.
Il en va de même de la sonde 1 et du terminal 2 qui comprennent chacun une mémoire respective pour le stockage d’instructions de code de programmation pour la mise en œuvre du procédé d’authentification présenté ci-dessous.
1.3. Cercle de confiance
La sonde 1 et la plateforme 3 sont des ressources appartenant à un même espace de confiance. La sonde 1 et la plateforme 3 sont par exemple fabriquées par une même organisation, ou appartiennent à une même organisation (même entreprise ou groupement d’entreprises).
L’unité de stockage de la plateforme 3 comprend une table répertoriant l’ensemble des sondes 1 fabriquées et/ou appartenant à l’organisation. Plus précisément, chaque sonde 1 est caractérisée par un identifiant de sonde (une suite de caractères) auquel est associée une clé publique de sonde permettant de chiffrer des messages à l’attention de la sonde 1. L’identifiant de sonde et la clé publique de sonde sont stockés dans la table de sonde contenue dans l’unité de stockage de la plateforme 3.
Seule la sonde 1 dispose de la clé privée de sonde permettant de déchiffrer les messages chiffrés à partir de la clé publique de sonde. En d’autres termes, la clé privée de sonde est stockée uniquement dans la mémoire de la sonde 1.
Le terminal 2 n’appartient, quant à lui, pas à la même organisation. Il est apte à fonctionner avec différentes sondes 1. Il appartient à un utilisateur ayant un compte client auprès de la plateforme 3 et lui permettant de s’identifier.
Lors de la souscription d’un compte client, un identifiant de terminal, une clé privée de terminal et une clé publique de terminal sont générés. L’identifiant de terminal et la clé privée de terminal sont stockés dans la mémoire du terminal 2. L’identifiant de terminal et la clé publique de terminal sont conservés dans une table stockés dans l’unité de stockage de la plateforme 3.
2. Procédé d’authentification
On va maintenant décrire plus en détail le principe de fonctionnement du procédé d’authentification selon l’invention. Ce procédé d’authentification est mis en œuvre entre les différentes entités (sonde 1, terminal 2, plateforme 3) du système préalablement à l’échange de données entre ces entités.
On suppose dans la suite que l’utilisateur dispose d’un compte utilisateur préalablement souscrit auprès de la plateforme 3, et que le terminal 2 de l’utilisateur a été enregistré lors de la souscription du compte utilisateur. Lors de l’opération d’enregistrement :
  • un clé publique de plateforme a été envoyée au terminal 2 par la plateforme distante ; cette clé publique de plateforme permet au terminal de chiffrer les messages à destination de la plateforme 3,
  • une clé privée de terminal a été générée par le terminal 2 ; cette clé privée de terminal permet au terminal 2 de déchiffrer les messages reçus ayant été chiffrés en utilisant une clé publique de terminal (stockée dans l’unité de stockage de la plateforme 3) associée la clé privée de terminal.
Comme indiqué ci-dessus :
  • la mémoire de la sonde 1 contient :
    • la clé privée de sonde permettant de déchiffrer des messages chiffrés avec l’une des clés publiques de sonde, et
    • éventuellement la clé publique de plateforme permettant de chiffrer les messages à destination de la plateforme 3 ;
  • la mémoire du terminal 2 contient :
    • la clé privée de terminal permettant de déchiffrer les messages chiffrés avec l’une des clés publiques de terminal, et
    • la clé publique de plateforme permettant de chiffrer les messages à destination de la plateforme 3 ;
  • l’unité de stockage de la plateforme 3 contient :
    • une table de sonde incluant l’identifiant de chaque sonde 1 de l’organisation et la clé publique de sonde associée à chaque identifiant de sonde,
    • une table de terminal incluant l’identifiant de chaque terminal 2 et la clé publique de terminal associée à chaque identifiant de terminal,
    • la clé privée de plateforme permettant de déchiffrer les messages chiffrés avec l’une des clés publiques de plateforme.
Le procédé d’authentification comprend deux phases :
  • une première phase de dialogue 100 entre le terminal 2 et la plateforme 3, et
  • une deuxième phase de dialogue 200 entre le terminal 2 et la sonde 1, la deuxième phase 200 étant postérieure à la première phase 100.
Avantageusement, ces deux phases 100, 200 peuvent être mises en œuvre à des instants éloignés dans le temps.
Ainsi, il est possible d’exécuter la deuxième phase 200 même si le réseau informatique (tel qu’Internet) n’est plus accessible. En effet, la sonde 1 et le terminal 2 étant destinés à être utilisés en situation de mobilité, il y a un risque que dans certaines conditions d’utilisation, l’accessibilité au réseau informatique Internet ne soit plus assurée au cours de l’acquisition de données pour réaliser un examen.
2.1. Première phase de dialogue
La première phase de dialogue 100 permet à la plateforme 3 d’authentifier la sonde 1 et le terminal 2.
La première phase de dialogue 100 permet également de transférer de la plateforme vers le terminal des données de commande pour le pilotage de la sonde (instructions d'examen, insonification, déroulé d'examen, etc. régissant l'énergie apportée par la sonde au patient). Ces données de commande sont avantageusement stockées dans le terminal pour permettre l’exécution du (ou des) examen(s) médical (médicaux) sans nécessiter une connexion à la plateforme.
La première phase 100 comprend les étapes suivantes :
  • émission 110 d’une requête d’examen par le terminal 2, et réception 120 de la requête d’examen par la plateforme 3,
  • émission 130 par la plateforme 3, d’un message de réponse incluant des informations de vérification chiffrées en utilisant la clé publique de sonde, et réception 140 du message de réponse par le terminal 2.
2.1.1. Emission/réception d’une requête
Plus précisément, lorsque l’utilisateur souhaite effectuer un examen, il saisit sur les moyens de saisie du terminal 2 des renseignements concernant l’examen, et notamment : l’identifiant du terminal, et l’identifiant de la sonde destinée à être utilisée pour l’examen.
La requête peut également comprendre des informations personnelles relatives au patient (nom, prénom, numéro de dossier, etc.) et/ou à l’examen (date d’acquisition des données d’examen, type d’examen, etc.).
A partir des renseignements saisis par l’utilisateur, le terminal 2 génère 111 une requête d’examen à destination de la plateforme 3. Cette requête comprend les identifiants du terminal 2 et de la sonde 1.
Avantageusement, cette requête peut être chiffrée 112 à partir de la clé publique de plateforme. Ceci permet de limiter les risques d’obtention de renseignements critiques par un tiers malveillant ayant intercepté toutes les communications, par exemple pour usurper l'identité du terminal 2.
La requête générée et chiffrée est envoyée 113 par le terminal 2.
La plateforme 3 reçoit 121 la requête émise par le terminal 2, et la déchiffre 122 en utilisant la clé privée de plateforme. Une fois la requête déchiffrée, la plateforme 3 extrait 123 les identifiants de la sonde 1 et du terminal 2.
Ainsi dans un mode de réalisation, l’étape d’émission/réception 110, 120 d’une requête comprend les sous-étapes consistant à :
  • pour le terminal 2 :
    • générer 111 une requête d’examen incluant les identifiants du terminal 2 et de la sonde 1,
    • chiffrer 112 la requête à partir de la clé publique de plateforme,
    • envoyer 113 la requête chiffrée à la plateforme 3,
  • pour la plateforme 3 :
    • recevoir 121 la requête,
    • déchiffrer 122 la requête à partir de la clé privée de plateforme et
    • extraire 123 les identifiants de sonde et de terminal.
2.1.2. Emission/réception d’un message de réponse
2.1.2.1. Emission 130
La plateforme 3 vérifie que l’utilisateur dispose de droits d’utilisation du système en fonction de l’identifiant de terminal notamment.
La plateforme 3 recherche 131 dans la table de sonde, la clé publique de sonde associée à l’identifiant de sonde.
Cette clé publique de sonde est destinée à être transmise au terminal 2 dans le message de réponse pour lui permettre de chiffrer les messages à destination de la sonde 1 avec ladite clé publique de sonde.
Cette clé publique de sonde est également utilisée par la plateforme 3 pour chiffrer des informations de vérification incluses dans le message de réponse et destinées à la sonde 1, l’accessibilité à ces informations de vérification n’étant pas souhaitée pour le terminal 2. En effet, comme rappelé ci-dessus seule la clé privée de sonde permet de déchiffrer les messages chiffrés à l’aide d’une clé publique de sonde. Ainsi, même si le terminal 2 dispose de la clé publique de sonde, il n’est pas en mesure de déchiffrer les informations de vérification contenues dans le message de réponse et ayant été chiffrées avec la clé publique de sonde.
Le fait de transmettre dans le message de réponse, des informations de vérification déchiffrables uniquement par la sonde 1 permet d’assurer l’authentification ultérieure du terminal 2 par la sonde 1 lors de la mise en œuvre de la deuxième phase 200.
La plateforme 3 recherche 131 également dans la table de terminal, la clé publique de terminal associée à l’identifiant de terminal. Cette clé publique de terminal est intégrée aux informations de vérification à destination de la sonde 1 incluses dans le message de réponse. La clé publique de terminal est également utilisée par la plateforme 3 pour chiffrer le message de réponse.
La plateforme 3 génère 132 ensuite le message de réponse. Ce message comprend :
  • d’une part la clé publique de sonde pour permettre au terminal 2 de chiffrer les messages adressés à la sonde 1 lors de la mise en œuvre de la deuxième phase 200, et
  • d’autre part, les informations de vérification à destination de la sonde 1 et auxquelles le terminal 2 ne doit pas pouvoir accéder ; ces informations de vérification comprennent notamment la clé publique du terminal, l’identifiant du terminal, une clé de session, et une clé de séquence, etc.
La clé de session est utilisée pour chiffrer/déchiffrer les données échangées selon un mode de cryptographie symétrique (la clé de session est utilisée à la fois pour chiffrer et déchiffrer les données). La clé de session est enregistrée dans l’unité de stockage de la plateforme 3. Elle sera utilisée durant la mise en œuvre de l’examen pour :
  • chiffrer/déchiffrer les messages adressés à/reçus de la sonde 1
  • chiffrer/déchiffrer les messages adressés au/reçus du terminal 2.
La durée de validité de la clé de session dépend du type d’application visée. Elle peut être de quelques dizaines de minutes pour un examen pour un patient, ou de plusieurs heures/jours pour une session d’imagerie dans un véhicule d’urgence (en mobilité), voire à une prescription de traitement pour un patient et une durée donnée.
Avantageusement, une clé de séquence est incluse dans les informations de vérification. Elle est réservée à l’échange d’information entre la plateforme et la sonde, via le terminal, en particulier d’informations sensibles de commande telles que les instructions de pilotage de la sonde. En effet, la (ou les) séquence(s) de paramétrage de la sonde (pour l’acquisition des données dans le cadre de l’examen) ne peuvent pas être envoyées directement de la plateforme vers la sonde, notamment du fait de la capacité mémoire limitée de la sonde. C’est pourquoi le terminal peut être utilisé pour stocker cette (ou ces) séquence(s), et pour la (ou les) transmettre séquentiellement par morceau à la sonde.
La durée de validité de la clé de séquence est la même que la clé de session.
Le message de réponse généré est chiffré 133 en utilisant la clé publique de terminal. Le fait de chiffrer le message de réponse en utilisant la clé publique de terminal permet d’éviter les risques d’interception frauduleuse de renseignements critiques pour le système, ceux-ci étant chiffrés et donc inexploitables en l’état. Cela permet en outre à la plateforme de s’assurer que le terminal 2 ayant généré la requête et que le terminal associé à l’identifiant contenu dans la requête constituent bien une seule et même entité (seul le terminal dont l’identifiant a été indiqué dans la requête disposant de la clé privée de terminal permettant de déchiffrer le message de la plateforme).
Une fois chiffré, le message de réponse est envoyé 134 par la plateforme 3.
Ainsi dans un mode de réalisation, l’étape d’émission 130 d’un message de réponse comprend les sous-étapes consistant à :
  • rechercher 131 dans la table de sonde, la clé publique de sonde associée à l’identifiant de sonde,
  • rechercher 131 dans la table de terminal, la clé publique de terminal associée à l’identifiant de terminal,
  • générer 132 le message de réponse, le message de réponse comprenant :
    • la clé publique de sonde, et
    • des informations de vérification à destination de la sonde (clé publique du terminal, identifiant du terminal, clé de session, etc.), lesdites informations de vérification étant chiffrées en utilisant la clé publique de sonde,
  • chiffrer 133 le message de réponse en utilisant la clé publique de terminal,
  • envoyer 134 le message de réponse chiffré vers le terminal externe.
2.1.2.2. Réception 140 du message de réponse
Le terminal 2 reçoit le message de réponse, le déchiffre 141 et le stocke 143 dans la mémoire du terminal 2 pour une utilisation ultérieure des données qu’il contient lors de la mise en œuvre de la deuxième phase de dialogue 200.
Ainsi, la mise en œuvre de la deuxième phase 200 peut être éloignée dans le temps de la mise en œuvre de la première phase 100. Ceci permet de ne pas conditionner la mise en œuvre de la deuxième phase 200 à l’accessibilité au réseau informatique de type Internet. En d’autres termes, l’utilisateur peut exécuter la première phase 100 lorsqu’il dispose d’un accès au réseau informatique, et mettre en œuvre la deuxième phase 200 durant une situation de mobilité au cours de laquelle l’accessibilité au réseau informatique n’est pas garantie.
Le lecteur appréciera que plusieurs premières phases 100 peuvent être effectuées consécutivement, pour une même (ou différentes) sonde(s) 1 associée(s) à un terminal 2, chaque première phase 100 correspondant à un examen respectif, d’un patient. Par exemple, si l’utilisateur sait qu’il doit réaliser huit examens planifiés au cours d’une journée de travail, il peut préalablement à ses déplacements, requérir la réception de huit messages de réponse correspondant chacun à un examen respectif.
Pour résumer et en référence à la figure 2, l’étape de réception 140 du message de réponse par le terminal 2 comprend les sous-étapes consistant à :
  • déchiffrer 141 le message de réponse,
  • extraire 142 la clé publique de sonde et les informations de vérification chiffrées (avec la clé publique de sonde),
  • stocker 143 la clé publique de sonde et les informations de vérification chiffrées.
2.2. De uxième phase de dialogue 200
La deuxième phase de dialogue 200 permet à la sonde 1 d’authentifier le terminal 2 et la plateforme 3.
La deuxième phase 200 comprend les étapes suivantes :
  • émission 210 par le terminal 2 d’un message de transfert contenant les informations de vérification chiffrées avec la clé publique de sonde, et réception 220 du message de transfert par la sonde 1,
  • émission 230 par la sonde 1 d’un message de contrôle, le message de contrôle incluant des informations chiffrées avec la clé publique du terminal 2, et réception 230 par le terminal 2 du message de contrôle,
  • émission 240 par le terminal 2 d’un message de confirmation, et réception 240 par la sonde 1 du message de confirmation,
  • émission 250 par la sonde 1 d’un message de validation, et réception 250 du message de validation par le terminal 2.
2.2.1. Emission/réception du message de transfert
La première étape de la deuxième phase consiste en l’émission 210 par le terminal 2 d’un message de transfert incluant les informations de vérification chiffrées à partir de la clé publique de sonde.
Plus précisément, le terminal 2 génère 211 le message de transfert en intégrant dans celui-ci :
  • une demande d’appairage incluant l’identifiant du terminal 2, et
  • les informations de vérification extraites de la mémoire du terminal 2, ces informations de vérification ayant été chiffrées par la plateforme 3 à l’aide de la clé publique de sonde.
Le terminal 2 chiffre 212 ensuite le message de transfert en utilisant la clé publique de sonde, et l’envoie 213 à la sonde 1.
La sonde 1 reçoit 221 le message de transfert, le déchiffre 222 en utilisant la clé privée de sonde qu’elle est la seule à détenir, et extrait 223 du message :
  • l’identifiant du terminal, ainsi que
  • les informations de vérification chiffrées par la plateforme.
2.2.2. Emission/réception 230 du message de contrôle
La sonde 1 déchiffre également les informations de vérification (chiffrées par la plateforme 3) en utilisant la clé privée de sonde.
La sonde 1 extrait l’identifiant de terminal des informations de vérification, et le compare à l’identifiant de terminal indiqué par le terminal 2 dans le message de transfert : ceci permet à la sonde 1 de vérifier que l’identifiant de terminal indiqué par le terminal 2 correspond bien à l’identifiant de terminal indiqué par la plateforme 3. Si les deux identifiants correspondent, alors la sonde 1 possède un a priori positif sur la fiabilité du terminal 2. La sonde génère alors un message de contrôle permettant à la sonde 1 de confirmer l’authenticité du terminal 2.
Pour générer le message de contrôle, la sonde 1 extrait des informations de vérification, et stocke dans sa mémoire :
  • la clé de session (qui sera utilisée pour chiffrer/déchiffrer les messages envoyés/reçus durant l’examen), et
  • la clé publique de terminal.
La clé de terminal est utilisée pour chiffrer 232 le message de contrôle. Le fait de chiffrer le message de contrôle en utilisant la clé publique de terminal fournie par la plateforme permet à la sonde de garantir l’authenticité du terminal, seul celui-ci disposant de la clé privée permettant de déchiffrer le message de contrôle.
La clé de session est quant à elle utilisée comme message de test pour confirmer l’identité du terminal 2 : si le terminal 2 correspondant bien à son identifiant, alors il est le seul à pouvoir déchiffrer le message de contrôle (chiffré avec la clé publique de terminal) et en extraire le message de test (i.e. la clé de session).
Une fois chiffré, le message de contrôle est envoyé 232 au terminal 2.
Le terminal 2 reçoit 233 le message de contrôle, le déchiffre 233 en utilisant la clé privée de terminal et extrait 234 la clé de session. La clé de session est stockée dans la mémoire du terminal 2 (elle sera utilisée pour chiffrer/déchiffrer les messages envoyés ou reçus durant l’examen).
2.2.3. Emission/réception 240, 250 des messages de confirmation et de validation
Le terminal 2 génère un message de validation à destination de la sonde 1 pour s’authentifier. Ce message de validation comprend la clé de session. Le message de validation est chiffré en utilisant la clé publique de sonde, et envoyé à la sonde 1.
La sonde reçoit le message de validation, le déchiffre en utilisant la clé privée de sonde, et extrait la clé de session. Cette clé de session est comparée à la clé de session stockée dans la mémoire de la sonde 1. Si la clé de session reçue dans le message de validation correspond à la clé de session contenue dans la mémoire de la sonde 1, alors l’authentification du terminal 2 est confirmée. La sonde émet 250 un message de confirmation au terminal 2 : toutes les entités (sonde 1, terminal 2, plateforme 3) du système satisfont les conditions de confiance requises, et l’examen peut débuter.
3. Examen
Durant l’examen, toutes les données transmises entre les différentes entités sont chiffrées en utilisant la clé de session. Les instructions de contrôle de la sonde sont transmises par la plateforme au sein d’un message chiffré par la clé de séquence (connue uniquement de la sonde et de la plateforme).
La clé de session garantit :
  • l’intégrité des données système d’une part, et la confidentialité des données médicales d’autre part : seule la sonde 1, le terminal 2 et la plateforme 3 authentifiés disposant de la clé de session permettant l’accès aux données, et
  • la fiabilité des données médicales : la clé de session étant unique pour chaque examen (ainsi si plusieurs examens successifs sont effectués par un même utilisateur pour un même patient, il n’y a aucun risque de confusion dans les données associées à ces différents examens, la correspondance entre la clé de session et l’examen étant biunivoque).
La clé de séquence garantit l’intégrité des données de pilotage de la sonde qui dépose de l’énergie ultrasonore dans le tissu biologique du patient.
Lorsque l’examen est terminé, la clé de session est effacée de la mémoire de la sonde 1, de la mémoire du terminal 2, et de l’unité de stockage de la plateforme 3, de même, la clé de séquence est effacée de la mémoire de la sonde 1 et de la plateforme 3.
Ainsi l’accessibilité aux données par les différentes entités du système est limitée dans le temps à la mise en œuvre de l’examen.
La fin d’examen peut être programmée par l’utilisateur en utilisant le terminal 2. Dans ce cas, le terminal 2 envoie à la sonde 1 et à la plateforme 3 un message de commande de fin d’examen. Si certaines données médicales relatives à l’examen n’ont pas été acquises par la sonde 1 et/ou n’ont pas été traitées par la plateforme 3, la sonde 1 et la plateforme 3 peuvent envoyer un message d’acceptation indiquant que la commande de fin d’examen a bien été prise en compte et que celle-ci sera effective dès finalisation de l’acquisition et/ou du traitement des données médicales par la sonde 1 et/ou la plateforme 3.
4. Conclusions
L’invention définie précédemment permet l’échange sécurisé et fiabilisé de données entre différents entités d’un système utilisant un réseau informatique de type Internet.
Le lecteur aura compris que de nombreuses modifications peuvent être apportées à l’invention décrite précédemment sans sortir matériellement des nouveaux enseignements et des avantages décrits ici (par exemple le procédé pourrait ne pas comprendre l’utilisation d’une clé de séquence).
Par conséquent, toutes les modifications de ce type sont destinées à être incorporées à l’intérieur de la portée des revendications jointes.  

Claims (13)

  1. Procédé de gestion des échanges de données durant une procédure d’examen médical d’un patient, le procédé permettant la gestion des échanges de données entre :
    • une sonde (1) d’acquisition de données médicales,
    • un terminal (2) apte à communiquer avec la sonde par l’intermédiaire de moyens de communication avec ou sans fil,
    • une plateforme (3) distante apte à communiquer avec le terminal par l’intermédiaire d’un réseau informatique tel qu’Internet,
    caractérisé en ce que le procédé comprend, préalablement à la mise en œuvre de la procédure d’examen, la mise en œuvre d’une procédure d’authentification dans laquelle :
    • une clé de session générée par la plateforme est transmise à la sonde et au terminal, ladite clé de session permettant le chiffrement/déchiffrement symétrique de données de session échangées durant la procédure d’examen médical, et
    • une clé de séquence générée par la plateforme est transmise à la sonde, ladite clé de séquence permettant le chiffrement/déchiffrement symétrique de données de séquence échangées entre la plateforme et la sonde durant la procédure d’examen médical.
  2. Procédé de gestion selon la revendication 1, dans lequel la procédure d’authentification comprend une première phase (100) d’échange entre le terminal (2) et la plateforme (3) par l’intermédiaire du réseau informatique, ladite première phase (100) comportant :
    • l’émission (110) par le terminal (2) d’une requête d’examen vers la plateforme (3),
    • l’émission (130) par la plateforme (3) d’un message de réponse vers le terminal (2), le message de réponse incluant :
      • des données accessibles au terminal (2), et
      • des informations de vérification accessibles uniquement par la sonde (1), les informations de vérification étant chiffrées par chiffrement asymétrique en utilisant une clé publique de sonde et incluant la clé de session et la clé de séquence.
  3. Procédé selon la revendication 2, dans lequel :
    • l’étape d’émission (110) d’une requête d’examen vers la plateforme (3) comprend une sous-étape consistant à chiffrer (112) asymétriquement la requête en utilisant une clé publique de plateforme,
    le procédé comprenant en outre :
    • une étape de réception (120) par la plateforme (3) de la requête chiffrée, ladite étape de réception (120) incluant une sous-étape consistant à déchiffrer (122) la requête chiffrée en utilisant une clé privée de plateforme.
  4. Procédé selon l’une quelconque des revendications 2 ou 3, dans lequel :
    • l’étape d’émission (130) par la plateforme (3) d’un message de réponse comprend une sous-étape consistant à chiffrer (133) asymétriquement le message de réponse en utilisant une clé publique de terminal,
    le procédé comprenant en outre :
    • une étape de réception (140) par le terminal (2) du message de réponse chiffré, ladite étape de réception (140) incluant :
      • une sous-étape consistant à déchiffrer (141) le message de réponse chiffré en utilisant une clé privée de terminal, et
      • éventuellement, une sous-étape consistant à stocker (143) en mémoire les informations de vérification chiffrées contenues dans le message de réponse.
  5. Procédé selon l’une quelconque des revendications 2 à 4, dans lequel la requête d’examen comprend un identifiant de sonde associé à la sonde et un identifiant de terminal associé au terminal, l’étape d’émission (130) du message de réponse comprenant les sous-étapes consistant à :
    • rechercher (131) dans une table de sonde la clé publique de sonde à partir de l’identifiant de sonde,
    • rechercher (131) dans une table de terminal la clé publique de terminal à partir de l’identifiant de terminal,
    • générer la clé de session, et la clé de séquence,
    • intégrer la clé de session, la clé de séquence, la clé publique de terminal et l’identifiant de terminal aux informations de vérification, et
    • chiffrer (133) asymétriquement les informations de vérification en utilisant la clé publique de sonde.
  6. Procédé de gestion selon l’une quelconque des revendications 2 à 5, dans lequel la procédure d’authentification comprend une deuxième phase (200) d’échange entre la sonde (1) et le terminal (2) par l’intermédiaire des moyens de communication avec ou sans fil, ladite deuxième phase (200) incluant :
    • l’émission (210) par le terminal (2) d’un message de transfert vers la sonde (1), le message de transfert comportant :
      • une demande d’appairage à la sonde (1) pour permettre l’échange de données entre la sonde (1) et le terminal (2),
      • les informations de vérification chiffrées par chiffrement asymétrique en utilisant la clé publique de sonde,
    • l’émission (230) par la sonde (1) d’un message de contrôle vers le terminal (2), le message de contrôle comprenant la clé de session chiffrée par chiffrement asymétrique en utilisant une clé publique de terminal.
  7. Procédé de gestion selon la revendication 6, dans lequel
    • l’étape d’émission (210) d’un message de transfert vers la sonde (1) comprend une sous-étape consistant à chiffrer (212) asymétriquement le message de transfert en utilisant une clé publique de sonde,
    le procédé comprenant en outre :
    • une étape de réception (220) par la sonde (1) du message de transfert chiffré, ladite étape de réception (220) incluant une sous-étape consistant à déchiffrer (222) le message de transfert chiffré en utilisant une clé privée de sonde.
  8. Procédé de gestion selon la revendication 7, dans lequel :
    • la demande d’appairage comprend l’identifiant du terminal renseigné par le terminal (2), et
    • les informations de vérification comprennent l’identifiant du terminal renseigné par la plateforme (3),
    l’étape de réception (220) par la sonde (1) du message de transfert incluant, postérieurement à l’étape consistant à déchiffrer (222) le message de transfert, les sous-étapes consistant à :
    • déchiffrer les informations de vérification en utilisant la clé privée de sonde,
    • extraire, des informations de vérification déchiffrées, l’identifiant de terminal renseigné par la plateforme (3),
    • extraire, de la demande d’appairage, l’identifiant de terminal renseigné par le terminal (2),
    • comparer l’identifiant de terminal renseigné par la plateforme (3) et l’identifiant de terminal renseigné par le terminal (2),
    • émettre une alarme si les identifiants de terminal sont différents,
    • passer à l’étape d’émission d’un message de contrôle sinon.
  9. Procédé de gestion selon l’une quelconque des revendications 6 à 8, dans lequel la deuxième phase (200) comprend en outre une étape de réception par le terminal (2) du message de contrôle, ladite étape de réception incluant :
    • une sous-étape consistant à déchiffrer (233) la clé de session chiffrée en utilisant une clé privée de terminal, et
    • une sous-étape consistant à extraire (234) du message de contrôle la clé de session.
  10. Procédé de gestion selon l’une quelconque des revendications 6 à 9, dans lequel la deuxième phase (200) comprend en outre une étape d’émission (240) par le terminal (2) vers la sonde (1), d’un message de confirmation incluant la clé de session, ledit message de confirmation étant chiffré par chiffrement asymétrique en utilisant une clé publique de sonde.
  11. Procédé de gestion selon la revendication 10, dans lequel la deuxième phase (200) comprend en outre une étape de réception du message de confirmation par la sonde (1), ladite étape de réception incluant les sous-étapes consistant à :
    • déchiffrer le message de confirmation en utilisant une clé privée de sonde,
    • extraire la clé de session du message de confirmation et la comparer à la clé de session contenue dans les informations de vérification,
    • émettre une alarme si la clé de session du message de confirmation est différente de la clé de session contenue dans les informations de vérification,
    • émettre (250) un message de validation vers le terminal (2) sinon, pour permettre la mise en œuvre de la procédure d’examen.
  12. Système pour l’échange de données lors d’une procédure d’examen d’un patient, le système comprenant :
    • une sonde (1) d’acquisition de données,
    • un terminal (2) apte à communiquer avec la sonde par l’intermédiaire de moyens de communication avec ou sans fil,
    • une plateforme (3) distante apte à communiquer avec le terminal par l’intermédiaire d’un réseau informatique tel qu’Internet,
    caractérisé en ce que la sonde (1), le terminal (2) et la plateforme (3) comprennent des moyens pour la mise en œuvre d’une procédure d’authentification, préalablement à la mise en œuvre de la procédure d’examen, dans laquelle une clé de session et une clé de séquence sont générées par la plateforme :
    • la clé de session étant transmise à la sonde et au terminal durant la procédure d’authentification, et permettant le chiffrement/déchiffrement symétrique de données de session échangées entre la sonde, le terminal et la plateforme durant la procédure d’examen,
    • la clé de séquence étant transmise à la sonde durant la procédure d’authentification, et permettant le chiffrement/déchiffrement de données de séquence échangées entre la sonde et la plateforme durant la procédure d’examen.
  13. Système selon la revendication 12, dans lequel la sonde, le terminal et la plateforme comprennent des moyens pour la mise en œuvre du procédé de gestion défini aux revendications 1 à 11.
FR1915204A 2019-12-20 2019-12-20 Procede et systeme de gestion d’echange de donnees dans le cadre d’un examen medical Active FR3105682B1 (fr)

Priority Applications (8)

Application Number Priority Date Filing Date Title
FR1915204A FR3105682B1 (fr) 2019-12-20 2019-12-20 Procede et systeme de gestion d’echange de donnees dans le cadre d’un examen medical
EP20829945.3A EP4079018A1 (fr) 2019-12-20 2020-12-21 Procede et systeme de gestion d'echange de donnees dans le cadre d'un examen medical
PCT/EP2020/087458 WO2021123431A1 (fr) 2019-12-20 2020-12-21 Procede et systeme de gestion d'echange de donnees dans le cadre d'un examen medical
CN202080094825.8A CN115136545B (zh) 2019-12-20 2020-12-21 用于在医疗检查的环境中管理数据交换的方法和系统
US17/786,195 US20230016828A1 (en) 2019-12-20 2020-12-21 Method and system for managing data exchange in the context of a medical examination
JP2022538167A JP2023507651A (ja) 2019-12-20 2020-12-21 医療検査に関するデータ交換を管理する方法及びシステム
KR1020227024603A KR20220134751A (ko) 2019-12-20 2020-12-21 의료 검사의 컨텍스트에서 데이터 교환을 관리하기 위한 방법 및 시스템
IL294053A IL294053A (en) 2019-12-20 2022-06-16 A method and system for managing data exchange in the context of a medical examination

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1915204A FR3105682B1 (fr) 2019-12-20 2019-12-20 Procede et systeme de gestion d’echange de donnees dans le cadre d’un examen medical
FR1915204 2019-12-20

Publications (2)

Publication Number Publication Date
FR3105682A1 true FR3105682A1 (fr) 2021-06-25
FR3105682B1 FR3105682B1 (fr) 2022-05-13

Family

ID=71094421

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1915204A Active FR3105682B1 (fr) 2019-12-20 2019-12-20 Procede et systeme de gestion d’echange de donnees dans le cadre d’un examen medical

Country Status (8)

Country Link
US (1) US20230016828A1 (fr)
EP (1) EP4079018A1 (fr)
JP (1) JP2023507651A (fr)
KR (1) KR20220134751A (fr)
CN (1) CN115136545B (fr)
FR (1) FR3105682B1 (fr)
IL (1) IL294053A (fr)
WO (1) WO2021123431A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12047778B2 (en) * 2021-08-11 2024-07-23 Texas Instruments Incorporated Wireless battery management system setup

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040034776A1 (en) * 2002-08-14 2004-02-19 Microsoft Corporation Authenticating peer-to-peer connections
US20170303119A1 (en) * 2016-04-15 2017-10-19 Fujitsu Limited Information processing system, method of obtaining monitor information, and sensor device
US20190089684A1 (en) * 2014-03-11 2019-03-21 Tencent Technology (Shenzhen) Company Limited Method and system for encrypted communications

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6987855B1 (en) * 1999-09-10 2006-01-17 Cisco Technology, Inc. Operational optimization of a shared secret Diffie-Hellman key exchange among broadcast or multicast groups
DE102013202494A1 (de) * 2013-02-15 2014-08-21 Siemens Aktiengesellschaft Authentifizierung von medizinischen Clientgeräten in einem Geräteverbund
US9769658B2 (en) * 2013-06-23 2017-09-19 Shlomi Dolev Certificating vehicle public key with vehicle attributes
US9716716B2 (en) * 2014-09-17 2017-07-25 Microsoft Technology Licensing, Llc Establishing trust between two devices
US11153076B2 (en) * 2017-07-17 2021-10-19 Thirdwayv, Inc. Secure communication for medical devices
CN110445614B (zh) * 2019-07-05 2021-05-25 创新先进技术有限公司 证书申请方法、装置、终端设备、网关设备和服务器
CN110351727B (zh) * 2019-07-05 2020-06-02 北京邮电大学 一种适于无线传感网络的认证与密钥协商方法
CN110535656A (zh) * 2019-07-31 2019-12-03 阿里巴巴集团控股有限公司 医疗数据处理方法、装置、设备及服务器

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040034776A1 (en) * 2002-08-14 2004-02-19 Microsoft Corporation Authenticating peer-to-peer connections
US20190089684A1 (en) * 2014-03-11 2019-03-21 Tencent Technology (Shenzhen) Company Limited Method and system for encrypted communications
US20170303119A1 (en) * 2016-04-15 2017-10-19 Fujitsu Limited Information processing system, method of obtaining monitor information, and sensor device

Also Published As

Publication number Publication date
JP2023507651A (ja) 2023-02-24
IL294053A (en) 2022-08-01
KR20220134751A (ko) 2022-10-05
CN115136545B (zh) 2024-03-12
EP4079018A1 (fr) 2022-10-26
CN115136545A (zh) 2022-09-30
WO2021123431A1 (fr) 2021-06-24
FR3105682B1 (fr) 2022-05-13
US20230016828A1 (en) 2023-01-19

Similar Documents

Publication Publication Date Title
EP0763803B1 (fr) Système de comptabilisation anonyme d'informations à des fins statistiques, notamment pour des opérations de vote électronique ou de relevés périodiques de consommation
US11604893B2 (en) Privacy-preserving image distribution
FR2800481A1 (fr) Systemes, procedes et dispositifs pour transferer des donnees medicales entre des appareils distants
EP1549011A1 (fr) Procédé et système de communication entre un terminal et au moins un équipment communicant
FR2803461A1 (fr) Procede et dispositif pour la gestion de groupes dans l'entretien de services distants
EP0547975A1 (fr) Procédé d'authentification, par un milieu extérieur, d'un objet portatif connecté à ce milieu par l'intermédiaire d'une ligne de transmission, et système pour la mise en oeuvre
EP2619941A1 (fr) Procede, serveur et systeme d'authentification d'une personne
EP3241137B1 (fr) Procede mis en oeuvre dans un document d'identite et document d'identite associe
CN107506635B (zh) 身份证网上功能开通方法、手机、可信终端和验证服务器
FR3048530B1 (fr) Systeme ouvert et securise de signature electronique et procede associe
FR2975855A1 (fr) Systeme et procede de securisation d'echanges de donnees entre un module client et un module serveur
CN105391540A (zh) 一种物联网安全系统、互联设备及实现方法
CN110443047A (zh) 数据交换群组系统及方法
EP3991381B1 (fr) Procédé et système de génération de clés de chiffrement pour données de transaction ou de connexion
FR3105682A1 (fr) Procede et systeme de gestion d’echange de donnees dans le cadre d’un examen medical
WO2024022988A1 (fr) Procédé de traitement de données dans l'informatique en nuage
CN111798946A (zh) 一种检测数据处理方法、装置及设备
FR3095707A1 (fr) Procédé de sécurisation d’une communication et dispositif correspondant.
EP3107023B1 (fr) Procédé, dispositif et programme d'authentification sans fil d'un terminal de payment
WO2019102120A1 (fr) Procédés et dispositifs pour l'enrôlement et l'authentification d'un utilisateur auprès d'un service
CN115051816A (zh) 基于隐私保护的云计算方法、金融数据云计算方法及装置
FR2887717A1 (fr) Procede de creation d'un terminal eclate entre un terminal de base et des equipements connectes en serie
EP3371760A1 (fr) Procédé de verification d'identité lors d'une virtualisation
FR2984047A1 (fr) Procede d'echange de donnee chiffree entre un terminal et une machine
FR3133463A1 (fr) Dispositif portable et autonome de sécurisation de transfert de données et procédé correspondant.

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20210625

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5