WO2021123431A1 - 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
WO2021123431A1
WO2021123431A1 PCT/EP2020/087458 EP2020087458W WO2021123431A1 WO 2021123431 A1 WO2021123431 A1 WO 2021123431A1 EP 2020087458 W EP2020087458 W EP 2020087458W WO 2021123431 A1 WO2021123431 A1 WO 2021123431A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
probe
platform
certificate
verification information
Prior art date
Application number
PCT/EP2020/087458
Other languages
English (en)
Inventor
Claude Cohen-Bacrie
Adrien BESSON
Frederic WINTZENRIETH
Luc Bertrand
Eric GUIFFARD
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
Application filed by E-Scopics filed Critical E-Scopics
Priority to EP20829945.3A priority Critical patent/EP4079018A1/fr
Priority to CN202080094825.8A priority patent/CN115136545B/zh
Priority to KR1020227024603A priority patent/KR20220134751A/ko
Priority to JP2022538167A priority patent/JP2023507651A/ja
Priority to US17/786,195 priority patent/US20230016828A1/en
Publication of WO2021123431A1 publication Critical patent/WO2021123431A1/fr
Priority to IL294053A priority patent/IL294053A/en

Links

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic 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/3263—Cryptographic 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
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT 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/60—ICT 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
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT 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/60—ICT 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/67—ICT 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network 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/0442—Network 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key 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/0825—Key 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key 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/083—Key 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]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/009—Security arrangements; Authentication; Protecting privacy or anonymity specially adapted for networks, e.g. wireless sensor networks, ad-hoc networks, RFID networks or cloud networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/50—Secure pairing of devices

Definitions

  • the present invention relates to the general technical field of service security.
  • the present invention relates to a method allowing:
  • the invention also relates to an associated authentication and encryption system.
  • the invention relates to an advanced application of data acquisition and transfer solutions: dematerialized ultrasound.
  • Ultrasound imaging is used in many diagnostic procedures due to its non-invasive nature, relatively low cost, and the absence of patient exposure to harmful ionizing radiation.
  • the cloud makes it possible to pool the structures for storing and processing data, and has very significant computing power.
  • a computer network such as the Internet
  • the probe control instructions must not be able to be modified by a malicious third party in order to eliminate the risks to the health of the patient,
  • all the components (ie acquired data, processed data, measurements, etc.) of the examination must be consistent (for example medical data from a previous examination must not interfere with the medical data of 'an examination in progress / all medical data acquired from an examination in progress must be processed / etc.).
  • An aim of the present invention is to provide a method and a system making it possible to perform an ultrasound examination in a mobile situation and integrating a solution to the aforementioned integrity, reliability and confidentiality problems linked to the exchange of data by the intermediary of a computer network such as the Internet.
  • the invention relates to a method of managing data exchanges during a patient medical examination procedure, the method allowing the management of data exchanges between:
  • said probe comprising a memory containing a digital probe certificate including a public probe key
  • a terminal capable of communicating with the probe by means of wired or wireless communication means, said terminal comprising a memory containing a terminal digital certificate including a terminal public key,
  • a remote platform capable of communicating with the terminal via a computer network such as the Internet, said platform being configured to: o deliver the digital probe certificate to the probe, o deliver the digital terminal certificate to the terminal , remarkable in that the method comprises, prior to the implementation of the examination procedure, the implementation of an authentication procedure comprising the following phases:
  • a third phase in which the probe, the terminal and the platform each generate an identical session key (independently), said session key being produced from the public keys of the probe and the terminal (and not being transmitted between the probe, the terminal and the platform).
  • This session key is used to symmetrically encrypt session data transmitted between the probe, the terminal and the platform after the authentication procedure has been completed.
  • the session data exchanged can consist of:
  • control data ie control instructions
  • o control data ie control instructions
  • This session data including: o medical data acquired (and / or preprocessed) by the probe, and / or o medical data processed by the terminal and / or the remote platform.
  • This session data can be encrypted / decrypted by the probe or the terminal or the remote platform using the session key. The information contained in this session data is therefore accessible by the three entities of the system.
  • the identical session key is generated independently by the probe, the terminal and the platform, the public keys of the probe and the terminal being stored respectively:
  • the session key is used to encrypt the data exchanged between the probe, the terminal and the platform using a symmetrical cryptography mode during the implementation of the examination;
  • the first phase includes the following stages:
  • the first phase further comprises the following steps:
  • the step of exchanging verification information comprises the sub-steps consisting in: o the extraction, by the probe, of the terminal public key contained in the terminal digital certificate, o the generation, by the probe , a verification information, o the asymmetric encryption, by the probe, of the verification information with the terminal public key, o the sending, by the probe, of a response message including the verification encrypted with the terminal public key, o reception, by the terminal, of the response message and decryption of the verification information using a terminal private key stored in the terminal's memory, o sending, by the terminal, a confirmation message containing the decrypted verification information, o the reception, by the probe, of the confirmation message, o the comparison, by the probe, of the decrypted verification information contained in the confirmation with v information erification contained in the response message sent by the probe, to define whether said verification information is identical or different, and if the verification information is identical, emission of
  • the second phase comprises the following stages:
  • the second phase also includes the following steps:
  • the terminal sends an alarm message
  • the step of exchanging verification information comprises the sub-steps consisting of: o the extraction, by the terminal, of the probe public key contained in the probe digital certificate, o the generation, by the terminal , of verification information, o asymmetric encryption, by the terminal, of the verification information using the probe public key, o sending, by the terminal, of a justification message including the information verification encrypted with the probe's public key, o reception, by the probe, of the justification message and decryption of the verification information using a private probe key stored in the probe's memory, o sending , by the probe, of a proof message containing the decrypted verification information, o the reception, by the terminal, of the proof message, o the comparison, by the terminal, of the verification information contained in the message proof with verification information contained in the justification message sent by the terminal, to define whether said verification information is identical or different, and o if the verification information is identical, transmission of a validation message representative of a successful authentication, o if the verification information is different, emission of an
  • the method comprises, prior to the implementation of an authentication procedure, a subscription procedure in which:
  • the terminal sends the platform an examination request message including a probe identifier, a terminal identifier, and the terminal public key
  • the platform sends the terminal a pairing authorization message including a platform certificate including a platform public key and a terminal certificate including the terminal public key.
  • the invention also relates to a system for the exchange of data during a procedure for examining a patient, the system comprising:
  • said probe comprising a memory containing a digital probe certificate including a public probe key
  • terminal capable of communicating with the probe by means of wired or wireless communication means, said terminal comprising a memory containing a terminal digital certificate including a terminal public key,
  • a remote platform capable of communicating with the terminal via a computer network such as the Internet, said platform being configured to: o deliver the digital probe certificate to the probe, o deliver the digital terminal certificate to the terminal , remarkable in that the probe, the terminal and the platform comprise means adapted for the implementation of an authentication procedure, prior to the implementation of the examination procedure, the authentication procedure comprising the following phases:
  • a third phase in which the probe, the terminal and the platform each generate an identical session key, said session key being produced from the public keys of the probe and of the terminal.
  • the probe, the terminal and the platform comprise means for implementing the phases, steps and sub-steps of the management method defined above.
  • FIG. 1 is a schematic representation of a system for the exchange of data (i.e. order data, control data and / or data of a medical nature) during a patient examination procedure,
  • data i.e. order data, control data and / or data of a medical nature
  • FIG. 2 is a schematic representation of a first phase of dialogue between a probe and a terminal, said first phase being implemented during an authentication procedure
  • FIG. 3 is a schematic representation of a second phase of dialogue between the probe and the terminal, the second phase being implemented during the authentication procedure.
  • the invention described below uses the technique of data cryptography which allows a sending entity to encrypt the transmitted data so that only a genuine receiving entity can decrypt this data in order to interpret it.
  • Symmetric cryptography is suitable for a dialogue within a single transmitter / receiver pair with mutual trust because the transmitter and the receiver secretly share the same key.
  • Asymmetric cryptography is best suited for establishing a dialogue with many potential stakeholders.
  • any sending system can encrypt data using the public key and transmit it to the receiving entity: only the receiving entity can. decrypt the data using the private key. This ensures the confidentiality of the transmitted document.
  • the private key is held by the issuing entity, it is the only one that can encrypt the data. Any receiving entity can decrypt the data using the public key: this with the assurance that the sending entity that transmitted the data is the one that has the private key.
  • a disadvantage of using the asymmetric encryption technique comes from the transmission of the public key. If it is not secure, a malicious third party entity can position itself between a trusted entity and its public by distributing false public keys (through a fake website for example) then intercepting all communications, allowing it to usurp the identity of the trusted entity. This type of attack is commonly known as the "middle man attack”.
  • the method and the system described below are based on the use of electronic certificates which are better suited to the needs of the intended application. Indeed, as will emerge below, the invention implements data exchanges: between at least three distinct entities, the authenticity of one of these entities must be validated by the other two entities prior to the exchange of any data.
  • an electronic certificate (also called a “digital certificate” or “public key certificate”) constitutes a “digital identity card” used to:
  • An electronic certificate is made up of a set of data containing:
  • identification information of the entity associated with the certificate for example: name, location, email address of the entity that issued the certificate
  • the signing entity is the only authority making it possible to trust (or not) the accuracy of the information in the certificate.
  • FIG. 1 there is illustrated an example of a system in which the authentication method described below can be implemented prior to the exchange of data between the different entities of the system.
  • the system consists of three separate entities:
  • an acquisition probe 1 - a local terminal 2 connected to the probe by means of wired or wireless communication, and
  • a remote platform 3 connected to terminal 2 via a computer network such as the Internet.
  • the probe 1 allows the recording of medical data representative of a region of interest of a patient (internal structures, organ, etc.).
  • the probe 1 is for example an echographic probe including:
  • a communication unit (wired or wireless) for transmitting the acquired data to the external terminal.
  • the processing of the data acquired by the probe 1 allows the extraction of information relating to the patient and / or the display of an image of the region of interest, etc.
  • Terminal 2 allows the possible processing of certain medical data acquired by probe 1 and / or the display of images of the region of interest.
  • the terminal 2 is for example a mobile terminal such as a mobile telephone, in particular of the smartphone type, a personal assistant (or “PDA”, acronym of the English expression “Personal Digital Assistant”), or any type of terminal mobile known to those skilled in the art, such as a connected watch of the Apple Watch® type.
  • the terminal 2 can be a virtual terminal, that is to say an emulation of a physical mobile terminal.
  • the term “virtual terminal” encompasses any virtualized resource, and / or part of a real entity.
  • the virtual terminal can be a computer program, a virtual machine, an instance implemented in a “cloud computing” environment, a physical device subsystem such as a display screen, and the like.
  • terminal 2 allows the transfer of:
  • Data exchanges between terminal 2 and platform 3 are implemented using a computer network such as the Internet.
  • the platform 3 also allows the generation of certificates for the probe and the terminal, as will be described in more detail below.
  • the platform 3 comprises a processing unit comprising, for example, a computer (s), a microcomputer (s), a workstation (s), and / or other devices known to those skilled in the art. including processor (s), microcontroller (s), programmable logic controller (s), application specific integrated circuit (s), and / or other programmable circuits.
  • processor for example, a computer (s), a microcomputer (s), a workstation (s), and / or other devices known to those skilled in the art. including processor (s), microcontroller (s), programmable logic controller (s), application specific integrated circuit (s), and / or other programmable circuits.
  • the platform 3 also includes a storage unit comprising one (or more) memory (s) which can be a ROM / RAM memory, a USB key, a memory of a central server.
  • a storage unit comprising one (or more) memory (s) which can be a ROM / RAM memory, a USB key, a memory of a central server.
  • the processing unit can be integrated or separate from the storage unit. Furthermore, the various elements constituting the processing unit (respectively the storage unit) can be located at physically different positions on the scale of a building, a city, a country or a region. or several continents.
  • the storage unit In addition to storing data associated with the medical examination (medical data, control data, etc.), the storage unit also makes it possible to store programming code instructions intended to perform certain steps of the authentication process. described below.
  • probe 1 and the terminal 2 which each include a respective memory for the storage of programming code instructions for the implementation of the authentication method presented below.
  • the platform constitutes a certification authority making it possible to guarantee the origin of the certificates assigned to the probe on the one hand, and to the terminal on the other hand.
  • platform 3 is characterized by:
  • - a platform private key known only to the platform, and used to sign: the probe certificate assigned to the probe during its manufacture, and the terminal certificate assigned to the terminal when the customer subscribes to a customer account by the user.
  • the platform public key is saved: - in a memory of the probe 1 during the manufacture of the latter, and
  • a platform certificate containing: the platform public key, and a signature obtained from of the platform private key.
  • platform 3 Only platform 3 has the platform private key allowing:
  • the platform private key is stored only in the platform storage unit 3.
  • the probe 1 and the terminal 2 can verify the authenticity of the certificates sent by the platform 3 using the platform public key, and no software entity can substitute for the platform 3 to generate fraudulent certificates.
  • Probe 1 and platform 3 are resources belonging to the same trust space.
  • the probe 1 and the platform 3 are for example manufactured by the same organization, or belong to the same organization (same company or group of companies).
  • the platform 3 storage unit includes a table listing all of the probes 1 manufactured and / or belonging to the organization.
  • each probe 1 is characterized by:
  • the probe certificate includes in particular:
  • probe ID The probe ID, probe public and private keys, probe certificate, and platform public key are stored in probe memory during manufacture.
  • the probe ID, the probe public key and the probe certificate are stored in the probe table contained in the platform storage unit 3.
  • probe 1 Only probe 1 has the probe private key to decrypt messages encrypted from the probe public key. In other words, the probe's private key is stored only in the memory of probe 1.
  • Terminal 2 does not belong to the same organization. It is able to work with different probes 1. It belongs to a user who has a customer account with the platform 3 and which allows him to identify himself.
  • terminal ID When registering for a customer account, a terminal ID, terminal private key, terminal public key, and terminal certificate are generated.
  • the terminal public and private keys are generated by the terminal, while the certificate and terminal identifier are generated by the platform 3.
  • the terminal 2 when subscribing to a customer account, the terminal 2 generates public and private terminal keys.
  • the terminal public key is transmitted to the platform 3 in a subscription request message.
  • the subscription request message may also include the identifier of the probe intended to be combined with the terminal to carry out tests. exams.
  • This allows the platform to associate the terminal with a probe of the probe table contained in the storage unit. As will be described in more detail below, such an association eliminates the need for the probe or the terminal to transmit to the platform a session key generated following the identification protocol described below.
  • the identifier of the probe intended to be combined with the terminal for carrying out an examination can be sent to the platform after the subscription of a customer account, in particular a few minutes before the implementation of an examination.
  • the platform 3 In response to the subscription request message, the platform 3 generates a terminal identifier, and produces a terminal certificate including:
  • This certificate is sent to the terminal. It can be encrypted from the terminal public key.
  • the platform certificate including the platform public key is also sent to the terminal.
  • Terminal ID, terminal public and private keys, platform public key, and terminal certificate are stored in the memory of terminal 2.
  • Terminal ID, terminal public key, and terminal certificate are stored in the memory of terminal 2. kept in a table stored in the storage unit of platform 3.
  • the probe identifier In the event that the probe identifier is also transmitted to the platform, the latter stores the identifiers of the probe in a probe / terminal correspondence table and the terminal to be combined for the implementation of an examination session.
  • terminal public and private keys were generated by terminal 2:
  • terminal private key allows terminal 2 to decrypt the received messages that have been encrypted using the terminal public key
  • the terminal public key allows the entities holding the terminal certificate to encrypt the messages intended for the terminal.
  • the platform certificate and a terminal certificate were sent to terminal 2 by the remote platform, and stored in the terminal memory.
  • the platform certificate contains in particular the platform public key; this platform public key allows the terminal to verify the authenticity of the certificates produced by the platform, and possibly to encrypt the messages intended for platform 3.
  • the terminal certificate contains:
  • the terminal public key which allows the entities holding the terminal certificate to encrypt the messages intended for the terminal
  • the memory of the probe 1 contains: o the private key of the probe allowing the decryption of messages encrypted with the public key of the probe, o the platform public key, allowing to possibly encrypt the messages intended for the platform 3 and verify the authenticity of the signature of the certificates issued by the platform, and o the probe certificate containing:
  • the memory of terminal 2 contains: o the private key of the terminal making it possible to decrypt the messages encrypted with the public key of the terminal, o the platform certificate containing the public platform key, possibly making it possible to encrypt the messages intended for the platform 3 and to verify the authenticity of the signature of the certificates issued by the platform, and o the terminal certificate containing:
  • the platform 3 storage unit contains: o a probe table including the identifier of each probe 1 of the organization and the probe certificate associated with each probe identifier, o a terminal table including the identifier of each terminal 2 and the terminal certificate associated with each terminal identifier, o a probe / terminal correspondence table including the probe and terminal identifiers to be combined for the implementation of an examination session, o the platform private key used to sign certificates and decrypt messages encrypted with the platform public key.
  • the authentication process consists of two phases:
  • the user When the user wishes to carry out an examination, he enters on the input means of the terminal 2 information concerning the examination, and in particular the identifier of the probe intended to be used for the examination.
  • This information and other information such as:
  • exam data (date of acquisition of exam data, type of exam, etc.) are included in an exam request message.
  • This examination request message is sent to platform 3 which records it in the storage unit and updates the probe / terminal correspondence table by associating the probe and terminal identifiers with it.
  • the examination request message can be encrypted from the platform public key. This limits the risk of critical information being obtained by a malicious third party who has intercepted all communications, for example to impersonate terminal 2.
  • Platform 3 verifies that the user has rights to use the system according to the terminal identifier. If the user has user rights, the platform issues a pairing authorization message, otherwise, the platform issues an error message prohibiting pairing.
  • the authorization message sent by the platform 3 can be encrypted using the terminal public key. Encrypting the authorization message using the terminal's public key avoids the risk of fraudulent interception of system-critical information, which is encrypted and therefore unusable as it is. This also allows the platform to ensure that the terminal 2 that generated the request and that the terminal associated with the identifier contained in the request do indeed constitute a single entity (only the terminal whose identifier has been indicated in the request with the private terminal key enabling the platform message to be decrypted).
  • the first dialogue phase 100 allows the probe 1 to authenticate the terminal 2.
  • the terminal 2 sends 110 a pairing request to the probe 1.
  • This pairing request contains the terminal certificate that will be used by the probe 1 to verify that the terminal is indeed an entity of trust.
  • Probe 1 receives 120 the pairing request, and extracts the terminal certificate.
  • Probe 1 verifies 130 the authenticity of the terminal certificate by comparing the signature of the terminal certificate to the platform public key stored in memory during its manufacture.
  • the probe 1 extracts 140 the terminal public key contained in the terminal certificate, and stores it in its internal memory. This terminal key will be used to generate a “session key” as will be described in more detail below. If the terminal certificate is not genuine, an error message is issued 135.
  • Probe 1 generates verification information (eg, a random sequence of digits), encrypts it using the terminal public key, and integrates it into a response message. This response message is sent 150 by the probe 1 to the terminal 2.
  • verification information eg, a random sequence of digits
  • Terminal 2 receives 160 the response message, and decrypts the verification information using the terminal private key.
  • This terminal private key known only to terminal 2, is the only one able to decrypt the verification information. Indeed, as recalled in point 1.1.1, in the case of asymmetric encryption, information encrypted using a public key cannot be decrypted using this same public key: only the private key associated with this public key can be used to decrypt this information.
  • Terminal 2 integrates the verification information into a confirmation message.
  • the confirmation message is sent 170 by terminal 2 to probe 1.
  • the probe 1 receives 180 the confirmation message and extracts the verification information from the confirmation message.
  • the probe then compares 190:
  • the probe 1 sends 200 an authentication validation message to the terminal 2.
  • the second dialogue phase 300 can be implemented.
  • probe 1 issues an error message 195 and refuses the pairing between probe 1 and terminal 2.
  • the first dialogue phase 100 therefore allows the probe to authenticate terminal 2 using the terminal certificate including the terminal public key:
  • the verification of the signature of this certificate - using the platform public key - allows the probe to confirm that the certificate was issued by a trusted authority (i.e. the platform),
  • the second dialogue phase 300 allows terminal 2 to authenticate probe 1.
  • the terminal 2 sends 310 a certificate request message to the probe 1.
  • the probe 1 receives 320 the certificate request message, and generates a result message including the probe certificate.
  • the result message can be encrypted using the terminal public key in order to limit the risks of interception of the information it contains by a fraudulent third party entity.
  • Probe 1 sends 330 the result message to terminal 2
  • Terminal 2 receives the result message, decrypts it and extracts the probe certificate. Terminal 2 verifies 340 the authenticity of the probe certificate by comparing the signature of the probe certificate to the platform public key stored in memory when subscribing to the customer account.
  • the terminal 1 extracts 350 the probe public key contained in the probe certificate, and saves it in its internal memory. This probe key will be used to generate the "session key”. If the terminal certificate is not genuine, an error message is issued 345.
  • Terminal 2 generates verification information (eg, a random sequence of digits), encrypts the verification information using the probe public key, and integrates it into a justification message.
  • This justification message is sent 360 by terminal 2 to probe 1.
  • Probe 1 receives 370 the justification message, and decrypts the verification information using the private probe key known only to probel.
  • the probe 1 integrates the verification information into a proof message.
  • the proof message is sent 380 by the probe to terminal 2.
  • the terminal 390 receives the proof message and extracts the verification information from the proof message.
  • the terminal then compares 400:
  • the terminal 2 sends 410 an authentication validation message to the probe 1.
  • the probe and the terminal are paired.
  • terminal 2 sends 405 an error message and refuses the pairing between probe 1 and terminal 2.
  • probe 1 and terminal 2 are paired.
  • a pairing confirmation message can be sent by probe 1 or terminal 2 to platform 3.
  • Each entity in the system then generates the session key from the probe and terminal public keys. Indeed, the public keys of probe and terminal are stored:
  • the public probe key is recorded during the manufacture of the probe, and the public terminal key is recorded during the implementation of the first dialogue phase 100
  • - in the terminal's memory the public probe key is recorded in the memory of terminal 2 when the second dialogue phase is implemented, and the terminal's public key is stored in the terminal's memory during subscription customer account
  • the public probe and terminal keys are contained in the probe and terminal tables, and the probe / terminal correspondence table is used to define which probe is associated with each terminal).
  • the same session key is generated independently by the probe, the terminal and the platform. This session key is therefore not transmitted between the different entities, which limits the subsequent risks of fraud.
  • the session key is used to encrypt / decrypt the data exchanged according to a symmetric cryptography mode (the session key is used both to encrypt and decrypt the data).
  • the session key will be used during the implementation of the exam to:
  • the period of validity of the session key depends on the type of application concerned. It can be a few tens of minutes for an examination for a patient, or several hours / days for an imaging session in an emergency vehicle (on the move).
  • the session key being unique for each examination (so if several successive examinations are carried out by the same user for the same patient, there is no risk of confusion in the data associated with these different exams, the correspondence between the session key and the exam being one-to-one).
  • the public and private probe keys can be used for the exchange of sensitive information between the platform 3 and the probe 1, via the terminal 2, without the terminal having access to this sensitive information.
  • This sensitive information consists for example of instructions for controlling the probe.
  • the probe configuration sequence (s) (for data acquisition in the context of the examination) cannot be sent directly from platform 3 to probe 1, in particular because of the limited memory capacity of probe 1.
  • terminal 2 can be used to store this (or these) sequence (s), and to transmit it (or them) sequentially by piece to probe 1.
  • By encrypting asymmetrically these control instructions using the public and private probe keys it is possible to transmit them via the terminal without the latter being able to have access to them.
  • the fact that the terminal cannot access asymmetrically encrypted driving instructions ensures the integrity of the data driving the delivery of ultrasound energy to the patient's biological tissues.
  • the end of the exam can be programmed by the user using the terminal 2.
  • the terminal 2 sends to the probe 1 and to the platform 3 an end of exam command message. If certain medical data relating to the examination have not been acquired by probe 1 and / or have not been processed by platform 3, probe 1 and platform 3 can send an acceptance message indicating that the end of examination order has been taken into account and that it will be effective as soon as the acquisition and / or processing of medical data by probe 1 and / or platform 3 is finalized.

Landscapes

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

Abstract

L'invention concerne un procédé de gestion des échanges de données entre : - une sonde (1) comportant une mémoire contenant un certificat numérique de sonde incluant une clé publique de sonde, - un terminal (2) comportant une mémoire contenant un certificat numérique de terminal incluant une clé publique de terminal, - une plateforme (3) distante configurée pour : o délivrer le certificat numérique de sonde à la sonde, o délivrer le certificat numérique de terminal au terminal, remarquable en ce que le procédé comprend la mise en œuvre d'une procédure d'authentification composé des phases suivantes : - une première phase dans laquelle la sonde vérifie l'identité du terminal à partir du certificat numérique de terminal, - une deuxième phase dans laquelle le terminal vérifie l'identité de la sonde à partir du certificat numérique de sonde, et - une troisième phase dans laquelle la sonde, le terminal et la plateforme génèrent chacun une clé de session identique à partir des clés publiques de sonde et de terminal.

Description

PROCEDE ET SYSTEME DE GESTION D’ECHANGE DE DONNEES DANS LE
CADRE D’UN EXAMEN MEDICAL
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.
PRESENTATION GENERALE DE L’ART ANTERIEUR
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èmes représentatifs 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.
PRESENTATION 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, ladite sonde comportant une mémoire contenant un certificat numérique de sonde incluant une clé publique de sonde,
- un terminal apte à communiquer avec la sonde par l’intermédiaire de moyens de communication avec ou sans fil, ledit terminal comportant une mémoire contenant un certificat numérique de terminal incluant une clé publique de terminal,
- une plateforme distante apte à communiquer avec le terminal par l’intermédiaire d’un réseau informatique tel qu’internet, ladite plateforme étant configurée pour : o délivrer le certificat numérique de sonde à la sonde, o délivrer le certificat numérique de terminal au terminal, remarquable en ce que le procédé comprend, préalablement à la mise en oeuvre de la procédure d’examen, la mise en oeuvre d’une procédure d’authentification comprenant les phases suivantes :
- une première phase dans laquelle la sonde vérifie l’identité du terminal à partir du certificat numérique de terminal, et
- une deuxième phase dans laquelle le terminal vérifie l’identité de la sonde à partir du certificat numérique de sonde
- une troisième phase dans laquelle la sonde, le terminal et la plateforme génèrent chacun une clé de session identique (de manière indépendante), ladite clé de session étant produite à partir des clés publiques de sonde et de terminal (et n’étant pas transmise entre la sonde le terminal et la plateforme).
Cette clé de session est utilisée pour chiffrer symétriquement des données de session transmises entre la sonde, le terminal et la plateforme une fois la procédure d’authentification achevée.
Dans le cadre de la présente invention, les données de session échangées peuvent consister en :
- des données système incluant : o des données de commande (i.e. instructions de pilotage) de la sonde et/ou du terminal et/ou de la plateforme, et/ou o des données de contrôle de la sonde et/ou du terminal et/ou de la plateforme ;
- des données médicales incluant : o des données médicales acquises (et/ou prétraitées) par la sonde, et/ou o 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 en utilisant la clé de session. L’information contenue dans ces données de session est donc accessible par les trois entités du système.
Des aspects préférés, mais non limitatifs de l’invention sont les suivants :
- la clé de session identique est générée indépendamment par la sonde, le terminal et la plateforme, les clés publiques de sonde et de terminal étant stockées respectivement :
- dans la mémoire de la sonde,
- dans la mémoire du terminal, et
- dans une unité de stockage de la plateforme de sorte que ladite clé de session n’est pas échangée entre la sonde, le terminal et la plateforme via les moyens de communication et/ou le réseau informatique ;
- la clé de session est utilisée pour chiffrer selon un mode de cryptographie symétrique des données échangées entre la sonde, le terminal et la plateforme durant la mise en oeuvre de l’examen ;
- la première phase comprend les étapes suivantes :
- émission par le terminal d’une requête d’appairage, la requête d’appairage contenant le certificat numérique de terminal,
- réception par la sonde de la requête d’appairage et extraction du certificat numérique de terminal,
- vérification par la sonde du certificat numérique de terminal en attestant l’authenticité dudit certificat numérique de terminal grâce à une clé publique de plateforme contenue dans la mémoire de la sonde ;
- la première phase comprend en outre les étapes suivantes :
- si le certificat numérique de terminal est authentique, alors échange d’informations de vérification entre la sonde et le terminal, lesdites informations de vérification étant successivement chiffrées et déchiffrées en utilisant la clé publique de terminal et une clé privée de terminal stockée dans la mémoire du terminal,
- si le certificat numérique de terminal n’est pas authentique, alors émission, par la sonde, d’un message d’alarme. - l’étape d’échange d’informations de vérification comprend les sous-étapes consistant en : o l'extraction, par la sonde, de la clé publique de terminal contenue dans le certificat numérique de terminal, o la génération, par la sonde, d’une information de vérification, o le chiffrage asymétrique, par la sonde, de l’information de vérification avec la clé publique de terminal, o l’envoi, par la sonde, d’un message de réponse incluant l’information de vérification chiffrée avec la clé publique de terminal, o la réception, par le terminal, du message de réponse et le déchiffrage de l’information de vérification en utilisant une clé privée de terminal stockée dans la mémoire du terminal, o l’envoi, par le terminal, d’un message de confirmation contenant l’information de vérification déchiffrée, o la réception, par la sonde, du message de confirmation, o la comparaison, par la sonde, de l’information de vérification déchiffrée contenue dans le message de confirmation avec l’information de vérification contenue dans le message de réponse émis par la sonde, pour définir si lesdites informations de vérification sont identiques ou différentes, et o si les informations de vérification sont identiques, émission d’un message de validation représentatif d’une authentification réussie, o si les informations de vérification sont différentes, émission d’un message d’alarme représentatif d’une authentification échouée.
- la deuxième phase comprend les étapes suivantes :
- réception, par le terminal, d’un message de résultat émis par la sonde, le message de résultat intégrant le certificat numérique de sonde,
- extraction, par le terminal, du certificat numérique de sonde,
- vérification par le terminal de l’authenticité du certificat numérique de sonde en comparant la signature dudit certificat numérique de terminal à une clé publique de plateforme contenue dans la mémoire du terminal ;
- la deuxième phase comprend en outre les étapes suivantes :
- si le certificat numérique de sonde est authentique, alors échange d’informations de vérification entre la sonde et le terminal, lesdites informations de vérification étant successivement chiffrées et déchiffrées en utilisant la clé publique de sonde et une clé privée de sonde stockée dans une mémoire de la sonde,
- si le certificat numérique de sonde n’est pas authentique, alors émission, par le terminal, d’un message d’alarme ;
- l’étape d’échange d’informations de vérification comprend les sous-étapes consistant en : o l'extraction, par le terminal, de la clé publique de sonde contenue dans le certificat numérique de sonde, o la génération, par le terminal, d’une information de vérification, o le chiffrage asymétrique, par le terminal, de l’information de vérification en utilisant la clé publique de sonde, o l’envoi, par le terminal, d’un message de justification incluant l’information de vérification chiffrée avec la clé publique de sonde, o la réception, par la sonde, du message de justification et le déchiffrage de l’information de vérification en utilisant une clé privée de sonde stockée dans la mémoire de la sonde, o l’envoi, par la sonde, d’un message de preuve contenant l’information de vérification déchiffrée, o la réception, par le terminal, du message de preuve, o la comparaison, par le terminal, de l’information de vérification contenue dans le message de preuve avec l’information de vérification contenue dans le message de justification émis par le terminal, pour définir si lesdites informations de vérification sont identiques ou différentes, et o si les informations de vérification sont identiques, émission d’un message de validation représentatif d’une authentification réussie, o si les informations de vérification sont différentes, émission d’un message d’alarme représentatif d’une authentification échouée ;
- le procédé comprend, préalablement à la mise en oeuvre d’une procédure d’authentification, une procédure de souscription dans laquelle :
- le terminal envoie à la plateforme un message de demande d’examen incluant un identifiant de sonde, un identifiant de terminal, et la clé publique de terminal, - la plateforme envoie au terminal un message d’autorisation d’appairage incluant un certificat de plateforme incluant une clé publique de plateforme et un certificat de terminal incluant la clé publique de terminal.
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, ladite sonde comportant une mémoire contenant un certificat numérique de sonde incluant une clé publique de sonde,
- un terminal apte à communiquer avec la sonde par l’intermédiaire de moyens de communication avec ou sans fil, ledit terminal comportant une mémoire contenant un certificat numérique de terminal incluant une clé publique de terminal,
- une plateforme distante apte à communiquer avec le terminal par l’intermédiaire d’un réseau informatique tel qu’internet, ladite plateforme étant configurée pour : o délivrer le certificat numérique de sonde à la sonde, o délivrer le certificat numérique de terminal au terminal, remarquable en ce que la sonde, le terminal et la plateforme comprennent des moyens adaptés pour la mise en oeuvre d’une procédure d’authentification, préalablement à la mise en oeuvre de la procédure d’examen, la procédure d’authentification comprenant les phases suivantes :
- une première phase dans laquelle la sonde vérifie l’identité du terminal à partir du certificat numérique de terminal, et
- une deuxième phase dans laquelle le terminal vérifie l’identité de la sonde à partir du certificat numérique de sonde,
- une troisième phase dans laquelle la sonde, le terminal et la plateforme génèrent chacun une clé de session identique, ladite clé de session étant produite à partir des clés publiques de sonde et de terminal.
Avantageusement, la sonde, le terminal et la plateforme comprennent des moyens pour la mise en oeuvre des phases, étapes et sous-étapes du procédé de gestion défini ci-dessus. PRESENTATION DES FIGURES
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 :
- la figure 1 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,
- la figure 2 est une représentation schématique d’une première phase de dialogue entre une sonde et un terminal, ladite première phase étant mise en oeuvre lors d’une procédure d’authentification,
- la figure 3 est une représentation schématique d’une deuxième phase de dialogue entre la sonde et le terminal, la deuxième phase étant mise en oeuvre lors de la procédure d’authentification.
DESCRIPTION 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.
1.1.1. Principe de chiffrement svmétriaue/asvmétrigue
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.
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.1.2. Principe de chiffrement par Certificats
Un inconvénient de l’utilisation de la technique de chiffrement asymétrique vient de la transmission de la clé publique. Si celle-ci n'est pas sécurisée, une entité tiers malveillante peut se positionner entre une entité de confiance et son public en diffusant de fausses clés publiques (par le biais d'un faux site web par exemple) puis intercepter toutes les communications, lui permettant d'usurper l'identité de l’entité de confiance. Ce type d’attaque est notamment connue sous le nom « d’attaque de l'hcmme du milieu ».
C’est pourquoi dans le cadre de la présente invention, le procédé et le système décrits dans la suite sont basés sur l’utilisation de certificats électroniques qui sont mieux adaptés aux besoins de l’application visée. En effet, comme il ressortira dans la suite, l’invention met en oeuvre 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, un certificat électronique (aussi appelé « certificat numérique » ou « certificat de clé publique ») constitue une « carte d'identité numérique » utilisée pour :
- identifier et authentifier une entité, mais aussi pour
- chiffrer des échanges de données.
Un certificat électronique est composé d’un ensemble de données contenant :
- une (ou plusieurs) clé(s) publique(s),
- des informations d'identification de l’entité associée au certificat (par exemple : nom, localisation, adresse électronique de l’entité ayant émis le certificat) ;
- au moins une signature construite à partir d’une clé privée de l’entité ayant générée le certificat ; ainsi, l'entité signataire est la seule autorité permettant de prêter confiance (ou non) à l'exactitude des informations du certificat.
Un tel certificat électronique est donc :
- infalsifiable : il est chiffré pour empêcher toute modification.
- nominatif : il est délivré à une entité et constitue la carte d’identité numérique de cette entité,
- certifié : il est signé par l’entité qui l’a délivré.
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 oeuvre 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ée 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 oeuvre en utilisant un réseau informatique tel qu’internet.
1.2.3. Plateforme distante
La plateforme 3 permet :
- la mise en oeuvre 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 permet en outre la génération de certificats pour la sonde et le terminal, comme il sera décrit plus en détails dans la suite.
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 oeuvre du procédé d’authentification présenté ci-dessous.
1.3. Cercles de confiance
La plateforme constitue une autorité de certification permettant de garantir l’origine des certificats attribués à la sonde d’une part, et au terminal d’autre part.
Plus précisément, la plateforme 3 est caractérisée par :
- une clé publique de plateforme, connue de la sonde et du terminal
- une clé privée de plateforme connue uniquement de la plateforme, et utilisée pour signer : le certificat de sonde attribué à la sonde lors de sa fabrication, et le certificat de terminal attribué au terminal lors de la souscription d’un compte client par l’utilisateur.
La clé publique de plateforme est enregistrée : - dans une mémoire de la sonde 1 lors de la fabrication de celle-ci, et
- dans une mémoire du terminal 2 lors de la souscription d’un compte client par l’utilisateur, par exemple suite à la transmission par la plateforme d’un certificat de plateforme contenant : la clé publique de plateforme, et une signature obtenue à partir de la clé privée de plateforme.
Seule la plateforme 3 dispose de la clé privée de plateforme permettant :
- de signer les certificats adressés à la sonde et au terminal, et
- de déchiffrer les messages chiffrés à partir de la clé publique de plateforme.
En d’autres termes, la clé privée de plateforme est stockée uniquement dans l’unité de stockage de la plateforme 3.
Ainsi, la sonde 1 et le terminal 2 peuvent vérifier l’authenticité des certificats adressés par la plateforme 3 en utilisant la clé publique de plateforme, et aucune entité logiciel ne peut se substituer à la plateforme 3 pour générer des certificats frauduleux.
1.3.1. Premier cercle de confiance et certificat
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),
- une clé privée de sonde connue,
- une clé publique de sonde permettant de chiffrer des messages à l’attention de la sonde 1 , et
- un certificat de sonde produit par la plateforme 3. Le certificat de sonde comprend notamment :
- un identifiant de sonde,
- la clé publique de sonde, et
- une signature obtenue à partir de la clé privée de plateforme.
L’identifiant de sonde, les clés publique et privée de sonde, le certificat de sonde et la clé publique de plateforme sont stockés dans une mémoire de la sonde lors de sa fabrication.
L’identifiant de sonde, la clé publique de sonde et le certificat 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.
1.3.2. Deuxième cercle de confiance et certificat
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, une clé publique de terminal et un certificat de terminal sont générés. Les clés publique et privée de terminal sont générées par le terminal, tandis que le certificat et l’identifiant de terminal sont générés par la plateforme 3.
Plus précisément, lors de la souscription d’un compte client, le terminal 2 génère des clés publique et privée de terminal. La clé publique de terminal est transmise à la plateforme 3 dans un message de demande de souscription. Dans l’hypothèse où l’utilisateur du terminal 2 dispose d’une sonde 1 avec laquelle il souhaite effectuer un examen, le message de demande de souscription peut également comprendre l’identifiant de la sonde destinée à être combinée avec le terminal pour réaliser des examens. Ceci permet à la plateforme d’associer le terminal à une sonde de la table de sonde contenue dans l’unité de stockage. Comme il sera décrit plus en détail dans la suite, une telle association permet de s’affranchir de la nécessité pour la sonde ou le terminal de transmettre à la plateforme une clé de session générée suite au protocole d’identification décrit ci-dessous. Dans l’hypothèse où l’utilisateur du terminal 2 ne dispose pas de sonde 1 au moment de la souscription, ou s’il possède plusieurs sondes, l’identifiant de la sonde destinée à être combinée au terminal pour la réalisation d’un examen peut être envoyée à la plateforme postérieurement à la souscription d’un compte client, notamment quelques minutes avant la mise en oeuvre d’un examen.
En réponse au message de demande de souscription, la plateforme 3 génère un identifiant de terminal, et produit un certificat de terminal incluant :
- l’identifiant de terminal,
- la clé publique de terminal, et
- une signature obtenue à partir de la clé privée de plateforme.
Ce certificat est envoyé au terminal. Il peut être chiffré à partir de la clé publique de terminal. Le certificat de plateforme incluant la clé publique de plateforme est également envoyé au terminal.
L’identifiant de terminal, les clés publique et privée de terminal, la clé publique de plateforme et le certificat de terminal sont stockés dans la mémoire du terminal 2. L’identifiant de terminal, la clé publique de terminal et le certificat de terminal sont conservés dans une table stockée dans l’unité de stockage de la plateforme 3. Dans l’hypothèse où l’identifiant de sonde est également transmis à la plateforme, celle-ci stocke dans une table de correspondance sonde/terminal les identifiants de la sonde et du terminal devant être combinés pour la mise en oeuvre d’une session d’examen.
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. 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, des clés publique et privée de terminal ont été générées par le terminal 2 :
- la clé privée de terminal permet au terminal 2 de déchiffrer les messages reçus ayant été chiffrés en utilisant la clé publique de terminal,
- la clé publique de terminal permet aux entités détenant le certificat de terminal de chiffrer les messages à destination du terminal.
Également lors de l’opération d’enregistrement, le certificat de plateforme et un certificat de terminal ont été envoyés au terminal 2 par la plateforme distante, et stockés dans la mémoire du terminal. Le certificat de plateforme contient notamment la clé publique de plateforme ; cette clé publique de plateforme permet au terminal de vérifier l’authenticité des certificats produits par la plateforme, et éventuellement de chiffrer les messages à destination de la plateforme 3. Le certificat de terminal contient :
- l’identifiant du terminal,
- la clé publique de terminal qui permet aux entités détenant le certificat de terminal de chiffrer les messages à destination du terminal,
- une signature obtenue à partir de la clé privée de plateforme ; cette signature permet d’authentifier la plateforme en tant qu’entité de certification ayant généré le certificat
Comme indiqué ci-dessus :
- la mémoire de la sonde 1 contient : o la clé privée de sonde permettant de déchiffrer des messages chiffrés avec la clé publique de sonde, o la clé publique de plateforme, permettant d’éventuellement chiffrer les messages à destination de la plateforme 3 et de vérifier l’authenticité de la signature des certificats émis par la plateforme, et o le certificat de sonde contenant :
- l’identifiant de sonde,
- la clé publique de sonde, - une signature obtenue à partir de la clé privée de plateforme ;
- la mémoire du terminal 2 contient : o la clé privée de terminal permettant de déchiffrer les messages chiffrés avec la clé publique de terminal, o le certificat de plateforme contenant la clé publique de plateforme, permettant d’éventuellement chiffrer les messages à destination de la plateforme 3 et de vérifier l’authenticité de la signature des certificats émis par la plateforme, et o le certificat de terminal contenant :
- l’identifiant de terminal,
- la clé publique de terminal,
- une signature obtenue à partir de la clé privée de plateforme ;
- l’unité de stockage de la plateforme 3 contient : o une table de sonde incluant l’identifiant de chaque sonde 1 de l’organisation et le certificat de sonde associé à chaque identifiant de sonde, o une table de terminal incluant l’identifiant de chaque terminal 2 et le certificat de terminal associé à chaque identifiant de terminal, o une table de correspondance sonde/terminal incluant les identifiants de sonde et de terminal devant être combinés pour la mise en oeuvre d’une session d’examen, o la clé privée de plateforme permettant de signer les certificats et de déchiffrer les messages chiffrés avec la clé publique de plateforme.
Le procédé d’authentification comprend deux phases :
- une première phase de dialogue 100 entre le terminal 2 et la sonde 1 pour permettre à la sonde d’authentifier le terminal, et
- une deuxième phase de dialogue 300 entre le terminal 2 et la sonde 1 pour permettre au terminal d’authentifier la sonde.
2.1. Préalable à la mise en œuyre du procédé d’authentification
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 de la sonde destinée à être utilisée pour l’examen. Ces renseignements et d’autres informations telles que :
- l’identifiant du terminal,
- des données personnelles relatives au patient (nom, prénom, numéro de dossier, etc.), et/ou
- des données relatives à l’examen (date d’acquisition des données d’examen, type d’examen, etc.) sont intégrés à un message de demande d’examen.
Ce message de demande d’examen est envoyé à la plateforme 3 qui l’enregistre dans l’unité de stockage et met à jour la table de correspondance sonde/terminal en y associant les identifiants de sonde et de terminal.
Avantageusement, le message de demande d’examen peut être chiffré à 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 plateforme 3 vérifie que l’utilisateur dispose de droits d’utilisation du système en fonction de l’identifiant de terminal. Si l’utilisateur dispose de droits d’utilisation, la plateforme émet un message d’autorisation d’appairage, sinon, la plateforme émet un message d’erreur interdisant l’appairage.
Avantageusement, le message d’autorisation émis par la plateforme 3 peut être chiffré en utilisant la clé publique de terminal. Le fait de chiffrer le message d’autorisation 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).
Lorsque le terminal a reçu le message d’autorisation, la sonde 1 et le terminal 2 mettent en oeuvre la première phase de dialogue 100. 2.2. Première phase de dialogue
Comme indiqué précédemment, la première phase de dialogue 100 permet à la sonde 1 d’authentifier le terminal 2.
Dans une première étape, le terminal 2 émet 110 une requête d’appairage à destination de la sonde 1. Cette requête d’appairage contient le certificat de terminal qui va être utilisé par la sonde 1 pour vérifier que le terminal est bien une entité de confiance.
La sonde 1 reçoit 120 la requête d’appairage, et en extrait le certificat de terminal.
La sonde 1 vérifie 130 l’authenticité du certificat de terminal en comparant la signature du certificat de terminal à la clé publique de plateforme stockée en mémoire lors de sa fabrication.
Si le certificat de terminal est authentique, la sonde 1 extrait 140 la clé publique de terminal contenue dans le certificat de terminal, et l’enregistre dans sa mémoire interne. Cette clé de terminal sera utilisée pour générer une « clé de session » comme il sera décrit plus en détails dans la suite. Si le certificat de terminal n’est pas authentique, un message d’erreur est émis 135.
La sonde 1 génère des informations de vérification (par exemple une suite de chiffres aléatoire), les chiffre en utilisant la clé publique de terminal, et les intègre à un message de réponse. Ce message de réponse est envoyé 150 par la sonde 1 à destination du terminal 2.
Le terminal 2 reçoit 160 le message de réponse, et déchiffre les informations de vérification en utilisant la clé privée de terminal. Cette clé privée de terminal, connue uniquement du terminal 2, est la seule pouvant déchiffrer les informations de vérification. En effet, comme rappelé au point 1.1.1 , dans le cas d’un chiffrement asymétrique, des informations chiffrées à l’aide d’une clé publique ne peuvent pas être déchiffrées à l’aide de cette même clé publique : seule la clé privée associée à cette clé publique permet de déchiffrer ces informations.
Le terminal 2 intègre les informations de vérification à un message de confirmation. Le message de confirmation est envoyé 170 par le terminal 2 à destination de la sonde 1.
La sonde 1 reçoit 180 le message de confirmation et extrait les informations de vérification du message de confirmation.
La sonde compare 190 ensuite :
- les informations de vérification du message de confirmation,
- aux informations de vérification contenues dans le message de réponse émis par la sonde 1.
Si la comparaison est positive (informations de vérification des messages de confirmation et de réponse concordantes), la sonde 1 émet 200 un message de validation d’authentification à destination du terminal 2. La deuxième phase de dialogue 300 peut être mise en oeuvre.
Si la comparaison est négative (informations de vérification des messages de confirmation et de réponse non concordantes), la sonde 1 émet 195 un message d’erreur et refuse l’appairage entre la sonde 1 et le terminal 2.
La première phase de dialogue 100 permet donc à la sonde d’authentifier le terminal 2 grâce au certificat de terminal incluant la clé publique de terminal :
- la vérification de la signature de ce certificat - à l’aide de la clé publique de plateforme - permet à la sonde de confirmer que le certificat a été émis par une autorité de confiance (i.e. la plateforme),
- l’échange d’informations de vérifications chiffrée à partir de la clé publique de terminal permet de confirmer que l’entité lui ayant adressé ce certificat est bien l’entité pour laquelle ce certificat a été produit par l’autorité de confiance. 2.3. Deuxième phase de dialogue
Comme indiqué précédemment, la deuxième phase de dialogue 300 permet au terminal 2 d’authentifier la sonde 1.
Dans une première étape, le terminal 2 émet 310 un message de demande de certificat à destination de la sonde 1.
La sonde 1 reçoit 320 le message de demande de certificat, et génère un message de résultat intégrant le certificat de sonde. Avantageusement, le message de résultat peut être chiffré en utilisant la clé publique de terminal afin de limiter les risques d’interception des informations qu’il contient par une entité tiers frauduleuse.
La sonde 1 envoie 330 le message de résultat à destination du terminal 2
Le terminal 2 reçoit le message résultat, le déchiffre et extrait le certificat de sonde. Le terminal 2 vérifie 340 l’authenticité du certificat de sonde en comparant la signature du certificat de sonde à la clé publique de plateforme stockée en mémoire lors de la souscription du compte client.
Si le certificat de sonde est authentique, le terminal 1 extrait 350 la clé publique de sonde contenue dans le certificat de sonde, et l’enregistre dans sa mémoire interne. Cette clé de sonde sera utilisée pour générer la « clé de session ». Si le certificat de terminal n’est pas authentique, un message d’erreur est émis 345.
Le terminal 2 génère des informations de vérification (par exemple une suite de chiffres aléatoire), chiffre les informations de vérification en utilisant la clé publique de sonde, et les intègre à un message de justification. Ce message de justification est envoyé 360 par le terminal 2 à destination de la sonde 1.
La sonde 1 reçoit 370 le message de justification, et déchiffre les informations de vérification en utilisant la clé privée de sonde connue uniquement de la sondel . La sonde 1 intègre les informations de vérification dans un message de preuve. Le message de preuve est envoyé 380 par la sonde au terminal 2.
Le terminal reçoit 390 le message de preuve et extrait les informations de vérification du message de preuve.
Le terminal compare 400 ensuite :
- les informations de vérification du message de preuve,
- aux informations de vérification contenues dans le message de justification préalablement émis par le terminal 2.
Si la comparaison est positive (informations de vérification des messages de confirmation et de réponse concordantes), le terminal 2 émet 410 un message de validation d’authentification à destination de la sonde 1. La sonde et le terminal sont appairés.
Si la comparaison est négative (informations de vérification des messages de confirmation et de réponse non concordantes), le terminal 2 émet 405 un message d’erreur et refuse l’appairage entre la sonde 1 et le terminal 2.
3. Examen
Une fois les première et deuxième phases de dialogue 100, 300 effectuées et l’authentification réussie, la sonde 1 et le terminal 2 sont appairés. Un message de confirmation d’appairage peut être envoyé par la sonde 1 ou le terminal 2 à destination de la plateforme 3.
Chaque entité du système génère alors la clé de session à partir des clés publiques de sonde et de terminal. En effet, les clés publiques de sonde et de terminal sont stockées :
- dans la mémoire de la sonde (la clé publique de sonde est enregistrée lors de la fabrication de la sonde, et la clé publique de terminal est enregistrée lors de la mise en oeuvre de la première phase de dialogue 100), - dans la mémoire du terminal (la clé publique de sonde est enregistrée dans la mémoire du terminal 2 lors de la mise en oeuvre de la deuxième phase de dialogue, et la clé publique de terminal est enregistrée dans la mémoire du terminal lors de la souscription du compte client)
- dans l’unité de stockage de la plateforme (les clés publiques de sonde et de terminal sont contenues dans les tables de sonde et de terminal, et la table de correspondance sonde/terminal permet de définir quelle sonde est associée à chaque terminal).
Ainsi une même clé de session est générée indépendamment par la sonde, le terminal et la plateforme. Cette clé de session n’est donc pas transmise entre les différentes entités, ce qui limite les risques ultérieurs de fraude.
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 sera utilisée durant la mise en oeuvre 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,
- chiffrer/déchiffrer les messages adressés à/reçus de la plateforme 3.
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é).
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).
Avantageusement, les clés publique et privée de sonde peuvent être utilisées pour l’échange d’informations sensibles entre la plateforme 3 et la sonde 1 , via le terminal 2, sans que le terminal n’ait accès à ces informations sensibles. Ces informations sensibles consistent par exemple en des 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 3 vers la sonde 1 , notamment du fait de la capacité mémoire limitée de la sonde 1. C’est pourquoi le terminal 2 peut être utilisé pour stocker cette (ou ces) séquence(s), et pour la (ou les) transmettre séquentiellement par morceau à la sonde 1. En chiffrant asymétriquement ces instructions de pilotage à l’aide des clés publique et privée de sonde, il est possible de les transmettre via le terminal sans que celui-ci ne puisse y avoir accès. Le fait que le terminal ne puisse accéder aux instructions de pilotage chiffrées asymétriquement (à partir des clés publique et privée de sonde) permet de garantir l’intégrité des données pilotant la dépose d’énergie ultrasonore aux tissus biologiques du patient.
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érentes entités authentifiées 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 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

REVENDICATIONS
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, ladite sonde comportant une mémoire contenant un certificat numérique de sonde incluant une clé publique de sonde,
- un terminal (2) apte à communiquer avec la sonde par l’intermédiaire de moyens de communication avec ou sans fil, ledit terminal comportant une mémoire contenant un certificat numérique de terminal incluant une clé publique de terminal,
- une plateforme (3) distante apte à communiquer avec le terminal par l’intermédiaire d’un réseau informatique tel qu’internet, ladite plateforme étant configurée pour : o délivrer le certificat numérique de sonde à la sonde, o délivrer le certificat numérique de terminal au terminal, caractérisé en ce que le procédé comprend, préalablement à la mise en oeuvre de la procédure d’examen, la mise en oeuvre d’une procédure d’authentification comprenant les phases suivantes :
- une première phase dans laquelle la sonde vérifie l’identité du terminal à partir du certificat numérique de terminal, et
- une deuxième phase dans laquelle le terminal vérifie l’identité de la sonde à partir du certificat numérique de sonde
- une troisième phase dans laquelle la sonde, le terminal et la plateforme génèrent chacun une clé de session identique, ladite clé de session étant produite à partir des clés publiques de sonde et de terminal.
2. Procédé de gestion selon la revendication 1 , dans lequel la clé de session identique est générée indépendamment par la sonde, le terminal et la plateforme, les clés publiques de sonde et de terminal étant stockées respectivement :
- dans la mémoire de la sonde,
- dans la mémoire du terminal, et
- dans une unité de stockage de la plateforme de sorte que ladite clé de session n’est pas échangée entre la sonde, le terminal et la plateforme via les moyens de communication et/ou le réseau informatique.
3. Procédé de gestion selon l’une quelconque des revendication 1 ou 2, dans lequel la clé de session est utilisée pour chiffrer selon un mode de cryptographie symétrique des données échangées entre la sonde, le terminal et la plateforme durant la mise en oeuvre de l’examen.
4. Procédé de gestion selon l’une quelconque des revendications 1 à 3, dans lequel la première phase comprend les étapes suivantes :
- émission par le terminal d’une requête d’appairage, la requête d’appairage contenant le certificat numérique de terminal,
- réception par la sonde de la requête d’appairage et extraction du certificat numérique de terminal,
- vérification par la sonde du certificat numérique de terminal en attestant l’authenticité dudit certificat numérique de terminal grâce à une clé publique de plateforme contenue dans la mémoire de la sonde.
5. Procédé de gestion selon la revendication 4, dans lequel la première phase comprend en outre les étapes suivantes :
- si le certificat numérique de terminal est authentique, alors échange d’informations de vérification entre la sonde et le terminal, lesdites informations de vérification étant successivement chiffrées et déchiffrées en utilisant la clé publique de terminal et une clé privée de terminal stockée dans la mémoire du terminal,
- si le certificat numérique de terminal n’est pas authentique, alors émission, par la sonde, d’un message d’alarme.
6. Procédé de gestion selon la revendication 5, dans lequel l’étape d’échange d’informations de vérification comprend les sous-étapes consistant en : o l'extraction, par la sonde, de la clé publique de terminal contenue dans le certificat numérique de terminal, o la génération, par la sonde, d’une information de vérification, o le chiffrage asymétrique, par la sonde, de l’information de vérification avec la clé publique de terminal, o l’envoi, par la sonde, d’un message de réponse incluant l’information de vérification chiffrée avec la clé publique de terminal, o la réception, par le terminal, du message de réponse et le déchiffrage de l’information de vérification en utilisant une clé privée de terminal stockée dans la mémoire du terminal, o l’envoi, par le terminal, d’un message de confirmation contenant l’information de vérification déchiffrée, o la réception, par la sonde, du message de confirmation, o la comparaison, par la sonde, de l’information de vérification déchiffrée contenue dans le message de confirmation avec l’information de vérification contenue dans le message de réponse émis par la sonde, pour définir si lesdites informations de vérification sont identiques ou différentes, et o si les informations de vérification sont identiques, émission d’un message de validation représentatif d’une authentification réussie, o si les informations de vérification sont différentes, émission d’un message d’alarme représentatif d’une authentification échouée.
7. Procédé de gestion selon l’une quelconque des revendications précédentes, dans lequel la deuxième phase comprend les étapes suivantes :
- réception, par le terminal, d’un message de résultat émis par la sonde, le message de résultat intégrant le certificat numérique de sonde,
- extraction, par le terminal, du certificat numérique de sonde,
- vérification par le terminal de l’authenticité du certificat numérique de sonde en comparant la signature dudit certificat numérique de terminal à une clé publique de plateforme contenue dans la mémoire du terminal.
8. Procédé de gestion selon la revendication 7, dans lequel la deuxième phase comprend en outre les étapes suivantes :
- si le certificat numérique de sonde est authentique, alors échange d’informations de vérification entre la sonde et le terminal, lesdites informations de vérification étant successivement chiffrées et déchiffrées en utilisant la clé publique de sonde et une clé privée de sonde stockée dans une mémoire de la sonde,
- si le certificat numérique de sonde n’est pas authentique, alors émission, par le terminal, d’un message d’alarme.
9. Procédé de gestion selon la revendication 8, dans lequel l’étape d’échange d’informations de vérification comprend les sous-étapes consistant en : o l'extraction, par le terminal, de la clé publique de sonde contenue dans le certificat numérique de sonde, o la génération, par le terminal, d’une information de vérification, o le chiffrage asymétrique, par le terminal, de l’information de vérification en utilisant la clé publique de sonde, o l’envoi, par le terminal, d’un message de justification incluant l’information de vérification chiffrée avec la clé publique de sonde, o la réception, par la sonde, du message de justification et le déchiffrage de l’information de vérification en utilisant une clé privée de sonde stockée dans la mémoire de la sonde, o l’envoi, par la sonde, d’un message de preuve contenant l’information de vérification déchiffrée, o la réception, par le terminal, du message de preuve, o la comparaison, par le terminal, de l’information de vérification contenue dans le message de preuve avec l’information de vérification contenue dans le message de justification émis par le terminal, pour définir si lesdites informations de vérification sont identiques ou différentes, et o si les informations de vérification sont identiques, émission d’un message de validation représentatif d’une authentification réussie, o si les informations de vérification sont différentes, émission d’un message d’alarme représentatif d’une authentification échouée.
10. Procédé de gestion selon l’une quelconque des revendications précédentes, lequel comprend, préalablement à la mise en oeuvre d’une procédure d’authentification, une procédure de souscription dans laquelle : - le terminal envoie à la plateforme un message de demande d’examen incluant un identifiant de sonde, un identifiant de terminal, et la clé publique de terminal,
- la plateforme envoie au terminal un message d’autorisation d’appairage incluant un certificat de plateforme incluant une clé publique de plateforme et un certificat de terminal incluant la clé publique de terminal. ii.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, ladite sonde comportant une mémoire contenant un certificat numérique de sonde incluant une clé publique de sonde,
- un terminal (2) apte à communiquer avec la sonde par l’intermédiaire de moyens de communication avec ou sans fil, ledit terminal comportant une mémoire contenant un certificat numérique de terminal incluant une clé publique de terminal,
- une plateforme (3) distante apte à communiquer avec le terminal par l’intermédiaire d’un réseau informatique tel qu’internet, ladite plateforme étant configurée pour : o délivrer le certificat numérique de sonde à la sonde, o délivrer le certificat numérique de terminal au terminal, caractérisé en ce que la sonde (1 ), le terminal (2) et la plateforme (3) comprennent des moyens adaptés pour la mise en oeuvre d’une procédure d’authentification, préalablement à la mise en oeuvre de la procédure d’examen, la procédure d’authentification comprenant les phases suivantes :
- une première phase dans laquelle la sonde vérifie l’identité du terminal à partir du certificat numérique de terminal, et
- une deuxième phase dans laquelle le terminal vérifie l’identité de la sonde à partir du certificat numérique de sonde,
- une troisième phase dans laquelle la sonde, le terminal et la plateforme génèrent chacun une clé de session identique, ladite clé de session étant produite à partir des clés publiques de sonde et de terminal.
12. Système selon la revendication 11 , dans lequel la sonde, le terminal et la plateforme comprennent des moyens pour la mise en oeuvre des phases, étapes et sous-étapes du procédé de gestion défini aux revendications 2 à 10.
PCT/EP2020/087458 2019-12-20 2020-12-21 Procede et systeme de gestion d'echange de donnees dans le cadre d'un examen medical WO2021123431A1 (fr)

Priority Applications (6)

Application Number Priority Date Filing Date Title
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
CN202080094825.8A CN115136545B (zh) 2019-12-20 2020-12-21 用于在医疗检查的环境中管理数据交换的方法和系统
KR1020227024603A KR20220134751A (ko) 2019-12-20 2020-12-21 의료 검사의 컨텍스트에서 데이터 교환을 관리하기 위한 방법 및 시스템
JP2022538167A JP2023507651A (ja) 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
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
FRFR1915204 2019-12-20
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

Publications (1)

Publication Number Publication Date
WO2021123431A1 true WO2021123431A1 (fr) 2021-06-24

Family

ID=71094421

Family Applications (1)

Application Number Title Priority Date Filing Date
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

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
US20230051689A1 (en) * 2021-08-11 2023-02-16 Texas Instruments Incorporated Wireless battery management system setup

Citations (4)

* 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
US20150052352A1 (en) * 2013-06-23 2015-02-19 Shlomi Dolev Certificating vehicle public key with vehicle attributes
US20190089684A1 (en) * 2014-03-11 2019-03-21 Tencent Technology (Shenzhen) Company Limited Method and system for encrypted communications
US20190386992A1 (en) * 2014-09-17 2019-12-19 Microsoft Technology Licensing, Llc Establishing trust between two devices

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7386878B2 (en) * 2002-08-14 2008-06-10 Microsoft Corporation Authenticating peer-to-peer connections
DE102013202494A1 (de) * 2013-02-15 2014-08-21 Siemens Aktiengesellschaft Authentifizierung von medizinischen Clientgeräten in einem Geräteverbund
JP2017192117A (ja) * 2016-04-15 2017-10-19 富士通株式会社 センサ装置、情報収集システム、および情報収集方法
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 (4)

* 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
US20150052352A1 (en) * 2013-06-23 2015-02-19 Shlomi Dolev Certificating vehicle public key with vehicle attributes
US20190089684A1 (en) * 2014-03-11 2019-03-21 Tencent Technology (Shenzhen) Company Limited Method and system for encrypted communications
US20190386992A1 (en) * 2014-09-17 2019-12-19 Microsoft Technology Licensing, Llc Establishing trust between two devices

Also Published As

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

Similar Documents

Publication Publication Date Title
EP2441207B1 (fr) Procédé cryptographique d'authentification anonyme et d'identification séparée d'un utilisateur
EP1612991B1 (fr) Procédé et système de vote électronique en réseau à haute sécurité
FR3041195A1 (fr) Procede d'acces a un service en ligne au moyen d'un microcircuit securise et de jetons de securite restreignant l'utilisation de ces jetons a leur detenteur legitime
EP1282288A1 (fr) Procédé et dispositif d'authentification
CA2377626A1 (fr) Procede et dispositif de paiement electronique
CN101479987A (zh) 生物测定凭证验证框架
EP2619941A1 (fr) Procede, serveur et systeme d'authentification d'une personne
CN107506635B (zh) 身份证网上功能开通方法、手机、可信终端和验证服务器
CA2969495C (fr) Procede mis en oeuvre dans un document d'identite et document d'identite associe
FR3048530B1 (fr) Systeme ouvert et securise de signature electronique et procede associe
EP2562958A1 (fr) Procede et dispositif de signature juridique
WO2021123431A1 (fr) Procede et systeme de gestion d'echange de donnees dans le cadre d'un examen medical
EP1514377A1 (fr) Procede et dispositif d'interface pour echanger de maniere protegee des donnees de contenu en ligne
US20230188345A1 (en) System and methods for interactive document sharing and authentication with privacy guarantee
US20210248863A1 (en) Method, system, and device for selecting a winner of a raffle based on content from raffle tickets
EP3262553A1 (fr) Procede de transaction sans support physique d'un identifiant de securite et sans jeton, securise par le decouplage structurel des identifiants personnels et de services
EP2056565A1 (fr) Procédé d'authentification d'un utilisateur accédant à un serveur distant à partir d'un ordinateur
FR3104867A1 (fr) Procédé et dispositif de contrôle d’accès anonyme à une plateforme collaborative d’anonymisation
CN114465734B (zh) 投资者认证方法及存储介质
US20240154943A1 (en) System and methods of crypto chat
FR2898423A1 (fr) Procede securise de configuration d'un dispositif de generation de signature electronique.
FR3138540A1 (fr) Procédé de traitement de données dans l’informatique en nuage
WO2017005644A1 (fr) Procédé et système de contrôle d'accès à un service via un média mobile sans intermediaire de confiance
EP1989819B1 (fr) Procéde de certification de clé publique par un prestataire non accrédité
FR3007929A1 (fr) Procede d'authentification d'un utilisateur d'un terminal mobile

Legal Events

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

Ref document number: 20829945

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022538167

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2020829945

Country of ref document: EP

Effective date: 20220720