FR3138540A1 - Procédé de traitement de données dans l’informatique en nuage - Google Patents

Procédé de traitement de données dans l’informatique en nuage Download PDF

Info

Publication number
FR3138540A1
FR3138540A1 FR2207647A FR2207647A FR3138540A1 FR 3138540 A1 FR3138540 A1 FR 3138540A1 FR 2207647 A FR2207647 A FR 2207647A FR 2207647 A FR2207647 A FR 2207647A FR 3138540 A1 FR3138540 A1 FR 3138540A1
Authority
FR
France
Prior art keywords
user
data
central server
encrypted
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
FR2207647A
Other languages
English (en)
Inventor
Louis ABRAHAM
Olivier Ami
Christopher YOVANOVITCH
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Anonymize
Original Assignee
Anonymize
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 Anonymize filed Critical Anonymize
Priority to FR2207647A priority Critical patent/FR3138540A1/fr
Priority to PCT/EP2023/070383 priority patent/WO2024022988A1/fr
Publication of FR3138540A1 publication Critical patent/FR3138540A1/fr
Pending legal-status Critical Current

Links

Classifications

    • 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/3226—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 using a predetermined code, e.g. password, passphrase or PIN
    • 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/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • 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/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • 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/0822—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 key encryption key
    • 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/3236—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 using cryptographic hash functions
    • H04L9/3239—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 using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/88—Medical equipments

Abstract

Procédé de traitement de données dans l’informatique en nuage, les données étant stockées chiffrées dans au moins un serveur de données, le procédé comprenant une étape de création d’un compte utilisateur, une étape d’envoi par un terminal utilisateur d’une requête d’authentification à un serveur central offrant des services de traitement de données, la requête d’authentification comprenant l’envoi au serveur central d’un mot de passe, une étape de contrôle d’authentification de l’utilisateur par le serveur central, une étape de réponse du serveur central à la requête d’authentification lorsque l’utilisateur a été authentifié, le procédé comprenant, lors de l’étape de création des comptes utilisateurs, la génération pour chaque utilisateur et pour chaque application d’une clé publique et d’une clé privée formant une paire de clés, l’étape de réponse du serveur central à la requête d’authentification comprenant l’envoi au terminal utilisateur de la paire de clés, la clé privée étant chiffrée avec une clé maîtresse générée à partir du mot de passe de l’utilisateur.

Description

Procédé de traitement de données dans l’informatique en nuage
L’invention a trait au domaine technique du traitement des données, en particulier de données concernant la santé, dans l’informatique en nuage (cloud computing).
Selon l’article 4-15 du RGPD (Règlement Général sur la Protection des Données 2016-679, JOUE du 23 mai 2018), par « données concernant la santé » sont désignées les données à caractère personnel relatives à la santé physique ou mentale d’une personne physique, y compris la prestation de services de soins de santé, qui révèlent des informations sur l’état de santé de cette personne. Cette définition vise toute information créé ou reçue, en particulier par un prestataire de santé ou une autorité de santé publique, rendant compte de l’état passé, présent ou futur du physique ou du mental d’un individu.
Une donnée médicale, pour être valide, doit être accessible, actuelle, exhaustive, fiable, pertinente et précise.
Les données médicales doivent être conservées de manière pérenne et sécurisée.
Les données médicales sont sensibles, le non-respect de la confidentialité de ces données pouvant avoir des conséquences de gravité diverse, par exemple refus d’un prêt si l’établissement bancaire est informé de l’état de santé d’un client, ou préférence à l’embauche de personnes ne présentant pas d’antécédents médicaux.
Les données médicales sont fragiles, et doivent être protégées des pertes, par exemple suite à panne matérielle, corruption des données par virus, ou erreur humaine. Les données médicales peuvent influencer le traitement administré au patient.
Les données médicales doivent ainsi être protégées non seulement de destruction et d’altération, par des moyens de sécurité, mais également être protégées d’une utilisation abusive, par des moyens de confidentialité.
Les données médicales doivent être protégées notamment dans le contexte d’équipements médicaux connectés, communiquant vers le cloud. De tels équipements médicaux collectent par exemple la fréquence cardiaque, la pression artérielle, la saturation en oxygène, la température, la glycémie. De tels équipements médicaux peuvent être des stimulateurs cardiaques, des neuro-stimulateurs, ou des dispositifs administrant des médicaments, par exemple de l’insuline, un antalgique, ou un traitement anticancéreux.
Le dossier médical personnel lancé en 2004, devenu dossier médical partagé (DMP) en 2016, a permis le stockage de documents médicaux tels que des comptes rendus d’hospitalisation, des comptes rendus d’imagerie, des résultats de biologie.
A juin 2021, environ 10 millions de DMP étaient ouverts, les DMP étant enrichis en contenus ou consultés par des logiciels métier DMP compatibles, pouvant fonctionner en installation locale, ou en cloud. L’accès au DMP pour le patient implique une double confirmation : un mot de passe enregistré par le patient, et un code unique envoyé par mail ou SMS lors de chaque connexion.
Le DMP s’est avéré peu utilisé par les médecins généralistes, son utilisation étant vue comme chronophage, avec une très mauvaise interopérabilité. La création de « Mon espace santé », en février 2022, vise à remplacer et améliorer le DMP, en recensant les informations et documents médicaux de chaque assuré.
Les professionnels de santé sont par ailleurs encouragés à utiliser une messagerie sécurisée de santé, par exemple MonSisra, ApiCrypt, Mailiz, Lifen. Le service public « Mon espace santé » est présenté comme intégrant une messagerie de santé sécurisée.
L’expression « cloud computing » a été définie par le passé de différentes manières. Dans une revue de 2009,Vaquero et al .identifient une vingtaine de définitions (A break in the clouds : towards a cloud definition, ACM SIGCOMM Computer Communication Review, vol. 39 n.1,pp. 50–55, 2009). Selon l’ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information), la cloud computing, ou informatique en nuage, peut être définie comme un hébergement externe partagé, c’est-à-dire un modèle de gestion informatique permettant l’accès aisé via un réseau à des ressources informatiques partagées et configurables, ces ressources étant attribuées à la demande et parfois en libre-service (ANSSI, référentiel d’exigences des prestataires de services d’informatique en nuage, 11 juin 2018). L’informatique en nuage est ainsi un modèle d’accès à des ressources, par exemple réseaux, serveurs, stockage, ou encore applications, services, calcul, pouvant être configurés en infrastructure, logiciels et applications.
L’informatique en nuage pour le traitement des données médicales facilite l’accès aux résultats d’analyse, aux images (par exemple scanner, IRM, échographie). L’informatique en nuage favorise le développement de la télémédecine et des opérations à distance.
La masse de données médicales peut, par ailleurs, être utilisée pour des recherches scientifiques, en particulier par apprentissage automatique (machine learning , deep learning), par exemple pour l’aide au diagnostic, ou en épidémiologie. La plateforme des données de santé PDS (Health Data Hub) a ainsi été créée par arrêté du 29 novembre 2019, pour faciliter le partage des données de santé, afin de favoriser la recherche. Les missions de la PDS sont prévues à l’article L1462-1 du Code de la santé publique. En raison de la sensibilité et du volume des données qui seront hébergées en cloud computing au sein de la PDS, la CNIL a fait part de son souhait que l’hébergement soit réservé à des entités relevant exclusivement des juridictions de l’Union européenne.
Des procédés de partage de données médicales entre utilisateurs d’un système d’informatique en nuage sont décrits par exemple dans les documents US2022044770 (Konica, 2022), EP3799056 (Siemens, 2021).
L’informatique en nuage peut être classée en différents types, en fonction de la répartition des responsabilités entre commanditaire et prestataire de services : logiciel en tant que service (SaaS Software as a service), fourniture de services (PaaS Platform as a Service), infrastructure en tant que service (IaaS Infrastructure as a Service).
Dans un fonctionnement SaaS, des applications sont hébergées sur une plateforme partagée. Le professionnel de santé accède au logiciel médical installé sur un serveur distant, qui stocke les données du professionnel de santé sur un ou plusieurs sites distants. Le professionnel de santé peut effectuer quelques paramétrages métier dans le logiciel médical, qui peut être installé sur un terminal de communication du professionnel de santé, ou être hébergé et géré par le fournisseur de service. L’intérêt pratique d’un tel fonctionnement est que le poste de travail du professionnel de santé est peu couteux, car ne nécessitant pas de puissants moyens de stockage ou de calcul. De plus, les opérations de maintenance sont effectuées chez le prestataire de service.
Le document WO 2014/071045 (Intelligent Medical Objects, 2014) décrit un logiciel de traitement d’informations médicales, dans une infrastructure SaaS.
Dans un fonctionnement PaaS, au moins une plateforme d’hébergement d’applications est mise à disposition par un prestataire. L’infrastructure (notamment réseau, serveurs, stockage) est gérée et contrôlée par le prestataire. Le professionnel de santé a la maîtrise des applications déployées sur la plateforme.
Le document US 2019251288 (Virtual Viewbox, 2019) décrit un système de contrôle d’accès aux données de santé, le système comprenant une plateforme en tant que service PaaS. Sur la base des informations d’enregistrement, le système génère un jeton (token) qui correspond à un utilisateur, le jeton fournissant une pluralité de sous-jetons d’autorisations, par exemple pour la visualisation d’images radiologiques. Un module de synchronisation en tant que service garantit que la personne demandant les dossiers médicaux est authentifiée et dispose des autorisations appropriées pour accéder aux informations médicales.
Dans un fonctionnement IaaS, des ressources informatiques abstraites (puissance CPU, stockage, mémoire) sont mises à disposition. Le commanditaire garde le contrôle du système d’exploitation, du stockage, des applications déployées ainsi que sur certains composants réseau, par exemple les pare-feu.
Le document CN 102306250 (Cheng, 2012) décrit la communication de valeurs d’impédances électriques cérébrales vers un serveur, une reconstruction de l’image tomographique étant effectuée dans un fonctionnement IaaS.
Pour limiter les risques d’attaques lors de la circulation et du stockage de données médicales, différents mécanismes sont utilisés.
Les hébergeurs de données de santé HDS sont soumis à un cahier des charges comprenant des mesures de sécurité. Dans le cadre de la procédure d’agrément, l’ANS (Agence du Numérique en Santé) publie la liste des sociétés ou organismes agréés HDS. Au 20 juillet 2021, 66 sociétés ou organismes sont agréés par le ministère chargé de la santé, avec des infrastructures de type IaaS, SaaS ou PaaS. Les logiciels de télémédecine doivent être conformes au RGPD et être certifiés HDS.
Les HDS qui sont hébergeurs d’infrastructure physique ou infogéreurs doivent s’assurer que les données à caractère personnel sont chiffrées avant d’être transmises sur les réseaux publics.
Le chiffrement utilise une cryptographie symétrique ou asymétrique. Le chiffrement permet de protéger la confidentialité d’une information échangée lors du transfert, ou lors du stockage.
Avec un algorithme de chiffrement symétrique, l’émetteur et le récepteur de l’information partagent une clé identique, utilisée pour chiffrer et déchiffrer l’information. La clé peut être communiquée entre émetteur et récepteur lors d’une rencontre physique, ou via un canal sécurisé. La clé peut être modifiée dans le temps. DES (Data Encryption Standard) et AES (Advanced Encry ption Standard) sont deux exemples d’algorithmes de chiffrement symétriques. Ces algorithmes sont peu couteux en calcul, mais ne permettent pas le traitement de données chiffrées.
Avec un algorithme de chiffrement asymétrique, l’émetteur et le récepteur de l’information possèdent deux clés, i.e. une clé privée et une clé publique. Un tiers de confiance peut signer les clés publiques pour prouver leur authenticité ou générer des paires de clés. L’émetteur chiffre l’information qu’il souhaite envoyer, à l’aide de la clé publique du récepteur, et le récepteur, destinataire de l’information, déchiffre en utilisant sa clé privée. RSA (Rivest-Shamir-Adleman) ou ECC (Elliptic Curve Cryptography) sont des exemples d’algorithmes de chiffrement asymétriques. L’on peut se référer, par exemple, aux documents EP 2320621 (Hoffmann La Roche AG, 2011), US 7912216 (Safenet, 2011).
Dans l’algorithme RSA, pour la signature du message, prouvant que le message provient de l’expéditeur, une fonction de hachage du message produit une empreinte qui est chiffrée par l’expéditeur, à l’aide de sa clé privée. A la réception du message et de la signature, le destinataire déchiffre l’empreinte à l’aide de la clé publique de l’émetteur et la compare avec celle qu’il obtient en appliquant la même fonction de hachage sur le message reçu.
Dans l’algorithme ECC, l’échange de clés peut être effectué par un protocole Diffie-Hellman (ECDH) avec des clés publiques statiques, ou un protocole ECDHE (Elliptic Curve Diffie Hellman Ephemeral), avec des clés publiques éphémères.
Les procédés de traitement des données dans l’informatique en nuage, en particulier de données concernant la santé, présentent de nombreux inconvénients.
En premier lieu, le professionnel est face à une multiplicité d’offres de services, qui ne sont pas interopérables. En France, pour les données concernant la santé, près de 200 logiciels de télémédecine conformes au RGPD sont recensés par le ministère des solidarités et de la santé. Chaque logiciel a son environnement propre, avec ses contraintes en termes de matériel et de connexion.
En deuxième lieu, le développeur est face à de fortes contraintes techniques et règlementaires, qui ralentissent le déploiement de nouvelles applications. En France, pour les données concernant la santé, l’hébergement doit par exemple être assuré par une entreprise ou un organisme agréé HDS.
En troisième lieu, le traitement des données dans l’informatique en nuage entraîne des risques de perte de confidentialité ou d’usage abusif, lorsque les données ne sont pas chiffrées de bout en bout. La confidentialité et la préservation de la vie privée sont des préoccupations majeures pour les utilisateurs d’internet, en particulier pour les données concernant la santé.
Par chiffrer, on désigne ici la réalisation d’une transformation (encryption) d’une donnée en un cryptogramme, au moyen d’un code et d’une clé, afin de rendre la donnée illisible à une personne ne connaissant pas la clé, seule une personne connaissant la clé pouvant déchiffrer la donnée.
L’invention vise à pallier les inconvénients des procédés de l’art antérieur de traitement de données dans l’informatique en nuage, en particulier les données concernant la santé.
Il est proposé, selon un premier aspect, un procédé de traitement de données dans l’informatique en nuage, les données étant stockées chiffrées dans au moins un serveur de données, le procédé comprenant
- une étape de création d’un compte utilisateur ;
- une étape d’envoi par un terminal utilisateur d’une requête d’authentification à un serveur central offrant des services de traitement de données ;
- une étape de contrôle d’authentification de l’utilisateur par le serveur central ;
- une étape de réponse du serveur central à la requête d’authentification lorsque l’utilisateur a été authentifié ;
le serveur central comprenant une base de données répertoriant des applications de traitement de données, l’étape de création d’un compte utilisateur comprenant la sélection par l’utilisateur d’au moins une application de traitement de données, le procédé comprenant, lors de l’étape de création des comptes utilisateurs, la génération pour chaque utilisateur et pour chaque application d’une clé publique et d’une clé privée formant une paire de clés, le serveur central comprenant une base de données de clés publiques des utilisateurs, l’étape de réponse du serveur central à la requête d’authentification comprenant l’envoi au terminal utilisateur de la paire de clés, la clé privée étant chiffrée avec une clé maîtresse générée à partir du mot de passe de l’utilisateur.
Le procédé permet le partage, dans l’informatique en nuage, de plusieurs applications de traitement de données, avec un accès à ces applications par une seule plateforme. Ce partage permet le dépôt de données, la lecture des données, ou la correction des données, en fonction de droits accordés aux utilisateurs.
Par exemple, un médecin aura accès en lecture à des données concernant la santé, stockées chiffrées dans le serveur de données, ces données pouvant être issues de différentes applications de traitement de données.
Les applications de traitement de données peuvent être des logiciels de mise en forme de rapports (par exemple pour un laboratoire d’analyse médicale, un centre d’anatomo-pathologie). Les applications de traitement de données peuvent être des logiciels d’aide à l’analyse de données (par exemple logiciels d’analyse d’images médicales issues de scanner, d’IRM, de radiographies, d’échographies). Les applications de traitement de données peuvent être des logiciels d’aide à la décision médicale (par exemple logiciels d’intelligence artificielle de prédiction d’un risque de présence ou d’évolution de pathologie, ou logiciel d’évaluation des risques lors d’un accouchement par voie basse).
Avantageusement, la génération de la clé maîtresse est obtenue par combinaison du mot de passe utilisateur avec une chaîne aléatoire (sel crytpographique,salt), cette chaîne aléatoire étant générée par l’utilisateur lors de la création du compte utilisateur, ou lors d’un changement de mot de passe utilisateur. La chaîne aléatoire est stockée dans le serveur central, et la chaîne aléatoire est fournie par le serveur central, lors de la connexion de l’utilisateur, après le contrôle de l’authentification de l’utilisateur.
Avantageusement, le contrôle de l’authentification de l’utilisateur est effectué à l’aide du protocole SRP (Secure Remote Password) et d’une authentification à plusieurs facteurs.
Avantageusement, la chaîne aléatoire est obtenue par un algorithme de hachage de type Argon2, et plus particulièrement Argon2id, en version 1.3. Une présentation d’Argon2 est donnée par Jos Wetzels (The password hashing competition and Argon 2, Applied Cryptography, 2015).
Avantageusement, l’étape de réponse du serveur central à la requête d’authentification comprend l’envoi au terminal utilisateur d’un identifiant unique de session généré par une fonction de hachage.
Dans d’autres mises en œuvre, l’identifiant unique provient d’un générateur de nombres pseudo-aléatoires, utilisant une fonction de hachage, et/ou des algorithmes de chiffrement par blocs, et/ou des algorithmes basés sur la théorie des nombres.
Avantageusement, la fonction de hachage est non inversible, le résultat obtenu par le hachage (empreinte) ne permettant pas de trouver la suite de bits d’origine. Avantageusement, la fonction de hachage est sans collision, de sorte qu’il n’est pas possible de calculer en un temps raisonnable un nombre de hachés aléatoires fournissant une empreinte donnée. La fonction de hachage est par exemple SHA-3 (Secure Hash Algorithm -3).
Avantageusement, les clés publiques sont sauvegardées en clair dans la base de données des clefs publiques du serveur central.
Avantageusement, un code et une chaîne de caractères uniformes sont associés à chaque application de traitement de données, dans la base de données répertoriant les applications de traitement de données. La chaîne de caractères uniformes est par exemple un URI (Uniform Resource Identifier), permettant les redirections web ou mobiles (Mobile deep linking).
Avantageusement, les données stockées dans le serveur de données sont organisées dans une hiérarchie de dossiers et fichiers dont les noms peuvent être chiffrés ou non.
Avantageusement, le procédé comprend une étape d’envoi d’un message ou d’un fichier depuis un premier terminal utilisateur expéditeur, à destination d’au moins un deuxième utilisateur destinataire du message, le procédé comprenant une étape de hachage du corps du message ou du fichier et de chiffrement du message ou du fichier avec la clé publique du destinataire, après l’étape de hachage et avant l’envoi au serveur. Le chiffrement et l’authentification sont avantageusement réalisés par deux algorithmes différents, par exemple XSalsa20 et Poly1305 MAC, ces deux algorithmes prenant en entrée la clé publique du destinataire et la clé privée de l’expéditeur.
Dans certaines mises en œuvre, le procédé comprend une étape de hachage du sujet du message, avant l’étape de chiffrement du message avec la clé publique du destinataire. Un hachage est avantageusement appliqué à l’ensemble du message (sujet+corps), pour une conversation de groupe.
Avantageusement, le procédé comprend une étape d’envoi du message haché et chiffré au serveur central, par le terminal expéditeur, et une étape de routage par le serveur central du message chiffré, vers au moins un utilisateur destinataire du message.
Le procédé permet ainsi une conversation entre deux utilisateurs, par exemple un médecin et un patient, un obstétricien et un radiologue. Le procédé permet une conversation de groupe, avec une vérification de ce que le même message a été envoyé à tous les participants. Dans le cas d’une attaque visant à altérer le message envoyé, le contenu du message est déchiffré et un deuxième hachage est effectué. Une comparaison entre les deux empreintes est effectuée. Si les deux empreintes sont différentes, un avertissement est avantageusement affiché sur le terminal du destinataire, et éventuellement de l’expéditeur, par exemple «attention, le message a pu être altéré».
Avantageusement, le procédé comprend une étape de stockage du message chiffré dans une base de données du serveur central.
Avantageusement, le procédé comprend :
- a) une étape de requête, par une application client de l’utilisateur d’un premier service, d’un accès aux données du même utilisateur, issues d’un second service ;
- b) la redirection de l’utilisateur vers le serveur central ;
- c) une étape, par le serveur central, d’autorisation du profil utilisateur ;
- d) une étape de redirection de l’utilisateur vers le premier service, avec des clefs de déchiffrement ;
- e) une étape de déchiffrement, par l’application client de l’utilisateur du premier service, des informations issues du second service.
Les étapes b, c et d ne sont avantageusement pas nécessaires dans le cas d’accès répétés à des données utilisant la même clé de déchiffrement ou la même clef d’application.
Le transfert de données peut ainsi être granulaire, et ne concerner que certaines données seulement.
Le procédé et une infrastructure mettant en œuvre le procédé donnent ainsi un accès facilité à différents services interopérables, ces services pouvant se partager des données entre eux.
Il est proposé, selon un deuxième aspect, une infrastructure informatique en nuage mettant en œuvre le procédé présenté ci-dessus, l’infrastructure comprenant le serveur central, au moins un serveur de données contenant les données chiffrées, l’infrastructure comprenant un canal de messagerie permettant le transfert de données entre au moins deux terminaux utilisateurs, les données étant chiffrées de bout en bout lors du transfert des données entre les terminaux utilisateurs.
L’infrastructure permet le stockage et le transfert de données chiffrées. Le chiffrement de données est avantageusement effectué de bout en bout. Avantageusement, le protocole SRP (Secure Remote Pass word) est employé, permettant de protéger les données des utilisateurs en leur adressant une clé qui n’est pas lisible par l’organisation en charge de l’infrastructure.
SRP est un protocole d’authentification reposant sur une preuve à divulgation nulle de connaissance (Zero-Knowledge Proof). Ce protocole a été standardisé dans sa version 3 en 2000 dans la RFC 2945, et la version 6 est décrite dans la RFC 5054 de 2007. Le protocole SRP utilise une longue clé secrète partagée, dérivée d’un nombre aléatoire, généré en partie par l’utilisateur et en partie par le serveur central, cette clé secrète étant ainsi unique à chaque tentative de connexion.
L’infrastructure permet aux développeurs d’applications de proposer plus facilement de nouvelles applications, en particulier de traitement des données de santé. Le développeur n’a pas besoin de détenir ou louer ses propres serveurs. L’infrastructure permet aux utilisateurs de différentes applications de communiquer. L’infrastructure permet la transmission de données entre différentes applications, et permet l’échange de données d’une application d’un utilisateur vers une autre application d’un autre utilisateur.
L’infrastructure permet à plusieurs applications, en particulier des logiciels de télémédecine ou d’aide au diagnostic, d’être visibles et accessibles via une même plateforme, créant un écosystème. Les données sont stockées sous forme chiffrée, assurant une protection de la vie privée. L’infrastructure permet à une application de prouver de manière cryptographique, à un serveur d’un tiers, l’identité d’un utilisateur de l’application.
L’infrastructure donne accès à différents services interopérables, ces services pouvant se partager des données entre eux, par exemple :
- service de stockage de fichiers et dossiers, chiffrés de bout en bout ;
- service de partage entre utilisateurs, qui peuvent avoir des droits différents sur les fichiers (droits administrateur, droit en écriture et lecture, droit en lecture seule) ;
- canal de messagerie, permettant une conversation entre deux utilisateurs, ou une conversation de groupe, avec chiffrement des conversations et authentification des échanges, et possibilité de vérification que le même message a été envoyé à tous les participants d’un groupe de conversation ;
- service de partage de données anonymisées ;
- application de dossier médical ;
- application de gestion de données clients (CRM Customer Relationship Management).
Avantageusement, le serveur de données chiffrées est un serveur hébergeur de données de santé HDS.
D’autres objets et avantages de l’invention apparaîtront à la lumière de la description de modes de réalisation.
Une infrastructure informatique en nuage comprend un serveur central, comprenant une base de données répertoriant des applications de traitement de données, en particulier de données de santé.
Dans une mise en œuvre, une des applications est un simulateur d’accouchement, utilisant les résultats obtenus par IRM à champ ouvert, lors d’accouchement, pour la réalisation de mesures pelvimétriques, afin de déterminer les risques de dystocie.
Dans une mise en œuvre particulière, une des applications effectue une reconstruction 3D, transformant les images 2D obtenues d’un IRM à champ ouvert, permettant de visualiser par exemple l’ampliation périnéale liée à la descente fœtale pendant la deuxième phase de travail.
Dans certaines mises en œuvre, une des applications est un logiciel d’aide au diagnostic, par exemple un logiciel d’intelligence artificielle d’analyse d’images médicales obtenues par IRM, scanner, ou échographie.
Dans certaines mises en œuvre, une des applications est un logiciel de simulation pour la formation en médecine, ou un logiciel d’assistance aux gestes médico-chirurgicaux.
Un utilisateur souhaite accéder à une des applications, via l’infrastructure en nuage, et adresse une requête de création de compte utilisateur, en précisant la (ou les applications) à laquelle (auxquelles) il souhaite accéder. Un serveur central redirige l’utilisateur avec une url telle que «https://services.fr/login?url=application.com #longuechaine», longuechaine étant une chaine de caractère contenant un jeton (token) et un couple de clefs publique et privé propre à l’utilisateur et à l’application.
Cet utilisateur est par exemple un patient, un professionnel de santé tel qu’un radiologue, ou un technicien spécialisé dans le traitement de données.
Dans une mise en œuvre, la création d’un compte utilisateur nécessite la communication au serveur central d’une adresse de courrier électronique et d’un numéro de téléphone de l’utilisateur. Un code de confirmation est envoyé par l’infrastructure, par exemple par sms, et ce code doit être communiqué au serveur central par l’utilisateur.
Dans une mise en œuvre particulière, l’utilisateur doit également communiquer une adresse Ethereum. Par « adresse Ethereum » on désigne ici un compte créé par un utilisateur du réseau Ethereum. L’adresse Ethereum est « vérifiée » en demandant la signature électronique d’un message par l’utilisateur.
Avantageusement, lorsque l’utilisateur dispose de plusieurs adresses de courrier électronique et/ou de plusieurs numéros de téléphone, le compte utilisateur pourra préciser quelle adresse de courrier électronique et/ou quel numéro de téléphone est à prendre en compte lors de l’accès à une application donnée. Cette disposition facilite l’organisation du travail de l’utilisateur exerçant des activités professionnelles différentes, ou exerçant la même activité professionnelle au sein d’organisations différentes.
Pour chacune de ses activités professionnelles, l’utilisateur pourra ainsi apparaître dans l’infrastructure, pour les autres utilisateurs, avec des données de contact (adresse de courrier électronique, numéro de téléphone) propres à chaque application.
Lors de l’étape de création des comptes utilisateurs, une clé publique et une clé privée sont générées, pour chaque utilisateur et pour chaque application, créant ainsi une paire de clés pour un couple utilisateur/application.
Avantageusement, après avoir redirigé l’utilisateur avec une url de type « https://services.fr/login?url=application.com#longuechaine », un jeton (token) est lu dans « longuechaine », le token n’étant valide que pour l’application de traitements de données, par exemple de données médicales, à laquelle l’utilisateur veut se connecter. Ce jeton peut être vérifié par un serveur de l’application de traitement de données, si ce serveur est différent du serveur central.
Avantageusement, le token est un Json web token (JWT) selon le standard défini par la RFC 7519.
Un Json web token (JWT) est un jeton d’autorisation dont le corps est signé ou crypté.
Dans une mise en œuvre, le jeton est en trois parties et comprend un en tête, un contenu et une signature, la portée de l’autorisation étant présente dans le contenu du jeton, la signature étant créée à partir de l’en-tête, du contenu et d’une clé secrète. L’en-tête (header) comprend le type de cryptage utilisé, et le type de token (ici JWT). Avantageusement, l’algorithme est HMAC512 HS512, ou HMAC256 HS256, l’en-tête étant le suivant :
"alg": "HS512",
"typ": "JWT".
Le serveur central comprend une base de données de clés publiques des utilisateurs.
L’utilisateur souhaitant accéder à une application, via l’infrastructure en nuage, envoie, par un terminal de communication, une requête d’authentification au serveur central.
Par « terminal de communication », on désigne ici notamment un ordinateur, un téléphone, un smartphone, une tablette, un téléphone-tablette (phablet).
Le serveur central contrôle d’authentification de l’utilisateur.
Lorsque l’utilisateur a été authentifié, le serveur central répond à la requête d’authentification et envoie au terminal utilisateur la paire de clés, la clé privée étant chiffrée avec une clé maîtresse de chiffrement symétrique, générée à partir du mot de passe de l’utilisateur.
L’utilisateur identifié est alors dirigé vers l’application qu’il souhaite utiliser.
Par exemple, le serveur central envoie à l’utilisateur un token JWT valide seulement pour l’application de traitement de données, notamment de données médicales, à laquelle l’utilisateur veut accéder.
L’en-tête et le contenu du JWT sont avantageusement encodés en base 64.
Le serveur central récupère l’url correspondante à l’application, et cherche dans la base de données l'application connue pour cette url.
Le serveur central indique à l'utilisateur qu'il va se connecter à cette application de traitement de données, via l’infrastructure. L’utilisateur communique par exemple son adresse mail ou un numéro de téléphone, et suit la procédure de connexion.
En réponse, un token JWT est généré, à courte durée de validité, par exemple 10 minutes, le token contenant le code de l'application de traitement de données à laquelle l’utilisateur souhaite accéder.
Le code de l'application est avantageusement de type 512 bits aléatoires, en base64, soit 88 caractères, par exemple vHBsPZKpoVF4J1Xa6gV9F4Vnlm/NCBUWCOuKhCoysT+ka0P3TILCKrJsJjAxI9IxuidJ9kjaaDcmTVYtSbcwBA==.
Le bénéficiaire du JWT est précisé dans le contenu du token ("aud": "APPLICATION_ID"). L’entité ayant émis le JWT est par exemple "iss": "services.fr", le contenu du token JWT étant :
{
"iss": "services.fr",
"sub": "USER_FAKE_ID",
"aud": "APPLICATION_ID",
"jti": "SESSION_ID",
"iat": "DATE",
"exp": "DATE+10mins",
"authorized": false
}
A ce moment, un lien est effectué entre l'application et l'utilisateur, pour générer un identifiant d'utilisateur seulement pour cette application ainsi qu'un id de "session".
L'application vérifie le token JWT, sans vérifier le champ d’identifiant unique jti.
Dans certaines mises en œuvre, l’application à laquelle souhaite accéder l’utilisateur génère un autre token JWT (toujours avec le code de l'application) à l’utilisateur. Ce token autorise l’utilisateur à faire des requêtes au serveur central.
Le contenu de cet autre token sera avantageusement semblable à reçu par le serveur central, mais avec "authorized": true.
L'utilisateur peut ensuite faire des requêtes vers l’application de traitements de données, via l’infrastructure, et décrypter/crypter les données.
Avantageusement, il n’y a qu’un seul compte utilisateur, dans le contexte d’une application.
Lorsqu’un utilisateur déclare le vol de son terminal, une connexion au compte utilisateur est avantageusement effectuée depuis un autre terminal, avec déconnexion éventuelle de la session ouverte avec le terminal volé, interdisant l’accès aux données.
Lorsque la clé de chiffrement a été volée, l’accès n’est pas possible pour les données des autres utilisateurs de l’infrastructure. Les données sont avantageusement chiffrées de bout en bout, le serveur central contrôlant les connexions. Lorsqu’un utilisateur a perdu son mot de passe et sa clef maîtresse, et qu’il réinitialise son compte et a donc perdu l’accès à ses fichiers, il peut récupérer l’accès aux fichiers qui étaient partagés avec d’autres utilisateurs en envoyant une requête en ce sens. Il est possible d’automatiser ce processus ou au contraire que l’application demande confirmation d’un ou plusieurs de ces utilisateurs.
Lorsque l’utilisateur a perdu son mot de passe, une clé de récupération est avantageusement utilisée. La clé de récupération peut être confiée à un tiers de confiance, ou être découpée en plusieurs parties données à des tiers de confiance, ou bien encore stockée en lieu sûr.
Lors de l’envoi d’une requête au serveur central, le serveur adresse au terminal utilisateur une demande de preuve d’identité, avantageusement à plusieurs facteurs (pièce d’identité, preuve d’accès au téléphone, preuve d’accès à l’adresse de courrier électronique).
Avantageusement, l’étape de réponse du serveur central à la requête d’authentification comprend l’envoi au terminal utilisateur d’un identifiant unique de session généré par exemple par une fonction de hachage.
Avantageusement, après la preuve d’identité de l’utilisateur, le serveur central envoie au terminal utilisateur les clefs qui étaient chiffrées avec la clé maîtresse. Le terminal utilisateur les déchiffre avec la clé de récupération, qui est identique à la clé maîtresse. Le terminal utilisateur génère une graine aléatoire et demande au terminal utilisateur de choisir un nouveau mot de passe. Une nouvelle clé maîtresse est générée à partir de ce nouveau mot de passe utilisateur. Les clés sont chiffrées avec la nouvelle clé maîtresse et stockées sur le serveur central.
Avantageusement, le protocole SRP est employé et un jeton d’authentification utilisé pour le protocole SRP est dérivé du nouveau mot de passe utilisateur. Le protocole d’initialisation de SRP est ensuite exécuté et la graine aléatoire est stockée sur le serveur central.
Avantageusement, un code et une chaîne de caractères uniformes (par exemple une URL) sont associés à chaque application de traitement de données, dans la base de données répertoriant les applications de traitement de données.
L’infrastructure donne accès à différents services interopérables, ces services pouvant se partager des données entre eux :
- service de stockage de fichiers et dossiers, chiffrés de bout en bout ;
- service de partage entre utilisateurs, qui peuvent avoir des droits différents sur les fichiers (droits administrateur, droit en écriture et lecture, droit en lecture seule) ;
- canal de messagerie, permettant une conversation entre deux utilisateurs, ou une conversation de groupe, avec chiffrement des conversations et authentification des échanges, et possibilité de vérification que le même message a été envoyé à tous les participants d’un groupe de conversation ;
- service de partage de données anonymisées ;
- application de dossier médical ;
- application de gestion de données clients (CRM).
Le transfert de données peut être granulaire, et notamment restreint à seulement certaines données.
L’application client de l’utilisateur d’un premier service A désirant un tel accès granulaire à certaines données du même utilisateur, issues d’un second service B, va rediriger l’utilisateur vers le serveur central.
Avantageusement, le serveur central requiert alors l’autorisation de l’utilisateur.
Après cette étape de contrôle, le serveur central redirige l’utilisateur vers le premier service A avec des clefs de chiffrement.
Lors de tentatives ultérieures de l’application client de l’utilisateur du premier service A, le serveur central autorisera l’accès aux informations issues du second service B, et l’application client de l’utilisateur du premier service A pourra déchiffrer ces informations avec les clefs de chiffrement.
Dans des mises en œuvre avantageuses, ces clefs de chiffrement sont stockées de manière chiffrée par l’application client du premier service A, sur le serveur central, afin de ne pas avoir besoin d’effectuer l’étape de redirection à nouveau.
Dans des mises en œuvre avantageuses, l’utilisateur peut accéder à la liste et la portée des autorisations d’accès à ses données à tout moment, à l’aide d’une interface gérée par le serveur central.
Dans certaines mises en œuvre, une clé de chiffrement symétrique peut être transmise (de manière chiffrée asymétriquement) à plusieurs destinataires, au moins un des destinataires ne devant recevoir que des données anonymes. Par exemple un destinataire est un prestataire de services qui effectue des calculs, sur la base de données de santé envoyées par un médecin, ces données ne contenant pas l’identité du patient. Le prestataire peut chiffrer le résultat des calculs avec la clé symétrique partagée, et les envoyer au médecin. Le médecin adressera ensuite son compte rendu au patient, avec le résultat des calculs.
L’infrastructure est particulièrement conçue et adaptée pour le traitement de données de santé, notamment pour la télémédecine.
L’infrastructure comprend un serveur avantageusement agréé HDS. Dans une mise en œuvre, un stockage objet (object storage) permet l’accès aux données par un protocole http, le contenu chiffré correspondant à un identifiant sur un serveur HDS. Cette disposition permet avantageusement de distribuer les serveurs de stockage, en prenant en compte les temps de latence, ou les contraintes environnementales.
Les fichiers de données de santé peuvent en effet être très volumineux, par exemple pour les fichiers d’imagerie médicale, et la proximité du serveur de stockage avec l’utilisateur peut réduire les temps de latence.
L’infrastructure délègue l’accès aux données à différentes applications. Dès que l’utilisateur est redirigé vers une application, il se forme un couple utilisateur/application, qui a une identité propre. L’infrastructure est de type BtoBtoC (Business to Business to Consumer).
L’infrastructure et le procédé permettent le traitement de données anonymisées.
Par exemple, un logiciel d’aide au diagnostic ou de prédiction peut traiter les données de santé anonymes, un utilisateur recevant les données anonyme sous forme chiffrée par le canal de messagerie et les traitants à l’aide du logiciel. Cet utilisateur peut être un technicien, non soumis au secret médical. Le médecin peut ensuite accéder ensuite au résultat produit par ce logiciel, stocké sous forme chiffrée, et adresser un compte rendu au patient avec chiffrement, par le canal de messagerie. Le serveur central n’a accès à aucune donnée en clair. Le terminal du médecin peut transmettre, de manière chiffrée asymétriquement, une clef symétrique à un patient et à un prestataire de calcul externe qui ne connait pas l’identité du patient. Ce prestataire externe pourra ensuite chiffrer le résultat du calcul avec cette clé symétrique partagée. Le patient pourra recevoir le résultat et le déchiffrer. En variante, un patient peut transmettre des données sans révéler son identité, en utilisant une primitive de chiffrement asymétrique, ne prenant pas en entrée sa clef privée et ne nécessitant pas de connaitre sa clé publique pour déchiffrer les données. L’infrastructure et le procédé permettent ainsi le traitement de données anonymisées.
L’infrastructure et le procédé peuvent trouver utilisation dans la gestion de données clients (CRMCustomer Relationship Management), seules certaines personnes de l’entreprise de CRM ayant accès aux données des clients de l’entreprise, ces données étant chiffrées de bout en bout et stockées sous forme chiffrées.
L’infrastructure et le procédé présentent de nombreux avantages.
L’infrastructure protège la vie privée, le serveur central n’ayant aucun accès en clair aux données sensibles. Seules certaines métadonnées comme le nom des destinataires et la taille des fichiers sont connues du serveur central. Ces métadonnées ne sont pas chiffrées, et sont utilisées pour le routage et la facturation. Ces métadonnées sont utilisées par le serveur central pour fournir des clés publiques aux utilisateurs.
C’est à partir du mot de passe que l’utilisateur reçoit la clé de chiffrement, et que le serveur central authentifie l’utilisateur. Lorsque l’utilisateur récupère un message ou un fichier auquel il a le droit d’accès, l’utilisateur a également la clé pour déchiffrer le message, clé que le serveur central ne possède pas.
L’utilisateur génère la clé maîtresse, à partir de son mot de passe. Cette clé maîtresse permet, dans certaines mises en œuvre, de déchiffrer directement les données. Dans d’autres mises en œuvre, cette clé maîtresse permet de déchiffrer les clés symétriques de chiffrement des données. Dans d’autres mises en œuvre, cette clé maîtresse permet de déchiffrer des clés permettant elles-mêmes de déchiffrer des clés de chiffrement de données.
L’infrastructure facilite la création et l’accès à des applications, par la création d’un écosystème et d’une plateforme d’accès unique à différentes applications. L’infrastructure offre une délégation d’autorisation, le même service étant fourni à plusieurs applications distinctes, un utilisateur pouvant se connecter à plusieurs applications, en utilisant un compte unique. Cette délégation d’autorisation peut être proposée à un développeur, qui reçoit du serveur central une clé propre à son application. La clé maîtresse, générée à partir du mot de passe, permet l’accès à toutes les applications répertoriées dans le serveur central.
Un développeur n’a pas besoin d’acheter un serveur, et utilise la technologie de stockage de l’infrastructure, pour proposer un service à ses utilisateurs, par exemple les patients et les médecins. Ce sont les patients et les médecins qui vont se connecter à la plateforme, pour accéder aux services proposés par le développeur.

Claims (12)

  1. Procédé de traitement de données dans l’informatique en nuage, les données étant stockées chiffrées dans au moins un serveur de données, le procédé comprenant
    - une étape de création d’un compte utilisateur ;
    - une étape d’envoi par un terminal utilisateur d’une requête d’authentification à un serveur central offrant des services de traitement de données;
    - une étape de contrôle d’authentification de l’utilisateur par le serveur central ;
    - une étape de réponse du serveur central à la requête d’authentification lorsque l’utilisateur a été authentifié ;
    le procédé étant caractérisé en ce que le serveur central comprend une base de données répertoriant des applications de traitement de données, l’étape de création d’un compte utilisateur comprenant la sélection par l’utilisateur d’au moins une application de traitement de données, le procédé comprenant, lors de l’étape de création des comptes utilisateurs, la génération pour chaque utilisateur et pour chaque application d’une clé publique et d’une clé privée formant une paire de clés, le serveur central comprenant une base de données de clés publiques des utilisateurs, l’étape de réponse du serveur central à la requête d’authentification comprenant l’envoi au terminal utilisateur de la paire de clés, la clé privée étant chiffrée avec une clé maîtresse générée à partir du mot de passe de l’utilisateur.
  2. Procédé selon la revendication 1, caractérisé en ce que l’étape de réponse du serveur central à la requête d’authentification comprend l’envoi au terminal utilisateur d’un identifiant unique de session généré par une fonction de hachage. .
  3. Procédé selon la revendication 1 ou 2, caractérisé en ce que les clés publiques sont sauvegardées en clair dans la base de données des clefs publiques du serveur central.
  4. Procédé selon l’une quelconque des revendications 1 à 3, caractérisé en ce qu’un code et une chaîne de caractères uniformes sont associés à chaque application de traitement de données, dans la base de données répertoriant les applications de traitement de données.
  5. Procédé selon l’une quelconque des revendications 1 à 4, caractérisé en ce que les données stockées dans le serveur de données sont organisées dans une hiérarchie de dossiers et fichiers dont les noms peuvent être chiffrés ou non.
  6. Procédé selon l’une quelconque des revendications 1 à 5, caractérisé en ce qu’il comprend une étape d’envoi d’un message ou d’un fichier depuis un premier terminal utilisateur expéditeur, à destination d’au moins un deuxième utilisateur destinataire du message, le procédé comprenant une étape de hachage du corps du message ou du fichier et de chiffrement du message ou du fichier avec la clé publique du destinataire, après l’étape de hachage et avant l’envoi au serveur.
  7. Procédé selon la revendication 6, caractérisé en ce qu’il comprend une étape de hachage du sujet du message, avant l’étape de chiffrement du message avec la clé publique du destinataire.
  8. Procédé selon la revendication 6 ou 7, caractérisé en ce qu’il comprend une étape d’envoi du message haché et chiffré au serveur central, par le terminal expéditeur, et une étape de routage par le serveur central du message chiffré, vers au moins un utilisateur destinataire du message.
  9. Procédé selon l’une quelconque des revendications 6 à 8, caractérisé en ce qu’il comprend une étape de stockage du message chiffré dans une base de données du serveur central.
  10. Procédé selon l’une quelconque des revendications 1 à 9, caractérisé en ce qu’il comprend
    • une étape de requête, par une application client de l’utilisateur d’un premier service, d’un accès aux données du même utilisateur, issues d’un second service ;
    • la redirection de l’utilisateur vers le serveur central ;
    • une étape, par le serveur central, d’autorisation du profil utilisateur ;
    • une étape de redirection de l’utilisateur vers le premier service, avec des clefs de déchiffrement ;
    • une étape de déchiffrement, par l’application client de l’utilisateur du premier service, des informations issues du second service.
  11. Infrastructure informatique en nuage mettant en œuvre le procédé selon l’une quelconque des revendications précédentes, l’infrastructure comprenant le serveur central, au moins un serveur de données contenant les données chiffrées, l’infrastructure comprenant un canal de messagerie permettant le transfert de données entre au moins deux terminaux utilisateurs, les données étant chiffrées de bout en bout lors du transfert des données entre les terminaux utilisateurs.
  12. Infrastructure selon la revendication 11, caractérisée en ce que le serveur de données chiffrées est un serveur hébergeur de données de santé.
FR2207647A 2022-07-26 2022-07-26 Procédé de traitement de données dans l’informatique en nuage Pending FR3138540A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR2207647A FR3138540A1 (fr) 2022-07-26 2022-07-26 Procédé de traitement de données dans l’informatique en nuage
PCT/EP2023/070383 WO2024022988A1 (fr) 2022-07-26 2023-07-21 Procédé de traitement de données dans l'informatique en nuage

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2207647A FR3138540A1 (fr) 2022-07-26 2022-07-26 Procédé de traitement de données dans l’informatique en nuage
FR2207647 2022-07-26

Publications (1)

Publication Number Publication Date
FR3138540A1 true FR3138540A1 (fr) 2024-02-02

Family

ID=84053230

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2207647A Pending FR3138540A1 (fr) 2022-07-26 2022-07-26 Procédé de traitement de données dans l’informatique en nuage

Country Status (2)

Country Link
FR (1) FR3138540A1 (fr)
WO (1) WO2024022988A1 (fr)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7912216B2 (en) 2006-03-03 2011-03-22 Safenet, Inc. Elliptic curve cryptosystem optimization using two phase key generation
EP2320621A1 (fr) 2009-11-06 2011-05-11 F. Hoffmann-La Roche AG Procédé pour établir des communications cryptographiques entre un dispositif distant et un dispositif médical et système permettant d'effectuer le procédé
CN102306250A (zh) 2011-09-08 2012-01-04 程浩川 基于云计算的脑部电阻抗图像监护方法及其系统
WO2014071045A2 (fr) 2012-11-05 2014-05-08 Intelligent Medical Objects, Inc. Système et procédé de génération et de mise en œuvre d'un module d'antécédents de patient apatride
US20190251288A1 (en) 2012-07-22 2019-08-15 Virtual Viewbox, Llc ePHI-COMPLIANT GATEKEEPER SYSTEM AND METHODS
EP3799056A1 (fr) 2019-09-24 2021-03-31 Siemens Healthcare GmbH Échange de données de patient en nuage
US20220044770A1 (en) 2020-08-07 2022-02-10 Konica Minolta Healthcare Americas, Inc. Control of viewing of patient information shared between healthcare facilities

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7912216B2 (en) 2006-03-03 2011-03-22 Safenet, Inc. Elliptic curve cryptosystem optimization using two phase key generation
EP2320621A1 (fr) 2009-11-06 2011-05-11 F. Hoffmann-La Roche AG Procédé pour établir des communications cryptographiques entre un dispositif distant et un dispositif médical et système permettant d'effectuer le procédé
CN102306250A (zh) 2011-09-08 2012-01-04 程浩川 基于云计算的脑部电阻抗图像监护方法及其系统
US20190251288A1 (en) 2012-07-22 2019-08-15 Virtual Viewbox, Llc ePHI-COMPLIANT GATEKEEPER SYSTEM AND METHODS
WO2014071045A2 (fr) 2012-11-05 2014-05-08 Intelligent Medical Objects, Inc. Système et procédé de génération et de mise en œuvre d'un module d'antécédents de patient apatride
EP3799056A1 (fr) 2019-09-24 2021-03-31 Siemens Healthcare GmbH Échange de données de patient en nuage
US20220044770A1 (en) 2020-08-07 2022-02-10 Konica Minolta Healthcare Americas, Inc. Control of viewing of patient information shared between healthcare facilities

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
GHEORGHE GABRIELA ET AL: "SPARER: Secure Cloud-Proof Storage for e-Health Scenarios", 2016 11TH INTERNATIONAL CONFERENCE ON AVAILABILITY, RELIABILITY AND SECURITY (ARES), IEEE, 31 August 2016 (2016-08-31), pages 444 - 453, XP033023096, DOI: 10.1109/ARES.2016.14 *
HUANG JACK ET AL: "MedBloc: A Blockchain-Based Secure EHR System for Sharing and Accessing Medical Data", 2019 18TH IEEE INTERNATIONAL CONFERENCE ON TRUST, SECURITY AND PRIVACY IN COMPUTING AND COMMUNICATIONS/13TH IEEE INTERNATIONAL CONFERENCE ON BIG DATA SCIENCE AND ENGINEERING (TRUSTCOM/BIGDATASE), IEEE, 5 August 2019 (2019-08-05), pages 594 - 601, XP033653685, DOI: 10.1109/TRUSTCOM/BIGDATASE.2019.00085 *
JIN HAO ET AL: "Toward Secure, Privacy-Preserving, and Interoperable Medical Data Sharing via Blockchain", 2019 IEEE 25TH INTERNATIONAL CONFERENCE ON PARALLEL AND DISTRIBUTED SYSTEMS (ICPADS), IEEE, 4 December 2019 (2019-12-04), pages 852 - 861, XP033700236, DOI: 10.1109/ICPADS47876.2019.00126 *
VAQUERA ET AL.: "identifient une vingtaine de définitions (A break in the clouds : towards a cloud définition", ACM SIGCOMM COMPUTER COMMUNICATION REVIEW, vol. 39, no. 1, 2009, pages 50 - 55
ZEIDLER CLEMENS ET AL: "AuthStore: Password-Based Authentication and Encrypted Data Storage in Untrusted Environments", 2018 17TH IEEE INTERNATIONAL CONFERENCE ON TRUST, SECURITY AND PRIVACY IN COMPUTING AND COMMUNICATIONS/ 12TH IEEE INTERNATIONAL CONFERENCE ON BIG DATA SCIENCE AND ENGINEERING (TRUSTCOM/BIGDATASE), IEEE, 1 August 2018 (2018-08-01), pages 996 - 1001, XP033398769, DOI: 10.1109/TRUSTCOM/BIGDATASE.2018.00140 *

Also Published As

Publication number Publication date
WO2024022988A1 (fr) 2024-02-01

Similar Documents

Publication Publication Date Title
Al Hamid et al. A security model for preserving the privacy of medical big data in a healthcare cloud using a fog computing facility with pairing-based cryptography
US8661247B2 (en) Computer implemented method for performing cloud computing on data being stored pseudonymously in a database
EP1253564A2 (fr) Procédé et dispositif de paiement électronique
FR2881248A1 (fr) Systeme et procede d'anonymisation de donnees personnelles sensibles et procede d'obtention de telles donnees
EP2619941A1 (fr) Procede, serveur et systeme d'authentification d'une personne
EP3446436B1 (fr) Procédé d'obtention par un terminal mobile d'un jeton de sécurité
Ibrahim et al. A secure framework for sharing electronic health records over clouds
WO2017114809A1 (fr) Deuxieme authentification dynamique d'une signature electronique utilisant un module materiel securise
Perumal et al. Architectural framework of a group key management system for enhancing e‐healthcare data security
Grover et al. Authorization and privacy preservation in cloud-based distributed ehr system using blockchain technology and anonymous digital ring signature
CN109740319A (zh) 数字身份验证方法及服务器
EP2306668B1 (fr) Système et procédé de transaction sécurisée en ligne
WO2024022988A1 (fr) Procédé de traitement de données dans l'informatique en nuage
CN113990399A (zh) 保护隐私安全的基因数据分享方法和装置
EP3889809A1 (fr) Protection d'un logiciel secret et de données confidentielles dans une enclave sécurisée
EP2056565A1 (fr) Procédé d'authentification d'un utilisateur accédant à un serveur distant à partir d'un ordinateur
De Oliveira et al. Red Alert: break-glass protocol to access encrypted medical records in the cloud
WO2021123431A1 (fr) Procede et systeme de gestion d'echange de donnees dans le cadre d'un examen medical
FR3118226A1 (fr) Procédé et dispositif de contrôle de l’accès à un service utilisant une chaîne de blocs
CN112257084A (zh) 基于区块链的个人信息存储与监控方法、系统及存储介质
US20230177209A1 (en) Distributed Communication Network
Koravatti et al. Blockchain Based Health Care Management System
CN108650086A (zh) 一种云数据加密方法
Meister et al. Password-less key recovery via multi-factor multi-party authentication
Aboelfotoh An ecosystem for improving the quality of personal health records

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20240202