Brevet FR2862170A1 — publié le 20050513

"Procédé de transfert de données confidentielles en coeur de réseaux" La présente invention concerne un procédé de transfert de données confidentielles en coeur de réseaux. Elle trouve application notamment dans les domaines des transactions utilisant le réseau Internet. Dans le domaine technique des communications téléinformatiques, les utilisateurs qui veulent consulter des contenus de données par un réseau informatique comme le réseau Internet, io doivent dans la plupart des cas obtenir une ressource de connexion auprès d'un fournisseur d'accès au réseau téléinformatique. Quand l'échange de données met en relation fournisseur de contenus, par exemple doté d'un serveur Web avec un utilisateur doté d'un navigateur exécuté sur un terminal connecté physiquement au réseau Internet, trois opérateurs économiques distincts se sont développés: - les fournisseurs d'accès au réseau; - les fournisseurs de contenus qui proposent le transfert de fichiers de données numériques comme des pages html ou des images ou séquences vidéo, et aussi proposent à la vente par le moyen de tels fichiers, des biens comme des produits ou des services à des utilisateurs; - les utilisateurs clients de ces fournisseurs de contenus qui souhaitent consulter les contenus numériques disponibles et le cas échéant effectuer des transactions confidentielles comme des achats avec les fournisseurs de contenus. Les utilisateurs clients des fournisseurs de contenus ont besoin de disposer d'un premier contrat avec un fournisseur d'accès au réseau téléinformatique. Puis, les échanges de données se déroulent sans intervention réelle du fournisseur d'accès au réseau. Or, les communications entre leurs utilisateurs et les fournisseurs de contenus contiennent de plus en plus fréquemment des données confidentielles. 2862170 2 C'est particulièrement le cas d'une transaction commerciale dans laquelle un utilisateur commande directement un contenu numérique ou indirectement un bien par l'intermédiaire du réseau Internet en utilisant une carte bancaire. II est le plus souvent conduit à échanger avec le fournisseur du bien des données personnelles qui doivent recevoir un traitement de protection comme un chiffrement ou cryptage, pour être inutilisables par des tiers non autorisés. Pour parvenir à cette protection, il est déjà défini dans l'état io de la technique un protocole de transaction sécurisée de type "HTTPs" qui utilise des couches de sécurité associées au protocole Internet classique. Dans de telles transactions, l'utilisateur doit, et ce à chaque transaction, saisir à nouveau les données confidentielles de la transaction sécurisée comme le code de sa carte bancaire. Or, particulièrement sur certains terminaux de consultation, comme les téléphones mobiles, de telles saisies sont peu pratiques. Pour remédier à cet inconvénient, il est déjà connu par certains fournisseurs de contenus d'installer des fichiers définis dans les normes de téléinformatique comme les "cookies" du protocole Internet sur le terminal de l'utilisateur et qui contiennent des copies des données confidentielles transmises par l'utilisateur. Mais cette solution présente plusieurs inconvénients. Tout d'abord, le traitement de protection est effectué par le fournisseur de contenus sans aucun contrôle possible de la part de l'utilisateur et ce, sans garantie de sécurité des données. Ensuite, l'enregistrement des données confidentielles est fait à l'insu de l'utilisateur qui détient alors un fichier dont il ignore le contenu avec tous les risques qu'une telle ignorance fait courir à ces données. Enfin, ce fichier n'est pas exploitable par un autre fournisseur de contenus et doit donc être reconstitué par ce dernier pour son propre compte, ce qui ajoute une saisie sous la responsabilité de l'utilisateur et 2862170 3 l'existence d'un nouveau fichier ("cookie") dont ce dernier ignore généralement l'existence. Pour dégager la responsabilité des fournisseurs de contenus, il a été proposé d'utiliser un "tiers de confiance" à qui l'utilisateur transmet une fois pour toutes ses données confidentielles. Lors d'une communication confidentielle avec un utilisateur, le fournisseur de contenus s'adresse au tiers de confiance pour obtenir de manière sécurisée les données confidentielles de l'utilisateur. L'échange avec le tiers de confiance se fait avec un io moyen de protection des données qui n'est pas à la discrétion du fournisseur de contenus. Mais, pour réaliser le lien entre l'utilisateur et le fournisseur requérant, le tiers de confiance a besoin de déposer des fichiers de type cookies sur le terminal de l'utilisateur et encore faut-il que ce dernier se soit inscrit auprès du tiers de confiance. Enfin, le tiers de confiance se trouve aussi en possession d'un nombre important de données confidentielles, ce qui l'expose aux convoitises des pirates qui peuvent suivre les transactions sécurisées en accédant aux fichiers cookies signés du tiers de confiance au moins sur les machines des utilisateurs. Dans un autre état de la technique, il est connu que le tiers de confiance fournisse à chaque utilisateur qui en fait la demande, un logiciel qui permet de mémoriser les données confidentielles de l'utilisateur nécessaires à l'exécution de transactions avec des fournisseurs de contenus abonnés pour lesquels l'utilisateur a marqué son intention de pouvoir y accéder et de mener des transactions du genre débit de carte bancaire. Cependant, cette solution est, par exemple dans le cas du logiciel Gator TM gratuite pour l'utilisateur et rémunérée par son acceptation de bandeaux publicitaires et autres éléments de promotion vendus par Gator . Par ailleurs, de tels logiciels ne sont pas compatibles avec des logiciels de navigation Internet sur téléphones mobiles. De plus, un logiciel doit être spécialement installé sur le terminal de l'utilisateur. Enfin, les opérations 2862170 4 d'enregistrement doivent se faire service par service, c'est-à-dire un nouveau service pour chaque nouveau fournisseur de contenus auquel un utilisateur souhaite se connecter. Dans un autre état de la technique, qui sera développé plus loin, on a déjà pensé utiliser la solution au problème de la protection des données confidentielles des utilisateurs du fournisseur d'accès au réseau téléinformatique. Cependant, ainsi qu'on le décrira plus en détail à l'aide de la figure 1, l'utilisateur doit encore correspondre avec un tiers fournisseur du logiciel pour io établir une partie de la transaction, notamment la partie bancaire de la transaction quand elle met en oeuvre un paiement par carte bancaire. La présente invention apporte un remède à ces inconvénients de l'état de la technique. Par ailleurs, dans de nombreuses occasions, les utilisateurs du réseau Internet, qui utilisent les services d'un fournisseur d'accès au Réseau Internet, échangent des données confidentielles. De telles données pourraient être interceptés par des personnes qui pourraient surprendre le secret que les parties attendent d'un échange de données. Ce sera le cas d'un fichier contenant des données professionnelles comme des secrets de fabrication. Pour remédier à cet inconvénient, il existe aujourd'hui des produits logiciels que chacune des parties installe sur son ordinateur. Puis, la partie émettrice exécute un chiffrement des données qui sont alors transmises à la partie destinatrice pour y être déchiffrées. Un tel chiffrement garantit la confidentialité des données et l'intégrité des données. Cependant un tel chiffrement de garantit pas l'authenticité des données chiffrées. La présente invention apporte remède à cet autre inconvénient de l'état de la technique. En effet, elle concerne un procédé qui consiste à échanger des données confidentielles entre au moins un utilisateur ayant reçu des attributs de connexion à un réseau détenu par un fournisseur 2862170 5 d'accès à un réseau téléinformatique comme le réseau Internet et un fournisseur de contenus, Le procédé de l'invention consiste: du côté de l'utilisateur émetteur: - à émettre une requête de service d'un contenu constituée selon un protocole prédéterminé comme le protocole HTTP à destination d'un fournisseur de contenus destinataire; puis, du côté du fournisseur d'accès à un réseau téléinformatique: - à intercepter la requête en fonction de l'adresse du fournisseur de contenus destinataire io - à exécuter un service de chiffrement de données confidentielles maintenues auprès du Fournisseur d'accès et relatives à l'utilisateur; - à insérer les données confidentielles chiffrées dans ladite requête; - à ré-acheminer la requête vers le fournisseur de contenus destinataire de la requête; puis, chez un fournisseur de contenus destinataire de la requête: - à recevoir ladite requête et; - à extraire les données chiffrées en relation avec l'adresse de 20 l'utilisateur émetteur. Selon un aspect de l'invention, dans une étape préparatoire chez un fournisseur d'accès à un réseau téléinformatique comme le réseau Internet, le procédé consiste à constituer un fichier de données confidentielles associées à un utilisateur en même temps que ses données de compte d'accès au réseau téléinformatique lors d'une procédure d'inscription. Selon un autre aspect de l'invention, dans une étape préparatoire chez un fournisseur d'accès à un réseau téléinformatique comme le réseau Internet, le procédé consiste à constituer un fichier de données d'habilitation d'au moins un fournisseur de contenus qui fournit des services nécessitant la communication de données confidentielles. Ces données confidentielles sont, par avance, enregistrées dans un fichier de 2862170 6 données confidentielles associé à un utilisateur requérant ces services. Lors d'une procédure d'habilitation, un fichier d'habilitation contenant des données relatives à l'identification du fournisseur de contenus habilité et le cas échéant de données de configuration pour préparer une transaction avec au moins un utilisateur inscrit est constitué auprès du Fournisseur d'accès. Selon un autre aspect de l'invention, dans une étape préparatoire chez un fournisseur d'accès à un réseau téléinformatique comme le réseau Internet, le procédé consiste lors io d'une transaction entre un utilisateur inscrit chez le fournisseur d'accès et un fournisseur de contenus offrant le service requis par le dit utilisateur et habilité lors de l'étape préparatoire, à générer un objet accessible sur le terminal de l'utilisateur selon une pluralité d'arguments de génération d'objet prédéterminés; puis à surveiller une action prédéterminée de l'utilisateur sur ledit objet accessible sur le terminal de l'utilisateur, de sorte que sans autre action, les données confidentielles du fichier associé au dit utilisateur et qui correspondent aux arguments de génération d'objet dudit objet accessible sur le terminal de l'utilisateur et/ou à des données de configuration de transaction dans le fichier d'habilitation du fournisseur de contenus, soient transmises au moyen d'un protocole de communication sécurisé du fichier d'inscription de l'utilisateur vers une adresse déterminée sur le réseau téléinformatique. Selon un autre aspect de l'invention, le procédé consiste à utiliser un service d'interception du flux représentatif d'une requête comme une requête HTTP construite au niveau d'un utilisateur à destination d'un fournisseur de contenus habilité pour que des données confidentielles soient chiffrées au niveau du fournisseur d'accès sur la base des informations de chiffrement détenues dans une base de données constituée chez le fournisseur d'accès et réacheminées sous une forme chiffrée vers le fournisseur de contenus habilité. 2862170 7 D'autres caractéristiques et avantages de la présente invention seront mieux compris à l'aide de la description et dessins annexés parmi lesquels: la figure 1 représente une procédure de transaction de données confidentielles selon un état de la technique; - la figure 2 est un ordinogramme représentant un mode particulier de réalisation du procédé de l'invention - la figure 3 est un schéma bloc d'un système mettant en oeuvre le procédé de l'invention; io les figures 4(a) et 4(b) sont des schémas de bases de données utilisées dans le procédé de l'invention; la figure 5 est un schéma bloc d'un système mettant en oeuvre un autre mode de réalisation du procédé de l'invention. À la figure 1, on a représenté un exemple de réalisation de l'état de la technique qui a déjà été détaillée dans le préambule de la présente demande. Le terminal utilisateur 1, qui peut être un ordinateur de bureau ou encore un téléphone mobile, est connecté au réseau téléinformatique par l'intermédiaire d'un fournisseur d'accès au réseau téléinformatique 2. Une telle connexion n'est possible que si l'utilisateur 1 est inscrit auprès du fournisseur d'accès 2. Lors de cette inscription, l'utilisateur indique un certain nombre de données confidentielles déterminées par le fournisseur d'accès 2. Un fournisseur de contenus 4 est connecté au réseau télé informatique 2. Lors de son inscription, le fournisseur de contenus 4 indique le type de données confidentielles que les utilisateurs qui se connectent à son site pourraient être conduits à échanger avec lui. Lors de cette inscription des fournisseurs de contenus, le fournisseur d'accès au réseau téléinformatique détermine les données confidentielles qu'il doit demander à ses utilisateurs lors de leur première inscription au réseau. Lorsque l'utilisateur 1 se connecte selon le chemin 5 au fournisseur de contenus 4, ce dernier lui présente, selon le chemin 2862170 8 10, des requêtes tendant à lui transmettre des données confidentielles détenues directement par le fournisseur d'accès 2. Une fois l'autorisation de transfert de données confidentielles accordées par l'utilisateur 1, le fournisseur de contenus 4 transmet une requête 6 à un tiers de facturation 3. Le tiers de facturation 3 transmet alors au fournisseur d'accès au réseau 2 une requête de transfert de données confidentielles associées à la fois à l'utilisateur 1 et à son destinataire 4. En retour, après avoir vérifié les habilitations, le fournisseur lo d'accès au réseau 2 consulte les bases de données et extrait les données confidentielles relatives à l'utilisateur 1. II transmet selon une procédure cryptée 8 les données confidentielles demandées au tiers de facturation 3 qui émet alors un traitement de facturation au bénéfice du fournisseur de contenu numérique 4 au titre de l'utilisateur et qui transmet un acquittement de la transaction au fournisseur de contenus au moyen d'une connexion 9 de retour. Une fois l'acquittement de retour reçu du tiers de facturation 3, le fournisseur de contenus 4 informe son utilisateur 1 de l'exécution de la transaction constituée par le transfert des données confidentielles demandées. Il transmet alors cette information et/ou les informations demandées par le biais des données confidentielles par exemple quand elles sont achetées par l'utilisateur selon le chemin 10 à travers le fournisseur d'accès 2. A la figure 2, on a représenté un ordinogramme d'un mode de 25 réalisation du procédé de l'invention. Après une étape SI de début, qui peut être initiée dès la détection d'un utilisateur et/ou d'un fournisseur de contenus, On entre dans une boucle BI au cours de laquelle, on exécute une étape S2 préparatoire. Dans un mode préféré de réalisation, selon le type de connexion, une étape S21 d'inscription d'un nouvel utilisateur est effectuée ou une étape S22 d'habilitation d'un nouveau fournisseur de contenus est effectuée. 2862170 9 Si l'utilisateur ou le fournisseur de contenus ne sont pas identifiés comme inscrit ou habilité, on entre dans une phase d'inscription ou d'habilitation. La phase d'inscription permet de constituer un fichier de données confidentielles associées à un utilisateur en même temps que ses données de compte d'accès au réseau téléinformatique lors d'une procédure d'inscription tenue par le fournisseur d'accès au réseau téléinformatique comme le réseau Internet. De même, la phase d'habilitation vise à constituer un fichier de données d'habilitation d'au moins un fournisseur de io contenus. Ce fournisseur de contenus détient par exemple un site Web et propose des services nécessitant la communication de données confidentielles d'un utilisateur. Préférentiellement, cet utilisateur est inscrit auprès du fournisseur d'accès au réseau Internet et les données confidentielles demandées par le fournisseur de contenus sont enregistrées dans le fichier de données confidentielles associées à cet utilisateur quand il requiert les services du fournisseur de contenus. Ces services peuvent être des services marchands, d'achat de documents multimédias par Internet, ou indirectement de produits ou de services par exemple vendus par un catalogue multimédia produit par le fournisseur de contenus. Mais, ces services peuvent aussi ne pas être des services marchands et par exemple consister en la transmission de données confidentielles produites par l'utilisateur pour que soit effectué un traitement spécial par le fournisseur de contenus. Dans un autre mode de réalisation du procédé de l'invention, les données confidentielles sont constituées par un fichier de données retourné par le fournisseur de contenus vers l'utilisateur. Particulièrement dans ce cas, les échanges de clés de procédures de chiffrement à deux clés sont exécutés lors de mises à jour des données personnelles des procédures d'inscription et/ou d'habilitation auprès du Fournisseur d'Accès Internet. Le fichier de données peut être directement associé dans une requête HTTP, par exemple sus une méthode dite POST Method ou encore sous 2862170 10 une forme d'une adresse URL ou d'une référence indirecte à un fichier de données à chiffrer. Lors d'une procédure d'habilitation d'un nouveau fournisseur de contenus, le fichier d'habilitation est construit à l'aide d'une application détenue par le fournisseur d'accès Internet sur la base de données relatives à l'identification du fournisseur de contenus habilité et, le cas échéant, de données de configuration pour préparer une transaction avec au moins un utilisateur inscrit. Ainsi, lorsqu'un nouvel utilisateur s'inscrit dans une procédure io d'inscription, ou lorsqu'un utilisateur déjà inscrit modifie son fichier d'inscription, le fournisseur d'accès dispose d'une application qui lui permet de demander les données confidentielles requises par le fichier d'habilitation de chaque fournisseur de contenus avec lequel l'utilisateur souhaite avoir un contact. Si l'un des partenaires, utilisateur ou fournisseur de contenus, n'est pas inscrit, le fournisseur d'accès dispose d'une application d'inscription ou d'une application d'habilitation pour le faire entrer dans le service de transfert de données confidentielles de l'invention. Si l'un ou l'autre des partenaires refuse, le service est interrompu (non représenté). Si les deux partenaires sont reconnus, respectivement comme utilisateur inscrit et comme fournisseur habilité, la phase préparatoire S2 est immédiatement terminée. On remarquera qu'on décrit ici une communication entre un seul utilisateur et un seul fournisseur de contenus. On comprendra que plus d'un utilisateur peuvent être connectés dans une phase préparatoire, ou une fédération de fournisseurs de contenus comme un portail Internet ou un anneau de fournisseurs de genre webring peuvent se trouver en relation avec un utilisateur inscrit. A l'issue de la phase préparatoire S2, on initie une seconde boucle B2 et, lors d'un test de fin de boucle T1 qui termine la 2862170 11 première boucle B1, on vérifie que les deux partenaires sont correctement reconnus ainsi qu'on l'a décrit ci-dessus. Le procédé de l'invention comporte alors une étape d'exploitation S3 qui démarre lors d'une transaction entre un utilisateur inscrit chez le fournisseur d'accès et un fournisseur de contenus offrant le service requis par le dit utilisateur et habilité lors de l'étape préparatoire. La seconde boucle initiée en B2 est terminée par un test de fin de boucle T2 qui met fin au service de transfert de données io confidentielles selon l'invention, lors d'une étape S4 de fin. Il est entendu que chaque boucle B1 ou B2 peut être initiée par la détection d'une requête d'ouverture de phase préparatoire (inscription ou habilitation) ou d'une requête d'exploitation (détection d'une requête de transaction demandant le transfert de is données confidentielles) de manière asynchrone. II est entendu que le processus de la figure 2 peut être exécuté en plusieurs réplications fonctionnant en parallèle avec un système de communications multi canal. L'invention s'applique donc à des transactions de types variés. Particulièrement, une transaction selon l'invention s'établit entre un utilisateur et un site de transfert du genre web, mais aussi d'autres genres, comme WAP. Une telle transaction comporte toujours au moins un chiffrement de données confidentielles exécuté en coeur de réseau, et donc un chiffrement qui n'est pas soumis ni à l'utilisateur, ni au site de transfert, ni à un tiers autre que le fournisseur d'accès au réseau téléinformatique, et un transfert des données confidentielles chiffrées. Une telle transaction peut porter directement sur le contenu numérique présenté par le fournisseur de contenus ou sur d'autres contenus non numériques ou des produits ou des services non informatiques comme ceux d'un service de Vente par Correspondance ou assimilé. Elle peut être marchande ou non, mettre en oeuvre une transaction de type financier ou bancaire. 2862170 12 Dans l'application de l'invention au paiement de biens sur Internet, les données confidentielles comme un code PIN de carte bancaire sont fournies en clair par l'utilisateur, client du service de vente, et chiffrées en coeur de réseau selon le procédé de l'invention à chaque transaction. Cependant, pour simplifier l'intervention de l'utilisateur, on préférera stocker ces données et les retrouver de façon automatique ainsi qu'il sera décrit ci-après. A la figure 3, on a représenté un schéma bloc d'un système mettant en oeuvre le procédé de l'invention. Ainsi qu'on l'a déjà io exposé, le procédé de l'invention met en présence un fournisseur 40 d'accès à un réseau comme le réseau Internet, au moins un fournisseur 39 de contenus et au moins un utilisateur 38 dudit fournisseur 39 de contenus Chez le fournisseur d'Accès Internet 40 se trouvent: - Une Base de données 20 d'inscription d'utilisateur dans laquelle est maintenue chaque compte d'utilisateur inscrit auprès du Fournisseur d'Accès Internet 40; - Une Base de données 21 d'habilitation de fournisseurs de contenus dans laquelle est maintenu chaque compte d'habilitation pour les fournisseurs de contenus habilités par le Fournisseur d'Accès Internet 40. Le Fournisseur d'Accès Internet dispose d'une ou plusieurs ressources suivantes qui sont: - une ressource 23 d'inscription ou de modification de compte d'utilisateur auprès de la base de données 20 d'inscription d'utilisateur; - une ressource 24 d'habilitation ou de modification de compte d'habilitation auprès de la base de données 21 d'habilitations une ressource de chiffrement C; - une ressource D de détournement de requête HTTP qui permet dans un canal HTTP 33 de prélever une requête 31, 32 formulée sur le navigateur Internet de l'utilisateur pour la présenter 2862170 13 à la ressource de chiffrement chez le Fournisseur d'Accès Internet 40; - une ressource R de ré acheminement de la requête HTTP dans laquelle une partie 32 de données X en clair ou de référence est disponible pour permettre le chiffrement exécuté par la ressource C en fonction de données de chiffrement contenues dans la base de données 20 de comptes d'utilisateur et/ou dans la base de données 21 de comptes d'habilitation. Au niveau du navigateur installé chez l'utilisateur 38, la requête io HTTP est composée de manière classique avec un mécanisme de production de données dans la requête HTTP 31. Des données confidentielles peuvent être insérées ainsi qu'il sera décrit plus loin, à la volée par le Fournisseur d'accès Internet sans autre intervention de l'utilisateur inscrit. Au niveau de l'application Serveur installée chez le Fournisseur de Contenus 39 la partie chiffrée de données 35 dans la requête 34 telle que ré acheminée par la ressource de Ré acheminement R et la partie X Chiffrée 35 peut alors être déchiffrée par une ressource locale de déchiffrement et exploitée par une ressource locale d'utilisation des données X, notamment pour produire une réponse HTTP (non représentée) sur le canal HTTP 33. A la figure 4(a), on a représenté la structure d'un fichier d'inscription 41 qui comporte: des données d'inscription 42 nécessaires à l'ouverture d'un 25 compte de connexion au fournisseur d'accès Internet et bien connues par ailleurs; des données confidentielles 43 qui peuvent être définies par l'utilisateur lui-même en fonction des différents fournisseurs de contenus auxquels il compte souscrire et d'après le type de données personnelles requises par chacun des fournisseurs de contenus habilités. 2862170 14 A la figure 4(b), on a représenté la structure d'un fichier d'habilitation 45 d'un fournisseur de contenus habilité par le fournisseur d'accès Internet et qui comporte: - des données d'identification 46 du fournisseur de contenus habilité ; - des données de génération d'objet 47 qui contiennent les arguments de génération d'objet permettant à l'application 25 (Figure 3) de générer l'objet accessible par l'utilisateur selon ce qui a déjà été décrit; io - des données définissant l'adresse du site destinataire des données confidentielles du fichier d'inscription adressé lorsque l'utilisateur aura exécuté l'action attendue sur le dot objet accessible par l'utilisateur. D'autres données peuvent être ajoutées aux deux structures des figures 4(a) et 4(b) sans sortir de la portée de la présente invention. A la figure 5, on a représenté un système de communication Internet dans un mode particulier de réalisation du procédé de l'invention dans lequel on va préciser notamment les moyens de contrôle du fournisseur d'accès Internet FAI sur une transaction entre un fournisseur de contenus et un utilisateur au cours de laquelle des données confidentielles doivent être transmises. Le système de communication met en oeuvre trois parties: l'utilisateur, client du fournisseur d'accès Internet, le fournisseur d'accès Internet FAI et au moins un site de fournisseur de contenus. Les divers moyens nécessaires sont respectivement: Du côté de l'utilisateur: un terminal 50 doté d'une connexion téléinformatique au fournisseur d'accès FAI, d'un moyen pour produire et recevoir des requêtes de type HTTP, comme un navigateur et de moyens pour traiter des contenus numériques provenant de fournisseurs de contenus via le réseau du fournisseur d'accès Internet; 2862170 15 Du côté des fournisseurs de contenus: des ressources 52 pour produire des contenus numériques, des ressources pour produire et recevoir des requêtes HTTP avec des utilisateurs connectés au réseau Internet par le fournisseur d'accès Internet FAI; Du côté du fournisseur d'accès Internet FAI: un serveur Web 53 pour exécuter l'étape préparatoire d'inscription d'utilisateurs et d'habilitation de fournisseurs de contenus, un dispositif proxy-cache implémentant un client iCAP 51, unserveur lo iCAP implémentant un service iCAP 55, une base de données 54 des utilisateurs du FAI ayant souscrit au service de transfert sécurisé de données confidentielles de l'invention, une base de données 56 des données d'habilitation des fournisseurs de contenus, partenaires du fournisseur d'accès Internet FAI et qui demandent à bénéficier des données confidentielles des utilisateurs inscrits dans la base de données 55. Notamment pour les techniques des proxy-caches et du protocole iCAP implémentées au niveau du fournisseur d'accès Internet FAI on pourra se reporter au contenu de la demande de brevet FR 2 823 044 du 30 mars 2001 au nom de France Telecom. Le moyen pour produire et recevoir des requêtes de type HTTP, comme un navigateur est dans d'autres versions capable de produire et recevoir des requêtes sur ledit réseau de divers types autre que le protocole HTTP. Particulièrement, l'invention est applicable au protocole WAP (Wireless Application Protocol) pour que les Terminaux Mobiles puissent accéder à Internet et leur permettre de consulter les courriers électroniques et divers sites ou services Web. L'invention est aussi applicable au protocole FTP qui permet à un utilisateur d'accéder à un serveur de fichiers, au protocole SMTP de transfert de courrier électronique, au protocole RTCP (Real Time Transfer Protocol). Ce dernier protocole est basé sur des transmissions périodiques de paquets de contrôle par tous les participants dans une session en contrôle des flux d'un autre 2862170 16 protocole dit protocole RTP, permettant de véhiculer des informations de base sur les participants d'une session, et sur la qualité de service notamment lors de communications entre plusieurs utilisateurs et/ou fournisseurs de contenus, ces derniers acteurs étant considérés selon le point de vue de la présente invention. On va maintenant décrire les flux de données échangés dans le système de la figure 5 sur la base du procédé de l'invention. Lors de la phase préparatoire, l'utilisateur 50 renseigne les données io confidentielles sur un serveur Web 53 par une connexion sécurisée de type HTTPs ou non sécurisée. Cette connexion peut avoir lieu lors de la première connexion au Fournisseur FAI pour l'inscription de l'utilisateur, ou ultérieurement lors d'une procédure de mise à jour. Les données confidentielles sont alors hébergées par une écriture 62, ou une mise à jour le cas échéant, au niveau de la base de données 54 des utilisateurs du fournisseur FAI. La même procédure (non représentée) est suivie pour les données d'habilitation de la base de données 56 des fournisseurs de contenus partenaires du fournisseur d'accès Internet FAI. Parmi les données d'habilitation, on trouve cependant une clef publique de chiffrement à mettre en oeuvre par le fournisseur FAI dans une procédure de chiffrement à clés publiques lorsqu'il transmettra les données confidentielles requises d'un utilisateur, le fournisseur de contenus habilité et partenaire du fournisseur FAI maintenant secrète la clé privée permettant le déchiffrement. Lors de l'étape d'exploitation, le fournisseur de contenus au site Web duquel l'utilisateur s'est connecté à travers le proxy-cache du fournisseur FAI a transmis une page Web dans laquelle se trouve une proposition de transaction avec transmission de données confidentielles détenues par le fournisseur FAI pour le compte de l'utilisateur. Par activation de la proposition, l'utilisateur transfère alors sur le réseau une requête 63 pour effectuer une transaction comme une commande en ligne. Le proxy-cache 51, installé chez le 2862170 17 fournisseur FAI, comporte un moyen pour intercepter les requêtes d'achat en ligne ou toute autre requête HTTP issue du navigateur d'un utilisateur inscrit auprès du Fournisseur d'accès Internet. L'interception 64 a lieu au moyen de l'analyse de listes, dites ACLs , qui font partie des fonctionnalités de gestion de flux d'un proxy-cache. Ayant détecté dans les ACLs la présence d'une requête d'achat en ligne, le proxy-cache route cette requête vers un serveur implémentant une interface supportant un protocole de transfert de flux HTTP tel qu'un serveur iCAP implémentant le io service iCAP de transfert de données confidentielles défini dans le procédé de l'invention. La requête parvenant au serveur iCAP 55 est de la forme suivante commentée dans le Tableau 1: Tableau 1: ll En-tête de requête définie selon iCAP REQMOD icap://xxx.xxx.xx. xxxxx/wwreqmod ?Profile=Filtl ICAP/1.0 Hast: xxx.xxx.xxx.xxx Encapsulated:req-hdr=0, null-body=394 X-Client-I P:yyy.yyy.yyy.yyy //En-tête de requête définie selon HTTP GET HTTP://www.site. domaine/?HTTP/1.1 Host:www.site.domaine Accept:image/gif, .... Referer: HTTP://www.site.domaine/ Accept-Language: xx //code langue Accept-Encoding:gzip, deflate User-Agent: Mozilla/4.0(compatible; liste) X-Forwarded-For: yyy.yyy.yyy.yyy dans laquelle requête: - xxx.xxx.xxx.xxx est l'adresse Internet IP du service iCAP 55; - yyy.yyy.yyy.yyy est l'adresse Internet url de l'utilisateur détecté et HTTP://www.site.domaine/ est l'adresse du site Web détecté du fournisseur de contenus; 20 25 2862170 18 les autres champs de la requête de la forme du tableau 1 permettent de déterminer les ressources disponibles pour la génération de l'objet accessible par l'utilisateur. Le serveur iCAP 55 qui reçoit la requête du tableau 1 implémente un service iCAP mettant en oeuvre la partie de traitement de l'étape d'exploitation du procédé de l'invention selon les enseignements présentés notamment dans la demande de brevet français FR 2 823 044 déposée au nom de France Telecom à laquelle on se reportera pour les détails de réalisation. io Le service iCAP exécute alors une étape 66 pour établir la correspondance entre l'adresse IP Internet du champ X-Client-IP allouée à l'utilisateur pour la session en cours et qui se trouve dans l'en-tête de requête HTTP et un identifiant de l'utilisateur contenu dans sa base de données des utilisateurs inscrits 54. Le service iCAP exécute ensuite une étape pour vérifier l'accord de l'utilisateur pour la transmission de ses données confidentielles au site partenaire lors d'une étape 67. Si cet accord est détecté par analyse des données inscrites en relation avec l'utilisateur connecté dans la base de données 54, le serveur iCAP 55 exporte 68 ces données confidentielles nécessaires pour l'achat en ligne de la base de données des utilisateurs 54 vers le serveur iCAP 55. Le service iCAP exécute ensuite une étape d'interrogation de la base de données des fournisseurs habilités (partenaires) 56 pour connaître la clé publique du fournisseur déclaré et, le cas échéant si cette donnée est manquante, pour déterminer l'adresse du site de destination des données confidentielles, ici définie dans la requête dans le champ adresse IP destination des données confidentielles (champ Host Tableau 1) dans le flux 69. Les étapes d'échange des flux 68 et 69 peuvent être réalisées simultanément pour accélérer le service. Dans un autre mode de réalisation, l'étape d'échange du flux 69 est exécutée d'abord puis seulement après celles des flux 66 et 20 25 30 67. En effet, dans le cas où un partenaire aurait besoin d'informations sur l'utilisateur qui soit différentes de celles des autres partenaires, on peut avoir besoin de consulter la base d'habilitation en premier pour savoir quels paramètres chercher dans la base des utilisateurs. Le serveur iCAP 55 exécute alors une étape de chiffrement avec la clé publique adéquate provenant du flux 70 et les insère dans un champ particulier, qui pourrait être normalisé et qui est intitulé EncryptedData , interne à la requête HTTP qui renvoie la io bonne clé publique. Le serveur iCAP 55 exécute ensuite une étape de retransmission de la requête modifiée dans le flux 72 vers le proxycache 51. La requête modifiée devient alors selon le Tableau 2: Tableau 2: l/ En-tête de requête définie selon iCAP REQMOD icap://xxx.xxx.xx. xxxxx/wwregmod ?Profile=Filtl ICAP/1.0 Host: xxx.xxx.xx.xxxxx Encapsulated:req-hdr=0, null-body=394 X-Cl ient-I P:yy.yyy.yyy.yyy //En-tête de requête définie selon HTTP GET HTTP://www.site. domaine/?HTTP/1.1 Host:www.site.domaine Accept:imagelgif, .... Referer: HTTP://www.site.domaine/ Accept-Language: xx //code langue Accept-Encoding:gzip, deflate User-Agent: Mozilla/4.0(compatible; liste) X-Forwarded-For: yy.yyy.yyy.yyy VIA: 1.0 c-icache(NetCache NetApp/5.2.1 R1 D9) Encrypted-Data: zzzzzzzzzzzzzzzz dans laquelle requête on a ajouté les deux dernières lignes à la Requête initiale qui sont: 2862170 20 - la ligne VIA définissant la ressource iCAP du proxy-cache chargée de la transmission de la requête modifiée vers le site du fournisseur habilité partenaire destinataire des données encodées; la ligne Encrypted-Data contenant le flot de données encryptées. Le proxy-cache exécute alors une étape de transmission 73 vers le site de l'hébergeur concerné par l'achat en ligne. Le chiffrement des données utilisateurs se fait sur le serveur ICAP 55 io et l'insertion de ces données chiffrées est réalisée dans un champ de la requête reçue dans le flux 65 par le serveur ICAP et retransmise par le flux 72. Le fournisseur de contenus 62 hébergeant le site d'achat en ligne extrait de l'en-tête HTTP (ligne Encrypted-Data ) lors d'une étape 74 qu'il décrypte à l'aide de sa propre clé privée et traite l'achat en ligne de l'utilisateur, son propre client. Le fournisseur de contenus 62 exécute alors: - si les données confidentielles transmises sont des données bancaires (carte bleue, numéro de compte de prélèvement), 20 une étape de facturation de l'utilisateur est effectuée par le fournisseur de contenus; - si les données confidentielles transmises sont des données d'identification d'un client du fournisseur de contenus, une étape de facturation du client est effectuée et transmise avec cet identifiant au fournisseur d'accès FAI qui peut alors exécuter la refacturation de son propre client utilisateur 50. Une étape 76 de réponse contenant la confirmation de la transaction au proxy-cache 51 est alors effectuée. Puis, le proxy-cache 51 exécute une étape d'acheminement 77 de la confirmation de transaction vers l'utilisateur 50. On remarque ainsi les avantages essentiels de l'invention. Tout d'abord, les opérations d'identification lors des procédures d'achat sont transparentes pour l'utilisateur, client du fournisseur de 2862170 21 contenus. Ensuite, le fournisseur d'accès Internet FAI peut offrir un service de masquage de l'identité de ses utilisateurs en leur attribuant un identifiant unique et chiffré rattachable à ce seul client. Il en résulte dans ce cas: 1. L'identité réelle du client est masquée au fournisseur de contenus ce qui préserve l'anonymat du client lors d'achat; une telle caractéristique permet notamment de réduire la diffusion involontaire du nom des utilisateurs dans des fichiers commerciaux qui en retour produisent des envois de io sollicitations commerciales non désirées (spamming notamment) ; 2. Les coordonnées bancaires de l'utilisateur inscrit ne transitent plus sur le réseau ce qui renforce la sécurité des données confidentielles; 3. Le fournisseur d'accès Internet FAI sert alors de tiers de facturation et peut mettre en place un modèle économique de rémunération sur les échanges commerciaux. Enfin, l'invention apporte l'assurance à tout fournisseur de contenus habilité par le fournisseur d'accès Internet FAI de la véracité de l'identité de son utilisateur puisque ce dernier est authentifié par son accès. 22 REVENDICATIONS 1 Procédé de transfert de données confidentielles entre au moins un utilisateur (1) ayant reçu des attributs de connexion à un réseau détenu par un fournisseur d'accès à un réseau téléinformatique comme le réseau Internet (2) et un fournisseur de contenus, caractérisé en ce qu'il consiste: du côté de l'utilisateur émetteur de données confidentielles: à émettre une requête de service d'un contenu constituée io selon un protocole prédéterminé comme le protocole HTTP à destination d'un fournisseur de contenus destinataire; puis, du côté du fournisseur d'accès à un réseau téléinformatique (2) : à intercepter la requête en fonction de l'adresse du 15 fournisseur de contenus destinataire (4) ; - à exécuter un service de chiffrement de données confidentielles maintenues auprès du fournisseur d'accès et relativesà l'utilisateur; - à insérer les données confidentielles chiffrées dans ladite 20 requête; - à ré-acheminer la requête vers le fournisseur de contenus destinataire de la requête puis, chez un fournisseur de contenus destinataire (4) de la requête: - à recevoir ladite requête et; - à extraire les données chiffrées en relation avec l'adresse de l'utilisateur émetteur. 2 Procédé selon la revendication 1, caractérisé en ce qu'il comporte aussi une étape préparatoire (B1, S2), chez au moins un fournisseur d'accès à un réseau téléinformatique comme le réseau Internet (2) : - à constituer un fichier (20) de données confidentielles associées à un utilisateur en même temps que ses données de 2862170 23 compte d'accès au réseau téléinformatique lors d'une procédure d'inscription; à constituer un fichier (21) de données d'habilitation d'au moins un fournisseur de contenus proposant des services nécessitant la communication de données confidentielles enregistrées dans un fichier de données confidentielles associés à un utilisateur requérant ces services, lors d'une procédure d'habilitation, ledit fichier d'habilitation contenant des données relatives à l'identification du fournisseur de contenus habilité et le cas io échéant de données de configuration pour préparer une transaction avec au moins un utilisateur inscrit. 3 Procédé selon l'une des revendications précédentes caractérisé en ce qu'il est exécuté par divers moyens qui sont respectivement: - du côté de l'utilisateur: un terminal (50) doté d'une connexion téléinformatique au fournisseur d'accès (FAI), d'un moyen pour produire et recevoir des requêtes sur ledit réseau de type HTTP, WAP, FTP, SMTP, RTCP ou autres comme un navigateur et de moyens pour traiter des contenus numériques provenant de fournisseurs de contenus via le réseau du fournisseur d'accès Internet; du côté des fournisseurs de contenus: des ressources (52) pour produire des contenus numériques, des ressources pour produire et recevoir des requêtes de type HTTP, WAP, FTP, SMTP, RTCP ou autres avec des utilisateurs connectés au réseau Internet par le fournisseur d'accès au réseau comme le réseau Internet (FAI) ; du côté du fournisseur d'accès au réseau comme le réseau Internet (FAI) : un serveur Web (53) pour exécuter l'étape préparatoire d'inscription d'utilisateurs et d'habilitation de fournisseurs de contenus, un dispositif proxy-cache implémentant un client iCAP (51), un serveur iCAP implémentant un service iCAP (55), une base de données (54) 2862170 24 des utilisateurs du FAI ayant souscrit au service de transfert sécurisé de données confidentielles de l'invention, une base de données (56) des données d'habilitation des fournisseurs de contenus, partenaires du fournisseur d'accès Internet (FAI) et qui demandent à bénéficier des données confidentielles des utilisateurs inscrits dans la base de données (55). 4 Procédé selon la revendication 3, caractérisé en ce que, lors de la phase préparatoire, l'utilisateur (50) renseigne les données confidentielles sur un serveur Web (53) par une connexion io sécurisée comme une connexion de type HTTPs , notamment lors de la première connexion au Fournisseur d'accès FAI pour l'inscription de l'utilisateur, ou ultérieurement lors d'une procédure de mise à jour, les données confidentielles étant alors hébergées par une écriture (62), ou une mise à jour le cas échéant, au niveau de la base de données (53) des utilisateurs du fournisseur FAI, la même procédure étant suivie pour les données d'habilitation de la base de données (56) des fournisseurs de contenus partenaires du fournisseur d'accès Internet FAI. Procédé selon la revendication 4, caractérisé en ce que parmi les données d'habilitation, on trouve une clef publique de chiffrement à mettre en uvre par le fournisseur d'accès au réseau FAI dans une procédure de chiffrement à clés publiques lorsqu'il transmettra les données confidentielles requises d'un utilisateur, le fournisseur de contenus habilité et partenaire du fournisseur FAI maintenant secrète la clé privée permettant le déchiffrement. 6 Procédé selon la revendication 5, caractérisé en ce que par activation d'une proposition de transaction, l'utilisateur transfère alors sur le réseau une requête (63) pour effectuer une transaction comme une commande en ligne, le proxy-cache (51), installé chez le fournisseur FAI, comportant un moyen pour intercepter les requêtes d'achat en ligne au moyen de l'analyse de listes ACLs de filtrage sur expression régulière, de sorte que, ayant détecté dans les ACLs la présence d'une requête d'achat en ligne, le proxy-cache 2862170 25 route cette requête vers le serveur iCAP implémentant le service iCAP de transfert de données confidentielles, et en ce qu comporte aussi une étape d'insérer dans l'en-tête de la requête une ligne (X-Client-IP) identifiant l'accès de l'utilisateur et une ligne s (Host) identifiant l'accès du fournisseur de contenus. 7 Procédé selon la revendication 6, caractérisé en ce que le serveur iCAP (55) qui reçoit la requête (tableau 1) implémente un service iCAP qui exécute alors une étape (66) pour établir la correspondance entre l'adresse IP Internet du champ X-Client-IP io allouée à l'utilisateur pour la session en cours et qui se trouve dans l'en-tête de requête HTTP et un identifiant de l'utilisateur contenu dans sa base de données des utilisateurs inscrits 54. 8 Procédé selon la revendication 7, caractérisé en ce que le service iCAP exécute ensuite une étape pour vérifier l'accord de l'utilisateur pour la transmission de ses données confidentielles au site partenaire lors d'une étape (67), de sorte que si cet accord est détecté par analyse des données inscrites en relation avec l'utilisateur connecté dans la base de données (54), le serveur iCAP (55) exporte (68) ces données confidentielles nécessaires pour l'achat en ligne de la base de données des utilisateurs (54) vers le serveur iCAP (55). 9 - Procédé selon la revendication 8, caractérisé en ce que le service iCAP exécute ensuite une étape d'interrogation de la base de données des fournisseurs habilités (partenaires) (56) pour connaître la clé publique du fournisseur déclaré à partir de l'adresse du site de destination et pour déterminer l'adresse du site de destination des données confidentielles, ici définie dans la requête dans le champ adresse IP destination des données confidentiels (champ Host Tableau 1) dans le flux (69). 10 Procédé selon la revendication 9, caractérisé en ce que le serveur iCAP (55) exécute alors une étape de chiffrement avec la clé publique adéquate dans le flux (70) et les insère dans un champ 2862170 26 spécial de l'en-tête de la requête HTTP des données encodées dans le flux (71). 11 Procédé selon la revendication 10, caractérisé en ce que le serveur iCAP (55) exécute ensuite une étape de retransmission de la requête modifiée dans le flux (72) vers le proxy-cache (51), dans laquelle requête on a ajouté à la Requête initiale une ligne Encrypted-Data contenant le flot de données encryptées. 12 Procédé selon la revendication 11, caractérisé en ce io que le proxycache exécute alors une étape de transmission (73) vers le site de l'hébergeur concerné par l'achat en ligne et en ce que le service iCAP attend alors un avis de réception des données confidentielles chiffrées par le fournisseur de contenus hébergeant le site d'achat en ligne qu'il extrait de l'en-tête HTTP (ligne Encrypted-Data) lors d'une étape (74) qu'il décrypte à l'aide de sa propre clé privée et traite l'achat en ligne de l'utilisateur, son propre client. 13 Procédé selon la revendication 12, caractérisé en ce que le service iCAP exécute alors: si les données confidentielles transmises sont des données bancaires (carte bleue, numéro de compte de prélèvement), une étape de facturation de l'utilisateur est effectuée par le fournisseur de contenus; si les données confidentielles transmises sont des données d'identification d'un client du fournisseur de contenus, une étape de facturation du client est effectuée et transmise avec cet identifiant au fournisseur d'accès FAI qui peut alors exécuter la refacturation de son propre client utilisateur (50) et en ce qu'une étape (76) de réponse contenant la confirmation de 3o la transaction au proxy-cache (51) est alors effectuée, puis, le proxy- cache (51) exécute une étape d'acheminement (77) de la confirmation de transaction vers l'utilisateur (50). 2862170 27 14 Procédé selon l'une des revendications précédentes, caractérisé en ce qu'il comporte aussi une étape dans laquelle le fournisseur d'accès Internet FAI offre un service de masquage de l'identité de ses utilisateurs en leur attribuant un identifiant unique et chiffré rattachable à ce seul client. Procédé selon l'une des revendications précédentes, caractérisé en ce que le fournisseur d'accès Internet FAI fait fonction de tiers de facturation et met en place un modèle économique de rémunération sur les échanges commerciaux.