FR2889388A1 - Procede et systeme de gestion securise de donnees entre un serveur et un client - Google Patents

Abstract

L'invention concerne un système et un procédé de gestion sécurisée de données entre un serveur (1) et un client (3) connectés entre eux au moyen d'un réseau de communication (7) comportant les étapes suivantes :- création par le serveur (1) d'un compte pour un utilisateur (5) associé audit client (3),- communication audit utilisateur (5) d'un identifiant dudit compte et d'un moyen d'authentification auprès de ce compte, et - tirage d'un biclef comprenant une clef publique et une clef privée, la clef publique étant conservée par le serveur (1) en association avec le compte utilisateur.

Description

2889388 1

Domaine technique de l'invention L'invention se rapporte au domaine de la gestion sécurisée de données entre un serveur et un client. Plus particulièrement l'invention se rapporte au domaine du stockage et du contrôle d'accès sécurisés à des documents en mode client/serveur ainsi qu'au domaine de la fédération d'identités associé à un fournisseur d'identités.

Arrière-plan de l'invention Les systèmes informatiques de stockage et de partage de l'information (par exemple archivage de documents, espaces collaboratifs, etc.) ont tous besoin de limiter le risque que des données confidentielles ne soient divulguées à des personnes non habilitées. De tels systèmes utilisent un certain nombre de concepts pour modéliser les droits d'accès (notion de propriétaire d'un document, définition de groupes d'utilisateurs partageant certains droits, etc.). Parmi ces droits, on peut distinguer des droits portant sur le document en tant qu'objet archivé (droit de prendre connaissance de l'existence et du nom du document, droit de suppression, etc.) et des droits portant sur le contenu lui-même du document (droits de lecture, écriture, etc.).

Ces systèmes de partage de l'information sont par nature répartis entre des sous-ensembles clients et des sous-ensembles serveurs . Par exemple, dans les architectures de type web , on distingue des sous-ensembles serveurs (serveurs H1TP, serveurs d'applications, bases de données), et des sous-ensembles clients (navigateurs web, programmes de visualisation).

Or, les systèmes actuels gèrent habituellement tous les droits 30 d'accès à travers des mécanismes de calcul des droits, c'est-à-dire que ce sont les programmes d'accès aux documents stockés qui décident , en fonction de l'identité de l'utilisateur connecté, de la nature et de l'étendue des interactions possibles. Par exemple, les systèmes de travail collaboratif sur le web calculent dynamiquement (côté serveur) la liste des documents qu'il est permis d'afficher sur le navigateur Internet d'un utilisateur authentifié.

Les services actuels de stockage de documents préservent en principe la confidentialité des données stockées, grâce aux mécanismes d'authentification des utilisateurs, qui restreignent aux seuls titulaires légitimes l'accès aux documents. Néanmoins, les logiciels d'infrastructure sous-jacents (dans le cas des services en mode web , on peut citer les serveurs HTTP et les systèmes d'exploitation) ne sont pas exempts de failles de sécurité. Cela est dû à la qualité encore imparfaite de ces logiciels. Par conséquent, il n'est pas encore possible d'accorder une complète confiance à ces mécanismes de contrôle d'accès. En outre, une tierce personne ayant un accès physique aux serveurs de stockage (ou aux supports de sauvegarde) n'a aucune difficulté matérielle à accéder aux contenus stockés. Ceci est complètement indépendant des mécanismes applicatifs d'authentification et de contrôle d'accès. Par conséquent, il est souhaitable d'adjoindre aux services de stockage de documents confidentiels une sécurité supplémentaire consistant à chiffrer les documents stockés.

Ce chiffrement des documents stockés est un moyen complémentaire pour garantir la confidentialité des données sensibles.

Actuellement, un chiffrement de documents peut être réalisé par des répertoires partagés chiffrés et gérés par des systèmes d'exploitation en réseau. Une autre technique de chiffrement de documents concerne des systèmes de gestion des droits numériques de type DRM (de l'anglais Digital Rights Management).

Ces techniques actuelles de chiffrement cumulent un ou plusieurs des inconvénients suivants: - certaines de ces techniques s'appuient sur des infrastructures à clé publique de type PKI ( Public Key Infrastructure), dont le déploiement est un préalable, et notamment la publication de certificats de chiffrement et la distribution de clefs de déchiffrement; - les outils de chiffrement existants ne s'intègrent pas avec les navigateurs Internet, et ne sont donc pas appropriés à une utilisation en mode web; et -certaines de ces techniques impliquent une adhérence ou une correspondance avec le poste de travail (c'est le cas des solutions de DRM), ce qui est nuisible au nomadisme c'est-à-dire à une plus grande mobilité du poste de travail.

Ceci explique que les services existants de stockage de documents, en particulier en mode client léger , n'intègrent pas cette sécurité supplémentaire que serait le chiffrement des données.

Un autre exemple de gestion sécurisée de données concerne la fédération d'identités entre un fournisseur d'identités et un service personnalisé .

En effet, il existe actuellement un grand nombre de services offerts sur le Web pouvant être regroupés sous la notion de services personnalisés . Ce type de service doit toujours connaître l'utilisateur avec lequel il communique. Pour cela, l'utilisateur doit s'être préalablement enregistré. Suite à cet enregistrement, l'utilisateur obtient des identifiants qui lui sont demandés lors de chaque nouvel accès. Ces services existent dans des domaines très variés (par exemple des messageries électroniques, banques en ligne, sites marchand, portails d'entreprise, etc.).

Devant la multiplicité et la diversité de ces services personnalisés, on constate qu'il est fréquent qu'un utilisateur soit enregistré sur plusieurs services l'obligeant à mémoriser un grand nombre d'identifiants différents et les associer chacun à un service donné (compte de messagerie, compte sur la banque en ligne, etc.).

En outre, au cours d'une même session de navigation, c'est à 5 dire lors de l'utilisation continue d'une même interface de communication (radio, navigateur, PC connecté à Internet, etc.), un utilisateur peut accéder à plusieurs services nécessitant identification.

En conséquence, les services personnalisés rendent la navigation difficile et saccadée par des identifications à répétition. De plus, 10 un utilisateur ne peut pas obtenir facilement une vision globale des différents services sur lesquels il s'est enregistré.

Un des moyens de résoudre cette difficulté est la fédération d'identités qui peut être mise en oeuvre au travers de différents produits et spécifications (MS PassportTM, Liberty Alliance, SAML, etc.) et repose sur les principes suivants: -des relations de confiance peuvent être établies entre des services personnalisés ce qui définit des cercles de confiance ; et -au sein de chaque cercle de confiance, un ou plusieurs services considérés comme centraux peuvent remplir la fonction de fournisseur 20 d'identités .

En général, les fournisseurs d'identités sont des serveurs qui sont susceptibles de connaître la majorité des utilisateurs déclarés sur l'ensemble des services du cercle de confiance. En outre, ils ont une audience, une influence, ou une autorité suffisantes pour que des services personnalisés aient intérêt à devenir facilement accessibles depuis les fournisseurs d'identités.

La fédération d'identités consiste alors à tisser des liens entre les différentes identités d'un même utilisateur, chacune étant définie sur un service personnalisé différent et son identité unique sur le fournisseur d'identités. Ces liens se matérialisent par le partage d'un alias (également appelé clé de fédération) entre le fournisseur d'identités et le service personnalisé. Cet alias est alors rattaché sur le fournisseur d'identités et sur le service personnalisé de l'utilisateur correspondant. Une fois cet alias échangé, il peut être utilisé par le fournisseur d'identités ou le service personnalisé pour communiquer au sujet d'un utilisateur donné connu des deux systèmes.

L'utilisation directe de cet alias permet alors de mettre en oeuvre un protocole de connexion unique (ou Single Sign On en anglais) au sein d'un cercle de confiance. Une fois l'utilisateur identifié auprès du fournisseur d'identités, les services personnalisés peuvent l'appeler pour lui demander son alias sur leur service. Cet alias peut alors directement être utilisé pour l'identification de l'utilisateur et ce dernier n'a plus à saisir ses identifiants sur chaque service.

Chaque fournisseur d'identités dispose alors d'une base de fédération. Cette base de fédération contient, pour chaque utilisateur, la liste des alias correspondants sur les différents services personnalisés du cercle de confiance.

Ainsi, la fédération d'identités, dans le cadre d'une relation entre un fournisseur d'identités et d'un service personnalisé permet d'associer un alias commun à deux identités sur deux systèmes différents. Plus largement, elle permet de faire un rapprochement entre les données liées à chacune de ces identités.

Pour opérer ce rapprochement, il faut avoir un accès aux données physiques du fournisseur d'identités et d'au moins un service personnalisé du même cercle de confiance, et faire un recoupement en se basant sur les alias. Deux identités partageant un même alias correspondent au même utilisateur réel. Il est alors possible de comparer les données et même d'agréger les données concernant un utilisateur. Cette possibilité peut être perçue comme une véritable atteinte à la vie privée par l'utilisateur. Dans le cadre d'un cercle de confiance élargi, il est probable qu'un même fournisseur d'identités offre l'accès à des services de natures complètement différentes (banque, assurance, impôt, suivi médical, etc.). La possibilité d'un recoupement des informations contenues sur ces différents services personnalisés est particulièrement critique et doit être rendue aussi difficile que possible; en particulier, elle ne doit pas être automatisable.

Certes, pour un acteur extérieur, l'accès aux données physiques d'un système est assez difficile. L'accès aux données physiques de deux systèmes par un acteur externe est donc peu probable. Néanmoins, les enjeux et les possibilités offertes par le recoupement d'informations sont tels qu'il faut également pouvoir se mettre à l'abri d'accès initiés par des acteurs internes au système (par exemple des personnels d'exploitation).

Objet et résumé de l'invention L'invention a pour but de remédier à ces inconvénients et de sécuriser la gestion de données entre un serveur et un client.

Ces buts sont atteints grâce à un procédé de gestion sécurisée de données entre un serveur et un client connectés entre eux au moyen d'un réseau de communication, comportant les étapes suivantes: -création par le serveur d'un compte pour un utilisateur associé audit client, -communication audit utilisateur d'un identifiant dudit compte et d'un moyen d'authentification auprès de ce compte, et - tirage d'un biclef comprenant une clef publique et une clef privée, la clef publique étant conservée par le serveur en association avec le compte utilisateur.

Ainsi, ce procédé permet un chiffrement en permanence des données pouvant être stockées sur le serveur. Cela constitue une très bonne protection à la fois contre des attaques menées à distance et contre l'accès aux données par un acteur ayant physiquement accès au serveur et les éventuels défauts d'implémentation d'un mécanisme de contrôle d'accès logiciel.

Selon un mode de réalisation de l'invention, la clef privée est stockée par le serveur sous forme chiffrée au moyen d'un mot ou phrase 5 de passe en association avec le compte utilisateur.

Ainsi, en chiffrant la clef privée avec par exemple une phrase de passe qui est un mot de passe avec plus de caractères, la gestion sécurisée des données peut être réalisée en mode client léger.

Selon un autre mode de réalisation de l'invention, la clef privée est conservée de façon sécurisée par l'utilisateur.

Ainsi, la gestion sécurisée des données peut être réalisée en mode client riche permettant d'augmenter la confidentialité des données stockées sur le serveur.

Le procédé selon l'invention comporte en outre les étapes 15 suivantes: dépôt par l'utilisateur d'un ensemble de données sur le serveur, chiffrement automatique dudit ensemble de données par le serveur pour former un ensemble de données chiffrées, et - stockage dudit ensemble de données chiffrées dans une mémoire de 20 masse du serveur.

Ainsi, le chiffrement intervient de façon transparente pour l'utilisateur qui dépose l'ensemble de données et ce chiffrement est réalisé de manière automatique par le serveur lui-même. Par conséquent, le dépôt de l'ensemble de données peut se faire à partir d'un navigateur Internet standard.

Avantageusement, le chiffrement automatique dudit ensemble de données comporte les étapes suivantes: - génération d'une clef de session de chiffrement, - chiffrement dudit ensemble de données avec la clef de session, et 30 -chiffrement de la clef de session avec la clef publique, la clef de session chiffrée étant stockée avec l'ensemble de données chiffrées dans la mémoire de masse du serveur.

Ainsi, le chiffrement de l'ensemble de données est réalisé de manière sécurisée et rapide par le serveur sans faire peser aucune contrainte ergonomique au niveau des postes clients. Par conséquent, la sécurité apportée par le chiffrement ne demande pas une adhérence particulière au niveau client et s'intègre parfaitement en mode client léger et en mode nomade.

Selon un mode de réalisation de l'invention, la lecture dudit 10 ensemble de données est réalisée selon les étapes suivantes: -authentification de l'utilisateur auprès du serveur, - communication au serveur par l'utilisateur d'un moyen de déchiffrement de la clef privée associée au compte utilisateur, - déchiffrement par le serveur de ladite clef privée, -déchiffrement par le serveur de la clef de session de chiffrement dudit ensemble de données au moyen de ladite clef privée, et -déchiffrement par le serveur dudit ensemble de données chiffrées au moyen de la clef de session permettant la lecture dudit ensemble de données.

Ainsi, les données chiffrées sont déchiffrables uniquement par l'utilisateur qui a déposé l'ensemble de données. Par ailleurs, selon ce mode de réalisation, le processus de déchiffrement est entièrement réalisé au niveau du serveur permettant ainsi l'accès à ces données en mode client léger.

Selon un autre mode de réalisation de l'invention, la lecture dudit ensemble de données est réalisée selon les étapes suivantes: authentification de l'utilisateur auprès du serveur, -envoi à l'utilisateur de la clef de session de chiffrement dudit ensemble de données, ladite clé de session étant chiffrée, - déchiffrement par des moyens locaux de l'utilisateur de ladite clef de session au moyen de la clé privée conservée par l'utilisateur, - renvoi au serveur de la clef de session déchiffrée, et - déchiffrement par le serveur dudit ensemble de données chiffrées au moyen de la clef de session.

Ainsi, les données chiffrées sont déchiffrables uniquement par l'utilisateur et de plus, la clef privée de l'utilisateur n'est connue que du client. Ceci permet d'augmenter davantage la sécurité d'accès aux données.

Selon encore un autre un mode de réalisation de l'invention, la lecture dudit ensemble de données est réalisée selon les étapes suivantes: authentification de l'utilisateur auprès du serveur, - envoi à l'utilisateur de la clef de session de chiffrement dudit ensemble de données, ladite clé de session étant chiffrée, ainsi que dudit ensemble de données chiffrées, - déchiffrement par des moyens locaux de l'utilisateur de ladite clef de session au moyen de la clé privée conservée par l'utilisateur, et - déchiffrement par les moyens locaux de l'utilisateur dudit ensemble de données chiffrées au moyen de la clef de session.

Ainsi, la clef privée de l'utilisateur n'est connue que du client et de plus les données chiffrées ne sont déchiffrées que sur le poste client. Ceci permet d'augmenter encore davantage la sécurité d'accès aux données.

Avantageusement le procédé de l'invention comporte en outre les étapes suivantes: - affichage d'une liste de documents stockés dans la mémoire de masse du serveur et disponibles pour l'utilisateur et/ou des titulaires de droits de lecture, et -sélection par l'utilisateur et/ou un titulaire de droit de lecture d'un document parmi ladite liste de documents en vue de son déchiffrement.

Ainsi, l'utilisateur ou le titulaire de droit peut accéder et gérer de manière simple et sécurisée les documents stockés sur le serveur. Les documents peuvent ainsi être déchiffrés uniquement par une liste de titulaire de droits de lecture définie par l'utilisateur.

Selon une autre particularité de la présente invention, ledit ensemble de données étant une base de fédération et le serveur étant un fournisseur d'identité, des demandes de modifications liées au compte utilisateur sont enregistrées par le fournisseur d'identité dans un journal afin de les proposer à l'utilisateur lorsque ce dernier déchiffre la base de fédération.

Ainsi, le procédé de gestion permet de fiabiliser un procédé basé sur la fédération d'identités en augmentant la protection de la vie privée de ses utilisateurs et la modification de la base de fédération se fait toujours sous le contrôle de l'utilisateur.

L'invention vise aussi un système de gestion sécurisée de données entre un serveur et un client connectés entre eux au moyen d'un réseau de communication, le serveur comportant: -un premier moyen de production destiné à créer un compte, un identifiant dudit compte, et un moyen d'authentification auprès de ce compte pour un utilisateur associé audit client, - un moyen de communication destiné à communiquer audit utilisateur l'identifiant dudit compte et le moyen d'authentification auprès de ce 25 compte, et - un deuxième moyen de production destiné au tirage d'un biclef comprenant une clef publique et une clef privée, la clef publique étant conservée par le serveur en association avec le compte utilisateur.

Ainsi, ce système offre une très bonne protection à la fois contre des attaques menées à distance et contre l'accès aux données par un acteur ayant physiquement accès au serveur ainsi que contre des éventuels défauts d'implémentation d'un mécanisme de contrôle d'accès logiciel.

Le serveur comporte en outre: -un moyen de traitement destiné à réaliser automatiquement le chiffrement/déchiffrement d'un ensemble de données déposé par l'utilisateur au moyen d'une clef de session pour former un ensemble de données chiffrées, et -une mémoire de masse destinée à stocker ledit ensemble de données 10 chiffrées.

Ainsi, le serveur du système de gestion réalise lui-même de manière sécurisée et automatique le chiffrement de l'ensemble de données déposé par l'utilisateur.

Selon une particularité de l'invention, la clef de session est stockée avec l'ensemble de données chiffrées dans la mémoire de masse du serveur, ladite clé de session étant chiffrée au moyen de la clef publique associée au compte utilisateur.

Ainsi, le système est compatible avec des clients légers lorsque la clef privée est par exemple chiffrée avec une phrase de passe .

L'invention vise aussi un serveur de gestion sécurisée de données, comportant: -un premier moyen de production destiné à créer un compte, un identifiant dudit compte et un moyen d'authentification auprès de ce compte pour un utilisateur, -un moyen de communication destiné à communiquer audit utilisateur l'identifiant dudit compte et le moyen d'authentification auprès de ce compte, -un deuxième moyen de production destiné au tirage d'un biclef comprenant une clef publique et une clef privée, la clef publique étant 30 conservée par le serveur en association avec le compte utilisateur, - un moyen de traitement destiné à réaliser automatiquement le chiffrement/déchiffrement d'un ensemble de données, et - une mémoire de masse destinée à stocker l'ensemble de données chiffrées.

Ainsi, ce serveur permet la réalisation d'un chiffrement/déchiffrement des données de manière simple efficace et sécurisée.

L'invention vise aussi un client de gestion sécurisée de données connecté à un serveur au moyen d'un réseau de communication, caractérisé en ce qu'il comporte: -des moyens de déchiffrement destinés à réaliser un déchiffrement d'une clef de session et/ou d'un ensemble de données chiffrées, et -un moyen de stockage destiné à stocker une clef privée produite par le serveur.

Ainsi, la clef privée n'est connue que du client et éventuellement le déchiffrement de l'ensemble de données chiffrées peut être entièrement réalisé sur le poste client lui-même offrant alors une sécurité optimale d'accès aux données.

L'invention vise également un programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé de gestion sécurisée selon les caractéristiques ci-dessus lorsqu'il est exécuté sur le serveur. Plus particulièrement, ledit programme est conçu pour permettre la création d'un compte pour un utilisateur associé audit client, la communication audit utilisateur d'un identifiant dudit compte et d'un moyen d'authentification auprès de ce compte, le tirage d'un biclef comprenant une clef publique et une clef privée, la clef publique étant conservée en association avec le compte utilisateur, la réalisation automatique du chiffrement/déchiffrement d'un ensemble de données, et le stockage de cet ensemble de données.

L'invention vise aussi un programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé de gestion sécurisée selon les caractéristiques ci-dessus lorsqu'il est exécuté sur le client. Plus particulièrement, ledit programme est conçu pour réaliser un déchiffrement d'une clef de session et/ou d'un ensemble de données chiffrées et pour stocker une clef privée produite par le serveur.

L'invention vise également une mise à disposition par téléchargement d'un programme d'ordinateur pouvant être exécuté sur le client.

Brève description des dessins

D'autres particularités et avantages de l'invention ressortiront à la lecture de la description faite, ci-après, à titre indicatif mais non limitatif, en référence aux dessins annexés, sur lesquels: -la figure 1 illustre schématiquement un système de gestion sécurisée de données entre un serveur et un client, selon l'invention; - la figure 2 illustre schématiquement un serveur selon la figure 1; - la figure 3 illustre schématiquement la création d'un compte 20 utilisateur dans le système de la figure 1, selon l'invention; - la figure 4 illustre schématiquement le dépôt et le chiffrement d'un ensemble de données, selon l'invention; - les figures 5A à 5C illustrent schématiquement des variantes de la lecture de l'ensemble de données, selon l'invention; -la figure 6 illustre schématiquement un client selon la figure 1; et - les figures 7 à 9 illustrent schématiquement un exemple d'une gestion sécurisée d'un ensemble de données selon l'invention.

Description détaillée de modes de réalisation

Conformément à l'invention, la figure 1 illustre un exemple schématique d'un système de gestion sécurisée de données entre un serveur 1 et un client 3 piloté par un utilisateur 5. Le client peut être un client léger ou un client riche et est connecté au serveur au moyen d'un réseau de communication 7. Par client léger, on entend le recours à un poste de travail ne nécessitant pas ou peu d'administration et se limitant généralement à effectuer des tâches d'affichage et de saisie et, par client riche, on entend la réunion des architectures client et Web au niveau du poste de travail.

Selon un premier exemple, ce système peut être utilisé pour le stockage et le contrôle d'accès sécurisé à des documents en mode client/serveur. Selon un autre exemple, le système peut être utilisé pour le stockage et le contrôle d'accès sécurisé à une base de fédération dans le cadre d'une fédération d'identités.

La figure 2 illustre un exemple schématique d'un serveur 1 selon l'invention comportant un premier moyen de production 11, un moyen de communication 13, un deuxième moyen de production 15, un moyen de traitement 17, et une mémoire de masse 19. Le moyen de traitement 17 contrôle tous les autres éléments 11, 13, 15 et 19 du serveur 1.

En outre, la figure 3 illustre des étapes de création d'un compte pour l'utilisateur 5 dans le système de gestion sécurisée de données entre le serveur 1 et un client 3.

A l'étape El, l'utilisateur 5 demande au serveur 1 la création d'un nouveau compte. Alors, aux étapes E2 à E6, le serveur 1 réalise le couplage d'un compte à une infrastructure à clé publique PKI.

En effet, à l'étape E2, le serveur 1 crée un compte pour l'utilisateur 5. En particulier, ce compte ainsi qu'un identifiant de ce compte et un moyen d'authentification (par exemple un mot de passe) auprès de ce compte sont créés par le premier moyen de production 11 du serveur 1. A titre d'exemple, le premier moyen de production 11 réserve une première zone de stockage 19a dans la mémoire de masse 19 du serveur 1 pour concrétiser ce compte associé à l'utilisateur 5.

A l'étape E3, le moyen de communication 13 du serveur 1 communique à l'utilisateur 5 l'identifiant et le moyen d'authentification concernant ce compte.

L'étape E4 concerne le tirage d'un biclef comprenant une clef publique et une clef privée pour réaliser un chiffrement/déchiffrement asymétrique. Plus particulièrement, le deuxième moyen de production 15 génère le biclef. De plus, le deuxième moyen de production 15 en relation avec le moyen de traitement 17, conservent (étape E5) la clef publique par exemple dans la première zone de stockage 19a de la mémoire de masse 19 du serveur 1 en association avec le compte de l'utilisateur.

Selon une première variante, à l'étape E6 (représentée en pointillé) la clef privée est stockée par le serveur 1 sous forme chiffrée par exemple dans la première zone de stockage 19a de la mémoire de masse 19 en association avec le compte de l'utilisateur. La clef privée peut être chiffrée à l'aide d'un mot de passe (ou d'une phrase de passe qui n'est autre qu'un mot de passe comportant plus de caractères, typiquement plusieurs dizaines ou plus encore) qui ne sera connu que de l'utilisateur, en utilisant par exemple un algorithme du type 3DES.

Selon cette première variante, la gestion sécurisée des données peut être réalisée en mode client léger. L'ordinateur client 3 peut dans ce cas comporter un simple logiciel d'interface graphique lui permettant d'afficher uniquement le résultat des traitements réalisés par le serveur 1.

Selon une seconde variante, la clef privée n'est pas conservée sur le serveur 1. En revanche, elle est conservée de façon sécurisée par l'utilisateur 5, par exemple sous la forme d'un support cryptographique du type carte à puce. Ainsi, la gestion sécurisée des données peut être réalisée en mode client riche permettant d'augmenter la confidentialité des données stockées sur le serveur 1.

On notera que le couplage d'un compte utilisateur avec une PKI, peut s'accommoder de toute forme de PKI. Dans sa forme la plus simple, la gestion de la PKI se réduit au tirage d'un biclef par compte réalisé par le serveur 1 lui-même. En effet, cette option est la plus naturelle dans un mode client léger Il est par ailleurs, envisageable de coupler une PKI plus classique à un système de comptes (certificats X.509, enregistrement de l'identité certifiée des porteurs de certificats...).

La figure 4 illustre des étapes concernant le dépôt et le chiffrement d'unensemble de données.

En effet, à l'étape E7, l'utilisateur 5 dépose un ensemble de données sur le serveur 1. A titre d'exemple, l'ensemble de données peut être transmis au serveur 1 en utilisant une requête HTTPS.

Eventuellement, l'ensemble de données peut être transmis au serveur 1 en utilisant une requête SMTP, auquel cas le dépôt de cet ensemble de données s'apparente à l'envoi d'un mail.

A l'étape E8, le moyen de traitement 17 du serveur 1 procède à un chiffrement automatique de cet ensemble de données au moyen de la clef publique associée au compte de l'utilisateur formant ainsi un ensemble de données chiffrées.

Plus particulièrement, le chiffrement de l'ensemble de données peut comporter la génération d'une clef de session de chiffrement, le chiffrement symétrique de l'ensemble de données avec la clef de session, et le chiffrement asymétrique de la clef de session avec la clef publique.

A l'étape E9, le moyen de traitement 17 réalise le stockage de cet ensemble de données chiffrées sur le serveur 1. A titre d'exemple, l'ensemble de données chiffrées peut être stocké dans une seconde zone de stockage 19b de la mémoire de masse 19 du serveur 1. On notera que la clef de session chiffrée est aussi stockée avec l'ensemble de données chiffrées dans la mémoire de masse 19 du serveur 1.

Les figures 5A à 5C illustrent des variantes de la lecture de l'ensemble de données chiffrées stocké sur le serveur.

Selon la première variante, l'étape E10 de la figure 5A concerne l'authentification de l'utilisateur 5 auprès du serveur 1.

L'étape E11 concerne la communication au serveur 1 par l'utilisateur 5 d'un moyen de déchiffrement de sa clef privée. Par exemple, l'utilisateur 5 communique au serveur 1, à travers un formulaire HTML, le mot de passe (ou phrase de passe) associé à la clef privée.

A l'étape E12, le moyen de traitement 17 réalise le déchiffrement de cette clef privée grâce au moyen de déchiffrement communiqué par l'utilisateur.

Ensuite, à l'étape E13, le moyen de traitement 17 procède au déchiffrement de la clef de session de chiffrement de l'ensemble de données au moyen de la clef privée déchiffrée de l'utilisateur 5.

Finalement, à l'étape E14, le moyen de traitement 17 réalise le déchiffrement de l'ensemble de données chiffrées au moyen de la clef de session déchiffrée permettant ainsi à l'utilisateur 5 de lire l'ensemble de données.

De la sorte, la clef privée de l'utilisateur 5 est connue par le serveur 1. Par contre, le serveur 1 réalise entièrement le processus de déchiffrement permettant à l'utilisateur 5 d'accéder à l'ensemble de données en mode client léger.

En revanche, selon la deuxième variante (figure 5B), la clef privée de l'utilisateur n'est connue que du client 3.

En effet, après l'étape E10 d'authentification de l'utilisateur 5, le serveur 1 envoie (étape E13) à l'utilisateur 5 la clef de session de chiffrement de l'ensemble de données.

A l'étape E14 l'utilisateur 5 déchiffre cette clef de session par des moyens locaux. Ces moyens locaux sont par exemple une extension logicielle sous forme d'un programme complémentaire ou plugiciel ( plugin en anglais) dans un navigateur capable d'utiliser la clef privée stockée dans le support cryptographique (carte à puce) de l'utilisateur 5.

A l'étape E15 l'utilisateur 5 renvoie au serveur 1, la clef de session déchiffrée, ce qui permet au moyen de traitement 17 du serveur 1 de déchiffrer à l'étape E16 l'ensemble de données chiffrées.

La figure 5C illustre une troisième variante de la lecture de l'ensemble de données.

Comme précédemment, après l'étape E10 d'authentification de l'utilisateur, le serveur 1 envoie (étape E13) à l'utilisateur 5 la clef de session de chiffrement de l'ensemble de données chiffrées.

De plus, à l'étape E17 le serveur 1 envoie à l'utilisateur 5 l'ensemble de données chiffrées.

A l'étape E14, l'utilisateur 5 déchiffre par ces moyens locaux la clef de session.

Finalement, à l'étape E18, l'utilisateur 5 déchiffre par des moyens locaux de déchiffrement (voir figure 6) l'ensemble de données chiffrées au moyen de la clef de session. Ceci permet d'augmenter la sécurité d'accès aux données. Bien entendu, dans ce cas, le client est un client riche.

En effet, la figure 6 illustre un client 3 de gestion sécurisée de données comportant des moyens de déchiffrement 21 et un moyen de 25 stockage 23.

Les moyens de déchiffrement 21 (par exemple un moyen de traitement) sont destinés à réaliser le déchiffrement de la clef de session générée par le serveur et/ou de l'ensemble de données chiffrées stocké sur le serveur 1.

En outre, le moyen de stockage 23 peut être destiné à stocker la clef privée produite par le serveur 1. Ce moyen de stockage 23 peut aussi stocker l'ensemble de données chiffrées envoyé par le serveur 1 et éventuellement l'ensemble de données déchiffrées par le client 3.

On notera que le procédé de gestion sécurisée selon l'invention peut être mis en oeuvre par des programmes d'ordinateurs comportant des instructions exécutées sur le serveur 1 et/ou le client 3.

En outre, le programme exécutable sur le client 3 peut être mis à disposition d'un utilisateur 5 par un téléchargement depuis par exemple le serveur 1.

Les figures 7 à 9 illustrent schématiquement un exemple d'une gestion sécurisée d'un ensemble de données formant un document numérique en relation avec un gestionnaire de documents du serveur 1. Cet exemple est adapté au cas particulier d'une architecture web de stockage et de partage de documents.

La figure 7 illustre la création pour un utilisateur d'un compte portedocuments dans le gestionnaire de documents du serveur 1.

L'étape E101 concerne la demande par l'utilisateur 5 d'une création d'un compte et éventuellement le choix du moyen 20 d'authentification auprès de ce compte.

L'étape E102 concerne la création et la réservation de ressources de stockage concrétisant un nouveau porte-documents appartenant au titulaire du compte.

L'étape E103 concerne la communication à l'utilisateur 5 d'un identifiant de compte et du moyen d'authentification auprès de ce compte.

L'étape E104 concerne le tirage d'un biclef pour un algorithme de chiffrement/déchiffrement asymétrique (exemple: RSA). La clef publique est conservée par le serveur (étape E106), en association avec le compte utilisateur.

En revanche, le traitement de la clef privée diffère selon la variante retenue.

En effet, dans une variante de client léger, la clef privée est chiffrée (étape E105) et est stockée (étape E106) avec la clef publique sur le serveur 1 sous forme chiffrée. Par exemple, la clef privée est chiffrée à l'aide d'un mot de passe qui ne sera connu que de l'utilisateur, en utilisant un algorithme tel que 3DES.

En revanche, dans une variante de client riche, la clef privée est conservée de façon sécurisée par l'utilisateur 5.

La figure 8 illustre le dépôt et chiffrement d'un document par le serveur 1. Selon cet exemple, tout acteur autorisé peut déposer de nouveaux documents dans le porte-documents.

Ainsi, à l'étape El11, un utilisateur émetteur 35 d'un document obtient l'identifiant de compte d'un client 3 destinataire.

A l'étape E112, l'émetteur 35 transmet des documents (initialement en clair) au serveur 1, par exemple en utilisant une requête HTTPS ou une requête du type SMTP. Dans ce dernier cas, il suffit que l'identifiant de compte du client 3 destinataire soit lié à une adresse mail.

Les étapes E113 à E115 concernent le chiffrement des documents par le serveur 1, à l'aide de la clef publique associée au compte. On peut utiliser un schéma de chiffrement classique, tel que PKCS#7 enveloped data .

Ainsi, l'étape E113 concerne la génération d'une clef de session de chiffrement. L'étape E114 concerne le chiffrement des documents avec la clef de session, en utilisant un algorithme symétrique. Finalement, l'étape E115 concerne le chiffrement de la clef de session avec la clef publique, en utilisant l'algorithme asymétrique prévu pour cette dernière.

Par ailleurs, l'étape E116 concerne le stockage et l'indexation des documents et de la clef de session ainsi chiffrés dans la mémoire de masse 19 du serveur 1.

Finalement, à l'étape E117, l'utilisateur 5 titulaire du compte est notifié du dépôt des documents.

On notera qu'un utilisateur émetteur 35 d'un document peut définir un ou plusieurs titulaires de droits de lecture du document au moment de dépôt de ce document. Pour cela, il suffit de désigner plusieurs destinataires, et de déclencher le chiffrement de la clef de session en plusieurs exemplaires, un par destinataire, à l'aide de la clef publique de chacun des destinataires.

La figure 9 illustre l'accès d'un utilisateur 5 titulaire d'un compte 10 porte-documents à ses documents.

L'étape E121 concerne l'établissement d'une session avec le serveur 1 de porte-documents, par exemple via le protocole HTTPS, en utilisant les moyens d'authentification qui ont été attribués lors de l'ouverture du compte. A titre d'exemple, ceci consiste en la saisie par l'utilisateur 5 de son identifiant de compte et d'un mot de passe dans un formulaire web, puis l'obtention par le navigateur Internet d'un jeton de session (par exemple un cookie) qui sera réemployé à chaque requête HTTPS ultérieure.

L'étape E122 concerne un affichage d'une liste de documents disponibles dans le porte-documents. Cette liste de documents est stockée dans la mémoire de masse 19 du serveur 1 et est disponible pour l'utilisateur 5 et éventuellement pour des titulaires de droits de lecture.

L'étape E123 concerne la sélection par l'utilisateur 5 (éventuellement un titulaire de droit de lecture) d'un document parmi ceux de la liste de documents disponibles en vue de son déchiffrement.

Les étapes E124 à E127 concernent le déchiffrement du document dans un mode de client léger. En effet, à l'étape E125, l'utilisateur 5 permet au serveur 1 de déchiffrer sa clef privée en communiquant (étape E124) au serveur 1, à travers un formulaire HTML, le mot de passe de chiffrement nécessaire.

Ensuite, à l'étape E126, le serveur 1 déchiffre, grâce à la clef privée, la clef de session de chiffrement du document.

Enfin, à l'étape E127, le serveur 1 déchiffre le document lui-même avant de l'envoyer ainsi déchiffré (étape E128) à l'utilisateur 5.

Dans un mode client riche, l'utilisateur 5 reçoit du serveur 1 la clef de session de chiffrement du document et la déchiffre par des moyens locaux. Ensuite, l'utilisateur 5 renvoie au serveur 1 la clef de session déchiffrée, ce qui permet au serveur 1 de déchiffrer le document lui-même. Ceci optimise la charge de calcul pour l'ordinateur de l'utilisateur 5, au détriment de celle du serveur 1.

Il est aussi envisageable que le serveur 1 communique directement le document chiffré à l'utilisateur 5 afin que ce dernier procède lui-même au déchiffrement du document.

Par ailleurs, on notera qu'il est possible d'élargir la liste des titulaires de droits de lecture sur un document chiffré.

Ainsi, dans un mode client léger, l'utilisateur 5, qui fait partie des titulaires de droits de lecture, sélectionne une liste d'utilisateurs auxquels il souhaite conférer également le droit de lecture sur le document.

Dans ce cas, l'utilisateur 5 communique son mot de passe de déchiffrement au serveur 1. Ceci permet au serveur 1 de déchiffrer la clef de session. Ensuite, le serveur 1 chiffre la clef de session avec la clef publique de chacun des nouveaux utilisateurs du document.

Par ailleurs, pour révoquer le droit de lecture d'un document pour un utilisateur donné, il suffit de supprimer la clef de session telle que chiffrée pour cet utilisateur.

Selon un autre exemple de gestion sécurisée de données, l'ensemble de données est une base de fédération et le serveur est un fournisseur d'identité.

Ainsi, la création d'un nouveau compte utilisateur sur le serveur 1 fournisseur d'identités se traduit par les étapes de la figure 3 explicitées précédemment.

Par ailleurs, lorsque l'utilisateur 1 s'authentifie sur le serveur 1 fournisseur d'identités ou lorsque ce dernier a besoin, pour la première fois d'accéder à la base de fédération, il est demandé à l'utilisateur de déchiffrer sa base de fédération afin que celle-ci puisse être utilisée dans le cadre de sa session selon les étapes des figures 6A à 6C explicitées précédemment.

En outre, lorsque la session de l'utilisateur sur le serveur 1 fournisseur d'identités prend fin suite à sa demande ou suite à une durée d'inactivité trop importante, la base de fédération est chiffrée et la forme déchiffrée est effacée. Le chiffrement de la base de fédération se fait selon les étapes de la figure 4 explicitées précédemment.

Par ailleurs, lorsque l'utilisateur 5 modifie, détruit ou crée de nouvelles fédérations, la base de fédération doit être mise à jour.

En effet, lorsque l'utilisateur est identifié sur le serveur 1 fournisseur d'identités et que la base de fédération est déchiffrée, la modification de la base de fédération peut se faire de façon classique. En effet, la base de fédération se trouve en clair, dans la mémoire vive du serveur. Afin de fiabiliser la prise en compte des changements, il peut être intéressant de renouveler le stockage sous forme chiffrée à chaque modification, sans attendre la fin de la session.

En revanche, lorsque la base de fédération n'est pas déchiffrée et que l'utilisateur n'intervient pas, alors, afin de mettre à jour la base de fédération, le serveur 1 fournisseur d'identités peut enregistrer dans un journal les demandes de modification et les proposer à l'utilisateur lorsqu'il déchiffre sa base de fédération.

Ainsi, la gestion sécurisée de données (documents numériques 30 ou base de fédération) selon l'invention permet un chiffrement en permanence des données stockés dans la mémoire de masse du serveur. Cela constitue une très bonne protection contre des attaques menées à distance en tirant parti de failles de sécurité logicielles.

De plus ce procédé constitue une très bonne protection afin que les personnes ayant physiquement accès au serveur (ou aux supports de sauvegarde) n'enfreignent pas leur devoir de confidentialité vis-à-vis des données stockées.

En outre, cette gestion sécurisée de données apporte un excellent compromis entre ergonomie et sécurité, puisqu'elle apporte un service de chiffrement, sans faire peser de contrainte ergonomique au niveau des postes clients. En effet, un navigateur Internet suffit. Quant au retrait de données, dans le mode client léger, il ne demande comme prérequis que la connaissance de d'un mot ou phrase de passe.

Claims (20)

REVENDICATIONS

1. Procédé de gestion sécurisée de données entre un serveur (1) et un client (3) connectés entre eux au moyen d'un réseau de communication (7), caractérisé en ce qu'il comporte les étapes suivantes: création par le serveur (1) d'un compte pour un utilisateur (5) associé audit client (3), communication audit utilisateur (5) d'un identifiant dudit compte et d'un moyen d'authentification auprès de ce compte, et tirage d'un biclef comprenant une clef publique et une clef privée, la clef publique étant conservée par le serveur (1) en association avec le compte utilisateur.

2. Procédé de gestion selon la revendication 1, caractérisé en ce que la clef privée est stockée par le serveur (1) sous forme chiffrée au moyen d'un mot ou phrase de passe en association avec le compte utilisateur.

3. Procédé de gestion selon la revendication 1, caractérisé en ce que la clef privée est conservée de façon sécurisée par l'utilisateur (5).

4. Procédé de gestion selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comporte en outre les étapes suivantes: dépôt par l'utilisateur (5) d'un ensemble de données sur le serveur (1), chiffrement automatique dudit ensemble de données par le serveur (1) pour former un ensemble de données chiffrées, et stockage dudit ensemble de données chiffrées dans une mémoire de masse du serveur (19).

5. Procédé de gestion selon la revendication 4, caractérisé en ce que le 25 chiffrement automatique dudit ensemble de données comporte les étapes suivantes: génération d'une clef de session de chiffrement, chiffrement dudit ensemble de données avec la clef de session, et chiffrement de la clef de session avec la clef publique, la clef de session chiffrée étant stockée avec l'ensemble de données chiffrées dans la mémoire de masse (19) du serveur (1).

6. Procédé de gestion selon la revendication 4 ou la revendication 5, caractérisé en ce que la lecture dudit ensemble de données est réalisée selon les étapes suivantes: authentification de l'utilisateur (5) auprès du serveur (1), communication au serveur par l'utilisateur d'un moyen de déchiffrement de la clef privée associée au compte utilisateur, déchiffrement par le serveur (1) de ladite clef privée, déchiffrement par le serveur (1) de la clef de session de chiffrement dudit ensemble de données au moyen de ladite clef privée, et déchiffrement par le serveur (1) dudit ensemble de données chiffrées au moyen de la clef de session permettant la lecture dudit ensemble de données.

7. Procédé de gestion selon la revendication 4 ou la revendication 5, caractérisé en ce que la lecture dudit ensemble de données est réalisée selon les étapes suivantes: authentification de l'utilisateur (5) auprès du serveur (1), envoi à l'utilisateur de la clef de session de chiffrement dudit ensemble de données, ladite clef de session étant chiffrée, déchiffrement par des moyens locaux de l'utilisateur de ladite clef de session au moyen de la clef privée conservée par l'utilisateur, renvoi au serveur (1) de la clef de session déchiffrée, et déchiffrement par le serveur dudit ensemble de données chiffrées au moyen de la clef de session.

8. Procédé de gestion selon la revendication 4 ou la revendication 5, caractérisé en ce que la lecture dudit ensemble de données est réalisée selon les étapes suivantes: authentification de l'utilisateur (5) auprès du serveur (1), envoi à l'utilisateur de la clef de session de chiffrement dudit ensemble de données ladite clef de session étant chiffrée, ainsi que dudit ensemble de données chiffrées, déchiffrement par des moyens locaux de l'utilisateur de ladite clef de session au moyen de la clef privée conservée par l'utilisateur, et déchiffrement par les moyens locaux de l'utilisateur dudit ensemble de données chiffrées au moyen de la clef de session.

9. Procédé de gestion selon l'une quelconque des revendications 4 à 8, caractérisé en ce qu'il comporte en outre les étapes suivantes: affichage d'une liste de documents stockés dans la mémoire de masse (19) du serveur (1) et disponibles pour l'utilisateur et/ou des titulaires de droits de lecture, et sélection par l'utilisateur et/ou un titulaire de droit de lecture d'un document parmi ladite liste de documents en vue de son déchiffrement.

10. Procédé de gestion selon l'une quelconque des revendications 4 à 8, caractérisé en ce que ledit ensemble de données étant une base de fédération et le serveur étant un fournisseur d'identité, des demandes de modifications liées au compte utilisateur sont enregistrées par le fournisseur d'identité dans un journal afin de les proposer à l'utilisateur lorsque ce dernier déchiffre la base de fédération.

11. Système de gestion sécurisée de données entre un serveur (1) et un client (3) connectés entre eux au moyen d'un réseau de communication (7), caractérisé en ce que le serveur comporte: un premier moyen de production (11) destiné à créer un compte, un identifiant dudit compte, et un moyen d'authentification auprès de ce compte pour un utilisateur associé audit client, un moyen de communication (13) destiné à communiquer audit utilisateur l'identifiant dudit compte et le moyen d'authentification auprès de ce compte, et un deuxième moyen de production (15) destiné au tirage d'un biclef comprenant une clef publique et une clef privée, la clef publique étant conservée par le serveur en association avec le compte utilisateur.

12. Système de gestion selon la revendication 11, caractérisé en ce que le serveur comporte en outre: un moyen de traitement (17) destiné à réaliser automatiquement le chiffrement/déchiffrement d'un ensemble de données déposé par l'utilisateur au moyen d'une clef de session pour former un ensemble de données chiffrées, et une mémoire de masse (19) destinée à stocker ledit ensemble de données chiffrées.

13. Système de gestion selon l'une quelconque des revendications 11 et 12, caractérisé en ce que la clef de session est stockée avec l'ensemble de données chiffrées dans la mémoire de masse (19) du serveur (1), ladite clef de session étant chiffrée au moyen de la clef publique associée au compte utilisateur.

14. Serveur de gestion sécurisée de données, caractérisé en ce qu'il comporte: un premier moyen de production (11) destiné à créer un compte, un identifiant dudit compte et un moyen d'authentification auprès de ce compte pour un utilisateur, un moyen de communication (13) destiné à communiquer audit utilisateur l'identifiant dudit compte et le moyen d'authentification auprès de ce compte, un deuxième moyen de production (15) destiné au tirage d'un biclef comprenant une clef publique et une clef privée, la clef publique étant conservée par le serveur en association avec le compte utilisateur, un moyen de traitement (17) destiné à réaliser automatiquement le chiffrement/déchiffrement d'un ensemble de données, et une mémoire de masse (19) destinée à stocker l'ensemble de données 10 chiffrées.

15. Client de gestion sécurisée de données connecté à un serveur au moyen d'un réseau de communication, caractérisé en ce qu'il comporte: des moyens de déchiffrement (21) destinés à réaliser un déchiffrement d'une clef de session et/ou d'un ensemble de données chiffrées, et un moyen de stockage (23) destiné à stocker une clef privée produite par le serveur.

16. Programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé de gestion sécurisée selon l'une quelconque des revendications 1 à 10 lorsque ledit programme est exécuté sur un serveur.

17. Programme d'ordinateur exécuté sur un serveur de gestion sécurisée de données, ledit programme étant conçu pour permettre la création d'un compte pour un utilisateur associé audit client, la communication audit utilisateur d'un identifiant dudit compte et d'un moyen d'authentification auprès de ce compte, le tirage d'un biclef comprenant une clef publique et une clef privée, la clef publique étant conservée en association avec le compte utilisateur, la réalisation automatique du chiffrement/déchiffrement d'un ensemble de données, et le stockage de cet ensemble de données.

18. Programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé de gestion sécurisée selon l'une quelconque des revendications 1 à 10 lorsque ledit programme est exécuté sur un client.

19. Programme d'ordinateur exécuté sur un client de gestion sécurisée de données connecté à un serveur au moyen d'un réseau de communication, ledit programme étant conçu pour réaliser un déchiffrement d'une clef de session et/ou d'un ensemble de données chiffrées et pour stocker une clef privée produite par le serveur.

20. Mise à disposition par téléchargement d'un programme d'ordinateur 10 selon la revendication 18.