FR3020697A1

FR3020697A1 - Dispositif pour detecter automatiquement et pour proteger de facon autonome la confidentialite et l'integrite des informations contenues dans des balises "tag" du standard "html"

Info

Publication number: FR3020697A1
Application number: FR1401056A
Authority: FR
Inventors: Vladimir Sekletov
Original assignee: Individual
Current assignee: Individual
Priority date: 2014-05-05
Filing date: 2014-05-05
Publication date: 2015-11-06

Abstract

Les solutions proposées, pour échanger des informations sécurisées, imposent de fortes modifications des architectures « client-serveur » et imposent des formats spécifiques de balises TAG propriétaires devant être pré-insérées dans les documents HTML. Ces formats sont fixés par le serveur et sont contraints à l'utilisateur, faisant que cela ne permet pas à un utilisateur de protéger ses saisies d'informations pour son propre usage ou pour l'usage de ces informations dans un réseau d'utilisateurs. Avantageusement, le dispositif permet de partager des informations dans des groupes sécurisés d'utilisateurs qui sont et restent sous le contrôle de l'utilisateur qui les a créés. Les champs d'information contenus dans les TAG d'un document HTML peuvent être protégés en confidentialité et intégrité sans modification de la structure et de la syntaxe des TAG et des attributs des TAG, telles que définies par le World Wide Web Consortium (W3C). Le dispositif selon l'invention est destiné à sécuriser des informations en vue d'être échangées, partagées ou sauvegardées sur internet et d'accès limité à un réseau de personnes. c'est un moyen de protéger les informations versées dans les réseaux sociaux internet et d'une façon plus générale des informations placées dans le « cloud computing »

Description

La présente invention concerne un dispositif mettant en oeuvre la protection en confidentialité et en intégrité du contenu des balises du langage HTML afin d'assurer la confidentialité et l'intégrité des informations, sauvegardées, échangées et partagées sur Internet, par et entre des utilisateurs, au travers de serveurs, de Personal Computers, de smartphones et de tablettes. De la publication de la Request For Comments 1866 « Hypertext Markup Language 2.0 » est connu un dispositif pour créer des documents HTML portables entre plateformes informatiques. Ce dispositif présente comme principal inconvénient de ne pas protéger en confidentialité et en intégrité les informations balisées et contenues dans les documents HTML exploités par les plateformes informatiques. De la publication des Request For Comments, « The Secure Sockets Layer (SSL) Protocol » (RFC 6101) et de la publication « The Transport Layer Security (TLS) Protocol » (RFC 4346) sont connus des dispositifs « client-serveur » utilisant un serveur pour gérer la sécurisation des échanges entre clients. Ce dispositif présente comme principal inconvénient d'être exposé aux dispositifs « serveur proxy HTTPS » qui réalisent des ruptures de confidentialité et d'intégrité dans l'échange client-serveur. Ce dispositif présente comme second inconvénient de ne pas protéger l'information au-delà du lien SSL ou du lien TLS, faisant que l'information échangée n'est pas protégée sur le serveur et sur le client. De la publication du brevet « Dynamic assignment of security parameters to web page » (US 6 029 245) est connu un dispositif pour imposer un protocole de communication sécurisé à partir de paramètres de configuration insérés dans un document HTML. Ce dispositif présente comme principal inconvénient de devoir modifier les documents HTML en y insérant des balises TAG propriétaires contenant les informations de configuration HTTPS, par exemple. Ceci nécessitant d'être détenteur d'un serveur HTTP pour pratiquer cette modification. Ce dispositif présente comme second inconvénient de ne pas protéger en confidentialité et en intégrité le contenu des TAG et d'être ainsi exposé aux dispositifs « serveur proxy HTTPS » qui réalisent des ruptures de confidentialité et d'intégrité dans les échanges client-serveur.

De la publication du brevet « Method for electronic communication providing self-encrypting and self-verification capabilities » (US 2002/0184485) est connu un dispositif pour signer et vérifier la signature d'un document HTML. Ce dispositif 5 présente comme principal inconvénient de faire intervenir un developpeur informatique pour intégrer, dans chaque document HTML, un programme de signature et créer les champs nécessaires au transport de la signature. Ce dispositif présente comme second inconvénient de ne pas protéger en confidentialité et en intégrité les informations balisées et contenues dans les 10 documents HTML exploités par les plateformes informatiques. De la publication du brevet « Procédé pour accéder à un système d'information disposé derrière une passerelle informatique » (PCT/FR2012/000403) est connu un dispositif pour accéder à un document HTML 15 par la saisie d'un code PIN (Personal Identifier Number) et la création d'une signature. Ce dispositif présente comme principal inconvénient de ne pas cloisonner en confidentialité et en intégrité les informations balisées et contenues dans les documents HTML. Ce dispositif présente comme second inconvénient d'imposer l'ajout d'une passerelle d'accès matérielle et logicielle, pour assurer un 20 contrôle de droit d'accès au serveur d'information, sans pour autant proposer de sécurisation de contenu d'information privée. De la publication du brevet « Method and system for secure data transmission » (WO 01/61962 A1) est connu un dispositif pour chiffrer un 25 document et le transmettre depuis un serveur à un utilisateur émetteur de la demande. Ce dispositif présente comme principal inconvénient d'utiliser une clé publique de chiffrement pour chiffrer un document devant traverser l'Internet. La conséquence de cette méthode est qu'un attaquant ayant accès à Internet et disposant de la clé publique du demandeur peut envoyer à ce demandeur des 30 documents contrefaits. Ce dispositif présente comme second inconvénient d'imposer l'utilisation d'un serveur pour réaliser les opérations de sécurisation (Chiffrement) en lieu et pour place du demandeur. En d'autres termes, un utilisateur ne peut pas protéger lui-même ses informations. Seul le serveur proposé est maître des informations qu'il met à disposition d'un utilisateur, faisant que cette méthode ne peut pas être appliquée à la sécurisation des réseaux sociaux. Ce dispositif présente comme troisième inconvénient de ne pas permettre à un utilisateur de protéger, par ses propres moyens cryptographiques, en confidentialité et en intégrité, les informations balisées et contenues dans les documents HTML, pour son propre usage ou pour l'usage d'un ensemble d'utilisateurs appartenant à un réseau d'utilisateur de confiance avec qui l'utilisateur souhaite partager des informations confidentielles et intègres. De la publication du brevet « Système et méthode de securité de serveur d'institution financière et de client browser de réseau » (EP 0880254 A2/A3) est connu un dispositif pour chiffrer et déchiffrer le TAG « FORM » d'un document HTML échangé avec un serveur dédié. Ce dispositif présente comme principal inconvénient d'imposer un format spécifique (« Directives de format ») au tag « FORM » du document HTML pour réaliser un transfert d'information sécurisée en y insérant par exemple des directives sur l'opération à réaliser. Ce format est fixé par le serveur et est imposé à l'utilisateur, faisant que cette méthode ne peut pas être appliquée à la sécurisation des réseaux sociaux. Ce dispositif présente comme second inconvénient d'utiliser une clé de session produite par le navigateur Web et non pas par l'utilisateur. Plus particulièrement, l'usage de ce type de clé ne permet pas à un utilisateur de protéger en confidentialité et en intégrité les informations pour son propre usage ou pour l'usage d'un ensemble d'utilisateurs appartenant à un réseau d'utilisateur de confiance avec qui l'utilisateur souhaite partager des informations confidentielles et intègres.

De la publication « Secure/Multipurpose Internet Mail Extensions (S/MIME) », référencée RFC 5751, est connu un dispositif pour sécuriser le corps des courriers électroniques envoyés entre ordinateurs. Ce dispositif présente comme principal inconvénient de ne pas être supporté par les messageries électroniques au format HTML. Ce dispositif présente comme second inconvénient de ne pas protéger, en confidentialité et intégrité, l'en-tête du message contenant particulièrement l'objet du message. Avantageusement, le dispositif comprend les capacités suivantes pour permettre à un utilisateur, au travers d'un serveur, d'un Personal Computer, d'un smartphone et d'une tablette, de protéger en confidentialité et en intégrité les informations contenues dans des balises « tag » du standard « HTML », sans modification des attributs des « tag »: - Partager des informations dans des groupes sécurisés d'utilisateurs qui sont et restent sous le contrôle de l'utilisateur qui les a créés. Ce partage permettant de gérer différents niveaux de besoin d'en connaître (Cf. TCSEC-Trusted Computer System Evaluation Criteria, ISO/IEC 15408 Common Criteria) dans un même document HTML. - D'auto-détecter les champs d'information pouvant être sécurisés dans un document HTML ; - D'auto-détecter dans un document HTML les champs d'information pouvant être faire l'objet d'un déchiffrement et d'un contrôle d'intégrité ; - De protéger en confidentialité et en intégrité les champs d'information d'un document HTML proposés par l'auto-détection ; - De protéger en confidentialité et en intégrité l'objet et le corps d'un message électronique présenté dans un document HTML ; - D'accéder au contenu sécurisé de tout document lié à un document HTML par sa source indiquée dans un attribut du TAG ; - De protéger en confidentialité et intégrité les champs d'information des documents HTML sans modifier la structure et la syntaxe des TAG et des attributs des TAG, telles que définies par le World Wide Web Consortium (W3C) La présente invention sera mieux comprise à l'étude d'un mode de réalisation particulier pris à titre d'exemple nullement limitatif et illustré par les dessins annexés, sur lesquels : la figure 1 présente un schéma général d'échanges de contenus HTML entre ordinateurs ; la figure 2 présente une communication HTTPS entre ordinateurs rendue discontinue par l'intervention d'un « serveur proxy HTTPS » ; la figure 3 est un schéma général d'échanges entre ordinateurs du contenu sécurisé des balises HTML ; la figure 4 présente un mode de réalisation du dispositif de protection des balises HTML sur un ordinateur traitant d'un document HTML ; la figure 5 présente une protection continue du contenu des balises HTML jusqu'au dispositif de sauvegarde qui comble les ruptures de confidentialité et d'intégrité introduites par les « serveur proxy HTTPS ». En référence à la figure 4, le dispositif conforme à l'invention comprend un logiciel de gestion de la protection des TAG (400) qui participe à l'invention en mettant en oeuvre le procédé technique qui solutionne l'absence de confidentialité et d'intégrité des informations échangées entre ordinateurs et contenues dans des balises TAG du standard « HTML » (W3C).

Le dispositif (400) exploite un document HTML (401) pour extraire (410) les noms des TAG : A, INPUT, IMG, VIDEO, TEXTAREA, BODY, DIV, TEXTBOX, EMBED (A titre d'exemples nullement limitatifs) et leurs attributs associés (430) : TYPE, ID, CLASS, SRC, HREF, MAXLENGTH (A titre d'exemples nullement limitatifs) Le dispositif (420) ajoute une balise avec un identifiant unique dans le document 20 HTML (401) pour chaque TAG identifié (410) et reconnu sécurisable en confidentialité et en intégrité par ses attributs (430). Les opérations possibles sont déterminées par le mécanisme (430) et sont exploitées par le mécanisme (450) de traitement des contenus qui décidera de la 25 mise en oeuvre d'un chiffrement ou d'un déchiffrement (440). Particulièrement, le mécanisme (430) fait appel aux mécanismes d'identification pour s'assurer de la concordance entre le TAG identifié et les attributs déclarés. Ainsi, le mécanisme (431) s'assure que le TYPE de données déclaré est 30 conforme au TAG identifié. Par exemple et dans ce cas précis nullement limitatif, le résultat attendu par le mécanisme (430) est que pour un TAG INPUT, l'attribut TYPE soit TEXT, FILE, PASSWORD ou SEARCH. En fonction de l'association identifiée, le mécanisme (430) détermine les opérations possibles comme étant une action sur un texte (TEXT, PASSWORD, SEARCH) ou sur un fichier (FILE).

Dans cet exemple nullement limitatif, le mécanisme (450) est alors en mesure de commander une opération de chiffrement ou une opération de déchiffrement (440), soit directement dans le champs texte VALUE (432) proposé par le TAG INPUT, soit en opérant sur la source du fichier référencé (435). Dans le second exemple, le mécanisme (450) commande une opération de chiffrement (440) sur le fichier « FILE » accessible à l'adresse identifiée par l'attribut « SRC ». <HTML> <INPUT TYPE=« FILE » SRC= « ADRESSE FICHIER » /> </HTML> Le fichier « FILE » est récupéré à l'adresse « ADRESSE FICHIER » et est chiffré (440). Le « cryptogramme » du fichier est alors envoyé et sauvegardé sur le serveur émetteur du document HTML. Lors de la consultation du document HTML référant ce fichier « cryptogramme » à l'adresse « ADRESSE CRYPTOGRAMME », le mécanisme (430) identifie la correspondance entre le TAG « A » et l'attribut du TAG « HREF » : <HTML> <A HREF=« ADRESSE CRYPTOGRAMME » </A> </HTML> Le mécanisme (430) propose le fichier placé à l'adresse « ADRESSE CRYPTOGRAMME » au mécanisme (450), lequel analyse la présence d'un 25 « cryptogramme » dans le fichier et commande alors une opération de déchiffrement (440) local du fichier chiffré distant. Le mécanisme (450) met en oeuvre deux méthodes de traitement des contenus. La première méthode traite le chiffrement ou le déchiffrement (440) d'un seul 30 contenu balisé et identifié par le mécanisme (420). La seconde méthode automatise le chiffrement ou le déchiffrement (440) de tous les contenus balisés et identifiés par le mécanisme (420). Le mécanisme (450) s'appuie sur le mécanisme (470) pour obtenir les informations de sécurité à appliquer et qui sont propres au groupe sélectionné pour réaliser le chiffrement ou le déchiffrement (440). En référence à la figure 3, à la figure 4 et à la figure 1, le dispositif conforme à 5 l'invention permet à un utilisateur au travers d'un smartphone ou d'une tablette (310), d'un ordinateur personnel (320) ou d'un serveur (350), d'échanger des contenus protégés en confidentialité et en intégrité. Pour cela, le mécanisme (470) associe des utilisateurs (310), (320) et (350) à un groupe disposant d'un même niveau de protection en confidentialité et en intégrité, leur permettant ainsi 10 de partager de façon protégée (301) un contenu TAG initialement non protégé (101). Ce mécanisme (470) met à disposition du mécanisme (430) les informations nécessaires au chiffrement de l'information ou au déchiffrement du cryptogramme (440). Par exemple, l'information contenue dans le champs « VALUE » du TAG « INPUT » : 15 <HTML> <INPUT VALUE= « INFORMATION » /> </HTM L> et échangée par les ordinateurs (110), (120) et (150) via un réseau (130), est chiffrée en un cryptogramme : 20 <HTML> ...« CRYPTOGRAMME »... </HTM L> remplaçant la valeur « INFORMATION » initiale pour être sauvegardée intègre et confidentielle (340). Inversement, lors de la consultation du document HTML via 25 le réseau (330), les ordinateurs disposant du mécanisme (400) accédent à l'information d'origine en déchiffrant localement le « cryptogramme » récupéré dans la source du document HTML et compris entre les balises « <HTML> » et « </HTML> ». Dans les deux cas, les TAGs et les attributs des TAGs du document HTML ne sont pas altérés et restent tel qu'ils ont été émis par le 30 serveur HTTP. Afin de pouvoir partager l'accès à cette information protégée en « cryptogramme », le mécanisme (470) doit avoir construit un groupe sécurisé comme une liste d'utilisateurs autorisés (membres), chacun identifié par une adresse e-mail associée à une clé secrète. Le groupe constitué est chiffré individuellement avec la clé publique du membre du groupe destinataire et transmis par un moyen physique ou logique à ce membre. Chaque membre reçoit alors le groupe constitué et chiffré avec sa clé publique. Le groupe sécurisé conservé chiffré est déchiffré pour chaque demande cryptographique (440).

Le mécanisme (470) construit des groupes sécurisés en s'appuyant sur le mécanisme (460) pour acquérir l'autonomie des moyens cryptographiques assurant la sécurisation des informations. Ce générateur (460) a en charge la production locale de clés secrètes et de bi-clés permettant d'éviter de faire appel à une tierce partie pour la protection d'information privée. Ainsi, chaque groupe constitué dispose seul de la connaissance des clés utilisées pour accéder à l'information protégée en « cryptogramme ». Lors du déclenchement d'une opération de chiffrement, le mécanisme (470) utilise la clé secrète du groupe sélectionné pour chiffrer l'information. Cette opération insère un identifiant de groupe, un identifiant de clé secrète, un identifiant d'algorithme cryptographique et un identifiant d'algorithme d'intégrité, dans le cryptogramme, faisant qu'aucune clé secrète et qu'aucune autre information directement exploitable ne transite avec le cryptogramme. Durant la consultation du document HTML, le mécanisme (450) détecte directement dans le document HTML la présence d'un cryptogramme encapsulé dans des balises et s'appuie sur le mécanisme (470) pour récupérer ces identifiants. Le mécanisme (470) compare ces identifants à ceux qui sont localement en sa possession : pour retrouver le groupe concerné, la clé secrète et les algorithmes utilisés, et finalement pour déchiffrer le cryptogramme. Comme chaque contenu de TAG peut être sécurisé pour un seul groupe, un document HTML peut contenir autant de contenus sécurisés pour différents groupes qu'il y a de contenus exploitables de TAG. Par exemple nullement limitatif, quand un document HTML contient trois TAGs « INPUT » pouvant être renseignés par la saisie d'informations dans leurs champs « VALUE » respectifs, alors il est possible de sécuriser chacun de ces champs avec les moyens cryptographiques de groupes sécurisés différents. <HTML> <INPUT VALUE= « INFORMATION GROUPE 1 » /> <INPUT VALUE= « INFORMATION GROUPE 2 » /> <INPUT VALUE= « INFORMATION GROUPE 3 » /> </HTML> Ainsi, le document HTML consulté contient maintenant des cryptogrammes non déchiffrables par tous les groupes. Seul le « cryptogramme groupe 1 » peut être déchiffré par les membres du « groupe 1 », seul le « cryptogramme groupe 2 » peut être déchiffré par les membres du « groupe 2 » et seul le « cryptogramme groupe 3 » peut être déchiffré par les membres du « groupe 3 ». <HTML> ...« CRYPTOGRAMME GROUPE 1 »... ...« CRYPTOGRAMME GROUPE 2 »... ...« CRYPTOGRAMME GROUPE 3 »... </HTML> L'association du mécanisme (450) et du mécanisme (470) est donc en mesure de réaliser le concept de « besoin d'en connaître », de type « multi-niveaux », dans un document HTML.

Des limitations sur les champs de saisie de texte sont parfois imposées par le créateur du document HTML (401) au travers de l'usage de l'attribut MAXLENGTH pour un champs de texte (434) ou par l'usage de script vérifiant le nombre de caractères textes renseignés dans un champs de données (433). Le mécanisme (430) se charge de déterminer les opérations possibles limitatives en fonction de l'analyse remontée par le mécanisme (434) et par le mécanisme (433). En référence à la figure 5, le dispositif conforme à l'invention permet de combler les ruptures de protection, de la confidentialité et de l'intégrité de la figure 2, provoquées par les serveurs proxy HTTPS (220). Les informations (240) présentent sur l'ordinateur client (210), sur le serveur proxy HTTPS (220) et sur le serveur HTTPS, échappent à la protection des segments (211) et (221). Le mécanisme (400), décrit dans la figure 4, protège l'information (240) en confidentialité et intégrité en disposant un segment protégé (540) de « bout-enbout » jusqu'à sa sauvegarde (550), au-dessus des segments HTTPS (511)(521). Ainsi, les équipements actifs ou passifs du réseau peuvent ne plus être considérés comme sensibles, du point de vue de la sécurité, puisque ces équipements actifs ou passifs ne disposent plus d'information sensible, de par leur confidentialité et de par leur intégrité. Tous les secteurs de l'industrie traitant d'informations sensibles en 5 confidentialité et en intégrité sont concernés par la présente invention. Les métiers exposés au nomadisme pourront trouver bénéfice à utiliser ce dispositif. Le dispositif selon l'invention est particulièrement destiné à sécuriser des informations privées, commerciales et techniques en vue d'être échangées, 10 partagées ou sauvegardées sur Internet et d'accès limité à un réseau de personnes. C'est un moyen de protéger les informations versées dans les réseaux sociaux Internet et d'une façon plus générale des informations placées dans le « Cloud » 15 Ce dispositif peut être particulièrement utile pour les métiers « libéraux » exposés à la confidentialité des informations qu'ils traitent (e.g. Domaine médical, échanges entre un avocat et son client) Ce dispositif peut être également utile dans les métiers « bancaires » pour la 20 protection de la transmission des informations confidentielles à chacun de ses clients (e.g. Solde courant d'un compte) Une entreprise pourra trouver aussi avantage à utiliser ce dispositif, pour protéger les contenus des pages HTML de son site Internet ou Intranet, pour mettre en 25 oeuvre un cloisonnement fort des informations entre les projets gérés par l'entreprise ou bien des informations personnelles des salariés de l'entreprise, mais aussi des informations échangées avec les sous traitants ou les clients de l'entreprise.

30 La présente invention n'est nullement limitée aux modes de réalisation décrits et représentés mais l'homme du métier saura y apporter toute variante conforme à son esprit.

Claims

REVENDICATIONS1) Dispositif pour sécuriser en confidentialité et en intégrité des échanges entre utilisateurs, au travers de serveurs, de Personal Computers, de smartphones et de tablettes, caractérisé en ce que le mécanisme (400) chiffre, déchiffre et protège en intégrité les contenus des TAG d'un document HTML (401) dont la syntaxe et la grammaire sont définies par le World Wide Web Consortium (W3C).
2) Dispositif selon la revendication 1 caractérisé en ce qu'il comprend un 10 mécanisme (430) de détermination des opérations de sécurisation possibles sur les contenus des TAG.
3) Dispositif selon la revendication 1 caractérisé en ce qu'il comprend un mécanisme (420) d'ajout d'une balise visuelle associée à chaque TAG reconnu sécurisable en confidentialité et en intégrité par son identifiant (410) et par ses 15 attributs (430).
4) Dispositif selon la revendication 1 caractérisé en ce qu'il comprend un mécanisme de détection (450) de l'opération de chiffrement ou de déchiffrement (440) à réaliser en fonction de l'information contenue dans le TAG (430).
5) Dispositif selon la revendication 1 caractérisé en ce qu'il comprend un 20 mécanisme (470) de regroupement d'utilisateurs partageant un même « besoin et droit d'en connaître » pour leurs propres échanges de contenus de TAG (301).
6) Dispositif selon la revendication 1 caractérisé en ce qu'il comprend un mécanisme (540), au-dessus de HTTPS, permettant à un ordinateur de propager la confidentialité et l'intégrité du contenu d'un TAG d'un document HTML sur le 25 serveur de ce document HTML (401).
7) Dispositif selon la revendication 1 caractérisé en ce qu'il comprend un mécanisme de chiffrement et de déchiffrement (440) d'un fichier référencé par sa source (435) dans un document HTML (401).