FR2858497A1 - Procede securise de fourniture de documents payants via un reseau de communication - Google Patents

Abstract

Le procédé sécurisé selon l'invention comprend une étape d'identification des interlocuteurs, une étape d'accord entre les interlocuteurs et une étape de livraison d'un document acheté (DOC) par un serveur fournisseur à une machine client. Conformément au procédé, dans le serveur fournisseur, un identifiant de transaction est associé au document à livrer et l'ensemble obtenu est découpé en une pluralité de tronçons (T1 à TM). Les tronçons sont signés avant d'être décomposés au moyen d'une transformée Mojette en une pluralité de projections (P). L'envoi des tronçons à la machine client est effectué progressivement au fur et à mesure que la machine client confirme par sa signature la réception des tronçons transmis. Une file standard (FS) et une file conditionnelle (FC) sont prévues pour ce mécanisme garantissant une non-répudiation incrémentale. D'autres mécanismes de sécurisation sont intégrés dans le procédé et permettent à celui-ci de garantir un très haut niveau de protection.Application au réseau de communication tel qu'internet.

Description

PROCEDE SECURISE DE FOURNITURE DE DOCUMENTS PAYANTS VIA

UN RESEAU DE COMMUNICATION

La présente invention concerne de manière générale les réseaux de 10 communication publics à grande échelle tels que 'l'nternet. Plus particulièrement, la présente invention concerne un procédé sécurisé de fourniture de documents payants via un réseau de comunication offrant un maximum de garanties de sécurité aux fournisseurs et aux clients.

Il est connu actuellement de nombreux sites web offrant un accès payant 15 à des documents. La carte bancaire est largement utilisée comme moyen de paiement dans de tels sites malgré les risques encourus très importants en cas de fraude. Afin de limiter les risques, des solutions de paiement faisant appel à des cartes prépayées à montant déterminé ont été développées ces dernières années et contribuent à sécuriser les transactions payantes sur le 20 réseau Internet. Toutefois, à la connaissance du présent demandeur, ces solutions de paiement connues présentent un certain nombre de failles dans la protection des différents acteurs intervenant lors d'une transaction. En effet, aucune des solutions n'apporte de réponse aux problèmes suivants: - le fournisseur n'envoie pas le document au client; - le fournisseur n'envoie pas le bon document au client; - le client voit son achat surfacturé; - le client de mauvaise foi prétexte la non-réception du document; - le client de mauvaise foi prétexte la réception d'un mauvais document; - le fournisseur n'est pas payé par l'organisme bancaire; - le versement effectué au fournisseur par l'organisme bancaire n'est pas à la hauteur de celui de l'achat; - le fournisseur de mauvaise foi prétexte le non versement pour le document fourni; - le fournisseur de mauvaise foi prétexte le versement d'un montant inférieur à celui prévu pour la transaction.

La présente invention a pour objectif de fournir un procédé sécurisé de fourniture de documents payants via un réseau de communication tel qu'lnternet qui est conçu de manière à apporter des solutions aux différents inconvénients de la technique antérieure mentionnés ci-dessus.

Le procédé sécurisé de fourniture de documents payants via un réseau 10 de communication tel qu'lnternet selon l'invention inclut une étape d'identification de plusieurs interlocuteurs intervenant dans le procédé et comprenant entre autres un serveur fournisseur et une machine client, une étape d'accord entre les interlocuteurs et une étape de livraison d'un document à la machine client par le serveur foumrnisseur, et est caractérisé en 15 ce que l'étape de livraison de document comporte les sous-étapes consistant, pour le serveur fournisseur, à: fl) ajouter un identifiant de transaction au document à livrer et former ainsi un ensemble de document et identifiant, f2) découper en une pluralité de M tronçons l'ensemble de document et 20 identifiant, f3) signer chacun des M tronçons et former ainsi une pluralité de M ensembles de tronçon et signature de fournisseur correspondants, f4) appliquer une transformée Mojette à chacun des M ensembles de tronçon et signature de fournisseur pour décomposer chacun de ceux-ci en 25 une pluralité de N projections correspondantes, sachant qu'un ensemble de tronçon et signature de fournisseur peut être reconstruit à l'aide d'une transformée Mojette inverse avec un nombre minimal de n projections, n < N, f5) envoyer à la machine client au moins n desdites projections correspondantes pour un seul ensemble de tronçon et signature de 3 0 fournisseur à envoyer à la machine client, f6) envoyer à la machine client n-1 des projections correspondantes pour chacun des M-1 ensembles de tronçon et signature de fournisseur restant à envoyer à la machine client; les sous-étapes consistant, pour la machine client, à: cl) reconstruire l'ensemble de tronçon et signature de fournisseur envoyé par le serveur fournisseur (3) par application de la transformée Mojette inverse au moins n projections correspondantes reçues, c2) vérifier la validité de la signature de fournisseur incluse dans l'ensemble de tronçon et signature de fournisseur reconstruit, et, si celle-ci est 10 valide, signer le tronçon reçu inclus dans ledit ensemble reconstruit pour former une signature de client, c3) envoyer au serveur fournisseur la signature de client; et la sous-étape consistant également, pour ledit serveur fournisseur, à: f7) vérifier la signature de client reçue, et, si celle-ci est valide, envoyer à z5 la machine client au moins une des N-n+ 1 projections restantes pour un ensemble de tronçon et signature de fournisseur suivant à envoyer à la machine client; les sous-étapes cl) à c3) et f7) étant répétées jusqu'à la reconstruction par la machine client des M ensembles de tronçon et signature de fournisseur 2 o afin de reconstituer le document et l'identifiant de transaction.

De préférence, la signature de client incluse dans la sous-étape porte sur tous les tronçons reçus et reconstruits du document.

Selon une autre caractéristique, des couples de clés asymétriques constitués chacun d'une clé privée et d'une clé publique sont employés par le 25 serveur fournisseur et la machine client pour signer et vérifier les signatures.

De préférence, la non-réception d'une signature valide par le serveur fournisseur ou par la machine client ou un autre desdits interlocuteurs met fin à la transaction.

Selon encore une autre caractéristique, lorsqu'une projection envoyée à 3 0 la machine client pendant la sous-étape f7) n'est pas acquittée par la machine client avant l'expiration d'un délai prédéterminé, le serveur fournisseur envoie au moins une nouvelle projection différente de celles déjà envoyées, et lorsqu'une projection envoyée à la machine client pendant une sous-étape différente de la sous-étape f7) n'est pas acquittée par la machine client avant l'expiration d'un autre délai prédéterminé, la projection est réémise.

De préférence, le procédé selon l'invention utilise un protocole de 5 communication avec des trames de longueur variable comprenant un champ d'en-tête et une pluralité de champs optionnels. De manière avantageuse, l'étape d'identification des interlocuteurs inclut l'envoi d'un ou plusieurs certificats émanant d'un serveur d'organisme certificateur et l'utilisation de couples de clés asymétriques constitués chacun d'une clé privée et d'une clé 10 publique, et peut inclure l'octroi par le serveur fournisseur d'une autorisation d'accès de durée prédéterminée à un client identifié pour un accès aux documents.

Selon une caractéristique particulièrement avantageuse, l'étape d'accord entre les interlocuteurs inclut une opération de signature d'un descriptif s15 formant preuve qui identifie un document objet de la transaction ainsi que le prix du document.

De plus, afin de lutter contre d'éventuelles opérations de rejeu effectuées à des fins illicites, certains des interlocuteurs peuvent générer des informations aléatoires que la machine client doit reprendre dans des 2 o réponses envoyées aux interlocuteurs, et un numéro d'autorisation de transaction délivré par un serveur d'organisme financier compris parmi les interlocuteurs peut être intégré dans les données transmises à la machine client lors de la livraison par le serveur fournisseur du document acheté. De préférence également, une clé de session est utilisée entre le serveur 25 fournisseur et la machine client pour le chiffrement des données envoyées.

D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante de plusieurs modes de réalisation préférés du procédé sécurisé de fourniture de documents via un réseau de communication selon l'invention.

Cette description est faite en référence aux dessins qu'elle comporte, dans lesquels: la Fig.1 montre les principales étapes comprises dans le procédé sécurisé de fourniture de documents via un réseau de communication selon l'invention; la Fig.2 montre l'environnement matériel dans lequel est mis en oeuvre le procédé selon l'invention; la Fig.3 est un diagramme de séquence montrant un principe général des échanges entre différents interlocuteurs impliqués dans le procédé selon l'invention; la Fig.4 est un diagramme de séquence concernant un mécanisme 10 d'authentification du fournisseur à l'aide d'un certificat; la Fig.5 montre un diagramme de séquence relatif à la livraison au fournisseur d'une clé publique du client; la Fig.6 est un diagramme de séquence relatif à l'authentification du client à l'aide de sa signature; la Fig.7 montre l'authentification au moyen d'un bail d'un client identifié lors d'un accès antérieur; la Fig.8 est un diagramme de séquence montrant les échanges relatifs à un descriptif de document dans un mécanisme de non- répudiation de contenu implanté dans le procédé selon l'invention; la Fig. 9 est un diagramme de séquence d'un mécanisme de nonrépudiation "incrémentale" implanté dans le procédé selon l'invention; la Fig.10 montre un diagramme de séquence concernant l'utilisation d'une information aléatoire avec un système de question-réponse de type "challenge" pour contrecarrer un rejeu de paiement; la Fig.11 montre un diagramme de séquence concernant l'utilisation d'une information aléatoire avec un système de question-réponse de type "challenge" pour contrecarrer un rejeu de chargement; la Fig.12 montre un diagramme de séquence concernant l'utilisation d'un numéro d'autorisation de transaction pour contrecarrer un rejeu de preuve de 30 transaction; la Fig.13 montre un mécanisme de gestion de flux à deux files implanté dans le procédé selon l'invention pour la livraison du document; et la Fig.14 montre la structure d'une trame de longueur variable employée dans un protocole de communication implanté dans le procédé selon l'invention.

En référence à la Fig.1, le procédé sécurisé de fourniture de documents selon l'invention comprend trois grandes étapes S1, S2 et S3.

L'étape S1 est une étape d'identification des interlocuteurs. Quatre types d'interlocuteurs interviennent dans une transaction gérée conformément au procédé de l'invention, à savoir, un fournisseur, un client, un organisme certificateur, et un organisme bancaire. Ces interlocuteurs doivent être 1o parfaitement identifiés.

Le fournisseur commercialise des documents qui sont téléchargeables par un client moyennant une contre-partie financière. L'identité du fournisseur est garantie par l'organisme certificateur. Le client dispose d'un compte bancaire auprès de l'organisme bancaire qui paye au fournisseur le montant 15 de l'achat effectué par le client. L'organisme bancaire est également référencé auprès du même organisme certificateur ou d'un autre organisme certificateur.

Les différents interlocuteurs sont identifiés à l'aide de leur signature.

Dans la suite de la description, pour des raisons de simplification et de commodité, il est considéré que l'organisme certificateur et l'organisme 20 bancaire ne forment qu'une seule et même entité qui est appelée "autorité bancaire certificatrice".

L'étape S2 est une étape d'accord entre les interlocuteurs sur un document acheté et son prix. Le client est d'accord pour acheter un document identifié pour un prix déterminé. L'autorité bancaire certificatrice est d'accord 25 pour payer le prix du document. Le fournisseur est d'accord pour livrer le document en contre-partie du prix payé. Cet accord est scellé par une signature de chacun des interlocuteurs.

L'étape S3 concerne la livraison par le fournisseur à son client du document que celui-ci a acheté. Cette étape S3 concerne uniquement le 30 fournisseur et le client. Conformément au procédé de l'invention, et comme cela apparaîtra plus clairement dans la suite de la description, la livraison du document n'est pas faite sous la forme d'un bloc unique livré d'un seul tenant, mais progressivement, en respectant différentes sous-étapes afin de constituer des preuves. En effet, il est souhaitable que le client soit en mesure de prouver que le fournisseur a envoyé un document, et le fournisseur que le client a effectivement reçu le document envoyé.

Comme montré également à la Fig.l, une étape S4 de constitution de preuves est également incluse dans le procédé de l'invention. Cette étape S4 est en fait présente dans chacune des étapes S1 à S3, car la constitution des preuves intervient tout au long du processus de la transaction.

En référence maintenant à la Fig.2, le procédé selon l'invention est mis 10 en oeuvre à travers un réseau 1 tel que l'lnternet. Les trois interlocuteurs principaux impliqués dans le procédé selon l'invention, à savoir, le client CL, le fournisseur FO et l'autorité bancaire certificatrice ABC, sont équipés respectivement d'une machine client 2, d'un serveur fournisseur 3 et d'un serveur d'autorité bancaire certificatrice 4.

La machine client 2 est munie notamment d'un navigateur 20, d'un programme mandataire client ou proxy client 21 et d'un gestionnaire de sécurité 22. Le serveur fournisseur 3 inclut un serveur web 30, un programme mandataire client ou proxy 31 et un gestionnaire de sécurité 32 qui sont, par exemple, hébergés dans une même machine. Le serveur d'autorité bancaire 20 certificatrice 4 héberge des moyens de gestion de sécurité incluant un gestionnaire de comptes 40 et un gestionnaire de certificats 41.

Différents acteurs sont impliqués dans le procédé selon l'invention et en modifient le processus. Par la terme "acteur", on se réfère dans la présente description à toutes personnes et tous programmes intervenant dans le 25 processus pour en modifier le cours normal.

Les personnes plus particulièrement impliquées sont les suivantes: l'administrateur sécurité de l'autorité bancaire certificatrice ABC, l'administrateur sécurité du fournisseur FO, le webmaster du fournisseur FO et le client CL. Les programmes prévus pour traiter l'information de manière à la 30 sécuriser comprennent notamment le proxy client 21 et le proxy fournisseur 31.

L'administrateur sécurité de l'autorité bancaire certificatrice ABC remplit de nombreuses tâches, à savoir: une gestion des comptes d'utilisateur avec notamment une création des comptes et des mots de passe correspondants; une génération d'une liste de comptes à offrir sur le marché; un déverrouillage 5 des comptes vendus; une gestion d'une clé privée Apr de l'autorité bancaire certificatrice ABC qui se limite à la création de celle-ci; une gestion générale de certificats avec notamment une génération de certificat pour l'autorité bancaire certificatrice ABC, une génération de certificats pour les fournisseurs FO, un envoi des certificats aux fournisseurs FO, et une gestion d'une liste de 10 révocation de certificats.

L'administrateur sécurité du fournisseur FO assure également des fonctions multiples qui sont les suivantes: une gestion d'une clé privée Fpr du fournisseur FO avec notamment une génération de la clé et une mise à disposition de celle-ci; une gestion de certificats comportant une génération 15 d'une demande de certificat auprès de l'autorité bancaire certificatrice ABC, une réception d'un certificat délivré par l'autorité bancaire certificatrice ABC, une demande de révocation du certificat auprès de l'autorité bancaire certificatrice ABC et une mise à disposition du certificat pour les clients CL.

Le webmaster du fournisseur FO n'intervient pas au premier plan de la 20 sécurisation du système. Cependant, il doit surveiller avec soin son développement afin d'éviter des trous de sécurité à travers les dispositifs pare-feu et autres. Sa tâche principale consiste à mettre à jour des pages d'accueil, ainsi que le contenu des documents auxquels sont associés des descriptifs, comme cela apparaîtra plus clairement par la suite.

2 5 Le rôle du client CL se limite à une demande de page au fournisseur FO.

Le proxy client 21 a pour mission de traiter la demande du client CL, autrement dit, du navigateur 20 et de dialoguer avec son homologue, le proxy fournisseur 31, tout en mettant en place des mécanismes de sécurisation.

Bien entendu, le proxy client 21 est également prévu de manière à pouvoir 3 0 communiquer directement avec des serveurs web classiques dans lesquels le procédé selon l'invention n'est pas implanté.

Le rôle du proxy fournisseur 31 est plus limité que celui de son homologue, le proxy client 21. Le proxy fournisseur 31 dialogue avec le proxy client 21 et le serveur web 30 du fournisseur FO, et il traite également l'information qui passe par lui.

La Fig.3 montre, sous la forme d'un diagramme de séquence, un principe général des échanges entre le navigateur client 20, le proxy client 21, le proxy fournisseur 31, le site web fournisseur 30 et le gestionnaire de comptes 40 de l'autorité bancaire certificatrice ABC, pour les demandes du client CL soumises à un traitement de sécurisation de l'autorité bancaire 10 certificatrice ABC. Des échanges plus détaillés et relatifs à des traitements effectués par les différents composants sont décrits par la suite.

Comme montré à la Fig.3, les échanges démarrent par une demande de page DP, Page = demander, du navigateur client 20 au site web fournisseur 30. Cette demande de page DP est transmise au site web fournisseur 30 à 15 travers le proxy client 21 et le proxy fournisseur 31. En réponse à la demande de page DP, le site web fournisseur 30 envoie au navigateur client 20 une requête de formulaire RF, Formulaire = rediriger, à travers les proxy 31 et 21.

Le navigateur 20 redirige cette requête RF, à travers le proxy client 21, vers le gestionnaire de comptes 40 sous la forme d'une demande de formulaire DF, 20 Formulaire = demander. Le gestionnaire de comptes 40 transmet en retour, Formulaire = envoyer, un formulaire FORM au navigateur 20, à travers le proxy client 21. Le formulaire FORM est rempli par le client CL et est transmis au proxy client 21, Formulaire rempli = envoyer, qui le fait suivre avec un numéro de compte NC et un mot de passe PAS du client CL, Compte + mot 25 de passe = envoyer, jusqu'au gestionnaire de comptes 40. Le gestionnaire de comptes 40 valide le compte NC et son mot de passe PAS, Compte et mot de passe = valider, et calcule un numéro d'autorisation de transaction NA qui est transmis au navigateur 20, Numéro autorisation = envoyer, à travers le proxy client 21. Le numéro d'autorisation NA est ensuite envoyé par le navigateur 20 30 au site web fournisseur 30, à travers les programmes mandataires ou proxies 21 et 31, Numéro autorisation = envoyer, et le site web fournisseur 30 transmet le numéro d'autorisation NA au gestionnaire de comptes 40. Le gestionnaire de comptes 40 valide le numéro d'autorisation NA reçu, Numéro autorisation = valider, et le paiement correspondant à la page PP demandée par le client CL, Paiement = effectuer. Un accord AC pour la livraison de la page PP est transmis par le gestionnaire de comptes 40, Accord = envoyer, 5 au site web fournisseur 30. A la réception de cet accord AC, le site web fournisseur 30, envoie la page PP au navigateur 20, Page = envoyer, à travers les proxies 31 et 21.

En référence aux Figs.7 à 13, il est maintenant décrit en détail différents mécanismes de sécurisation des transferts employés dans le procédé selon 10 I'invention et implantés notamment dans les proxies 21 et 31. Plus particulièrement, des mécanismes d'authentification, d'intégrités de données, de non-répudiation, de non-rejeu, de confidentialité, de renforcement de chiffrement, de distribution des clés et de livraison de document sont explicités dans les paragraphes suivants.

Le mécanisme d'authentification intervient dans l'étape S1 montrée à la Fig.1 du procédé de l'invention. Le mécanisme d'authentification permet de s'assurer pendant les transactions que les interlocuteurs en présence sont bien ceux qu'ils prétendent être. Ainsi, le client CL, afin de recevoir des documents du fournisseur FO, doit prouver à ce dernier qu'il sera bien en 20 mesure de récupérer le paiement correspondant au document livré. Le fournisseur FO doit également prouver son identité au client CL afin que celuici accepte les messages en toute confiance. Le mécanisme d'authentification selon le procédé de l'invention repose sur un enregistrement auprès d'un organisme certificateur et sur l'implication d'un organisme financier, lesdits 25 organismes étant représentés dans ce mode de réalisation par l'autorité bancaire certificatrice ABC.

L'authentification du serveur fournisseur 3 permet aux clients CL d'être sûrs de s'adresser au bon serveur afin de ne pas recevoir des données de provenance non identifiée. Le fournisseur FO s'enregistre préalablement 30 auprès de l'autorité bancaire certificatrice ABC et prouve au client CL qu'il a bien à faire au bon serveur en lui remettant un certificat émanant de l'autorité bancaire certificatrice ABC lors d'une demande de page payante. A charge du client CL de s'assurer de la validité du certificat auprès de l'autorité bancaire certificatrice ABC.

Le diagramme de séquence pour l'authentification du serveur fournisseur 3 est montré à la Fig.4. Le proxy client 21 demande un certificat CER, 5 Certificat = demander, au site web fournisseur 30, à travers le proxy fournisseur 31. Le certificat CER est envoyé au proxy client 21 qui le transmet pour validation au gestionnaire de sécurité 41 de l'autorité bancaire certificatrice ABC. Le gestionnaire de sécurité 41 informe ensuite le proxy client 21 de la validité ou de la non-validité du certificat CER.

o10 L'authentification du client CL intéresse le fournisseur FO qui doit s'assurer que personne d'autre qu'un client solvable n'accédera aux données.

Cette authentification doit préserver l'anonymat du client CL. Plusieurs modes d'authentification du client peuvent être employés dans le procédé selon l'invention.

Conformément à un premier mode d'authentification du client, les données transmises au serveur fournisseur 3 par la machine client 2 sont signées au moyen d'une clé privée Cpr du client CL et la signature, SignatureC, du client CL est transmise conjointement avec les données. Le fournisseur FO dispose d'une clé publique Cpu du client CL correspondant à la clé privée 20 Cpr et qui permet au serveur fournisseur 3 de vérifier Signature-C. Afin d'éviter toute possibilité de fraude dont la victime serait le fournisseur FO, la clé publique Cpu doit être liée à la transaction et rattachée à un compte. La livraison de la clé publique Cpu au fournisseur FO à travers l'autorité bancaire certificatrice ABC est montrée à la Fig.5.

Comme montré à la Fig.4, des données "numéro de compte + login + clé publique Cpu" sont signées au niveau du proxy client 21 avec la clé privé Cpr du client CL et ces données accompagnées de Signature-C sont transmises au gestionnaire de sécurité 40 de l'autorité ABC. La signature, Signature-C, et le numéro de compte + login sont validés par le gestionnaire 40. Un numéro 3 0 d'autorisation NA et la clé publique Cpu sont signés avec une clé privé Apr de l'autorité bancaire certificatrice et le numéro NA et la signature, Signature-N, correspondante de l'autorité ABC sont transmis par le gestionnaire de sécurité au proxy client 21. Le proxy client 21 valide Signature-N et vérifie la clé Apr avant de rediriger les données "clé publique Cpu + Numéro NA + Signature- N" vers le proxy fournisseur 31.

L'authentification à proprement parlé du client CL auprès du fournisseur 5 FO se déroule de la manière montrée à la Fig.6. Des données signées avec la clé Cpr sont transmises par le proxy client 21 au proxy fournisseur 31. La signature, Signature-C, des données est ensuite validée au niveau du proxy fournisseur 31 à l'aide de la clé publique Cpu du client CL transmise de la manière indiquée ci-dessus en référence à la Fig.5. Le client CL est alors 10 identifié comme solvable, et le fournisseur FO, sur la base du numéro d'autorisation NA, autorise le client CL à accéder au document souhaité.

L'authentification telle que décrite ci-dessus génère de nombreux échanges qui s'ajoutent à ceux des transactions web habituelles. Pour réduire le volume des échanges et améliorer les performances, deux possibilités 15 peuvent être considérées et consistent en une authentification directe du fournisseur FO par le client CL et en une authentification directe du client CL par le fournisseur FO. Dans le procédé selon l'invention, afin de fiabiliser la sécurisation, une authentification directe du fournisseur FO par le client CL est exclue. Par contre, une authentification directe du client CL par le fournisseur 20 FO est possible et correspond à un second mode d'authentification du client qu'il est possible d'implanter dans le procédé selon l'invention.

Dans ce second mode d'authentification du client selon le procédé de l'invention, le fournisseur FO fait appel une première fois à l'autorité bancaire certificatrice ABC pour authentifier le client CL, et il délivre ensuite au client 25 CL authentifié une autorisation d'accès aux documents pour une durée déterminée. Cette autorisation d'accès aux documents de durée déterminée est appelée "BAIL". Comme montré à la Fig.7, à chaque fois que le client CL souhaite accéder à un document DOC déjà consulté, il fournit préalablement le BAIL. Si le BAIL est valide, le client CL accède directement aux documents, 30 si le BAIL est expiré, le client CL sera redirigé vers l'autorité bancaire certificatrice ABC pour obtenir un nouveau numéro d'autorisation NA. Sur présentation de ce nouveau numéro d'autorisation NA, le fournisseur FO délivrera un nouveau BAIL et ainsi de suite. Pour empêcher sa reproductibilité et empêcher un accès à des personnes non autorisées, le BAIL est accompagné d'une empreinte EMP calculée à partir de la valeur du BAIL et d'une clé. Le client CL présente donc son BAIL accompagné de l'empreinte 5 EMP. De préférence, le fournisseur FO enregistre le dernier BAIL valide à chaque fois et, en cas de vol de la clé, cette dernière peut être déclarée valide jusqu'à la date d'expiration du dernier BAIL validé par la clé volée.

Le mécanisme d'intégrité de données implanté dans le procédé selon l'invention a pour fonction de garantir un acheminement correct des données l0 et une protection de celles-ci contre le vol. Un calcul d'empreinte et un cryptage sont utilisés.

De manière connue, I'empreinte EMP est calculée à partir des données et permet de prouver à la réception, par un recalcul de l'empreinte EMP et une comparaison avec celle reçue, qu'un document n'a subi aucune modification is entre l'extrémité émettrice et l'extrémité destinataire.

De préférence, le cryptage repose sur un algorithme de hachage tel que l'algorithme MD5.

Conformément au procédé de l'invention, il est mis en oeuvre un mécanisme de non-répudiation aussi bien à l'envoi qu'à la réception. A l'envoi, 20 le fournisseur FO ne peut nier être à l'origine d'un document DOC envoyé.

Cette fonctionnalité autorise la défense du client CL qui reçoit par exemple une page différente de celle annoncée. A la réception, le client CL ne peut pas nier avoir reçu le document DOC du fournisseur FO.

Un mécanisme de non-répudiation élémentaire repose sur l'utilisation de 25 deux clés: la clé privée de l'émetteur qui lui permet de générer sa signature (l'émetteur ne peut alors pas nier être à l'origine du message), et la clé publique de l'émetteur utilisée par le destinataire pour vérifier que le message a bien été généré par le bon émetteur.

Conformément au procédé selon l'invention, la signature repose sur 30l'empreinte d'un document. En d'autres termes, c'est l'empreinte d'un document qui est signée et non pas le document lui-même.

Dans le procédé selon l'invention, le client CL et le fournisseur FO doivent pouvoir prouver la provenance du message reçu, et il est donc employé deux couples de clés asymétriques: la clé privée Fpr du fournisseur FO avec laquelle il génère la signature, Signature-F, de son message; la clé 5 publique Fpu du fournisseur FO avec laquelle le client CL vérifie que le message reçu provient bien du fournisseur FO; la clé privée Cpr du client CL avec laquelle il génère la signature, Signature-C, de son message; la clé publique Cpu du client CL avec laquelle le fournisseur FO vérifie que le message reçu provient bien du client CL.

o Relativement à l'autorité bancaire certificatrice ABC, il est employé un autre couple de clés asymétriques: la clé privée Apr de l'autorité bancaire certificatrice ABC qui sert à générer le certificat CER du fournisseur FO ainsi que celui de l'autorité bancaire certificatrice ABC, et la clé publique Apu de l'autorité bancaire certificatrice ABC qui est utilisée par le client CL pour 15 valider le certificat CER envoyé par le fournisseur FO, et donc la clé publique Fpu du fournisseur FO.

Conformément à un mode de réalisation plus perfectionné du mécanisme de non-répudiation implanté dans le procédé de l'invention, il est assuré une non-répudiation du contenu afin d'apporter ainsi une solution pour 20 une défense du client CL en cas de mauvaise livraison par le fournisseur FO.

En effet, avec ce mode de réalisation, le client CL est en mesure de prouver, le cas échéant, que la nature du document DOC reçu n'est pas celle à laquelle il s'attendait. A cette fin, il est fait appel à un descriptif DESF qui accompagne chaque document DOC. Le descriptif DESF indique par exemple 25 les informations suivantes: le prix, le sujet principal du document, les mots clés, la durée d'une vidéo, le nombre d'illustrations dans le document, le nombre de pages, etc.. Le descriptif DESF est envoyé conjointement avec le document DOC correspondant afin de constituer une preuve de contenu efficace.

Lorsqu'un document DOC sera envoyé, il est précédé de son descriptif DESF. La signature est apposée sur l'ensemble descriptif-document DESFDOC et rend toute dissociation impossible.

De plus, afin d'empêcher toute possibilité de fraude, tous les protagonistes sont impliqués dans le processus de la manière suivante: 1 Le fournisseur FO livre au client CL une page de connexions (patchs), des descriptifs DESF et des signatures Signatures-F générées pour 5 les descriptifs DESF. La preuve est ainsi apportée que les descriptifs DESF sont bien émis par le fournisseur FO.

2 - Le client CL, en choisissant une connexion (patch), envoie à l'autorité bancaire certificatrice ABC, le descriptif DESF et la signature, Signature-F, de celui-ci par le fournisseur FO, ainsi que son numéro de compte NC et le mot 10 de passe PAS correspondant. De cette manière, le client CL signifie son accord pour le descriptif DESF provenant d'un fournisseur FO identifié.

3 - L'autorité bancaire certificatrice ABC renvoie au client CL le descriptif DESF et la signature, Signature-F, de celui-ci par le fournisseur FO, associés à un numéro d'autorisation NA, le tout signé par ses soins. L'autorité ABC 15 prouve ainsi qu'elle prend en compte la transaction identifiée par le numéro d'autorisation NA, liée à un sujet représenté par le descriptif DESF, et pour un fournisseur FO déterminé correspondant à Signature-F. Le client CL a ainsi la preuve que sa demande concerne un sujet déterminé.

De préférence, I'affichage des descriptifs DESF est généré 20 automatiquement chez le client CL, par le proxy client 21, à partir des informations reçues et qui constituent la base des preuves.

Lorsque le client CL est d'accord avec le descriptif DESF renvoyé par l'autorité bancaire certificatrice ABC, il envoie la signature, SignatureN, de l'autorité bancaire certificatrice ABC au fournisseur FO. Le fournisseur FO a 25 ainsi la preuve que l'autorité bancaire certificatrice ABC lui doit un versement.

Dans le cas contraire, le client CL annule la transaction entamée en l'interrompant.

Les échanges et opérations décrits ci-dessus sont représentés de manière détaillée à la Fig.8.

Conformément à un autre mode de réalisation du mécanisme de nonrépudiation implanté dans le procédé de l'invention, il est assuré une nonrépudiation de type "incrémental".

Avec ce mode de réalisation de type incrémental, le fournisseur FO envoie morceau par morceau le document DOC et attend la signature, Signature-C, du client CL pour chaque morceau ou tronçon envoyé avant d'envoyer le morceau suivant. Le client CL ne peut reconstruire le document 5 DOC que s'il dispose de l'intégralité des morceau. Cette solution présente l'avantage d'obliger le client CL à envoyer sa signature. De préférence, la signature, Signature-C, envoyée par le client CL porte sur l'ensemble des morceaux reçus et prouve la réception de ceux-ci. Le fournisseur FO n'a donc pas à conserver comme preuve l'ensemble des signatures des morceaux 10 reçus. Le diagramme de séquence de ce mécanisme est montré à la Fig.9.

Afin de ne pas avoir un temps de réponse trop important introduit par la signature de l'ensemble des morceaux reçus, le calcul de la signature, Signature-C, s'appuie sur un calcul précédent. Les égalités suivantes sont utilisées: Signature = Ccléprivée(H(H(Donnéesn-1), Donnéesn)) Signature = Ccléprivée(H(Données)) dans lesquelles, Signature est la signature portant sur l'intégralité des données transmises y compris celles du morceau courant, 2 o Données représente l'intégralité des données transmises, morceau courant compris, Donnéesn représente les données transmises du morceau courant, Donnéesn_1 représente l'intégralité des données transmises dans les morceaux précédents, CcléprivéeO est la fonction de chiffrement qui génère la signature à l'aide de la clé privée, H( est la fonction de hachage générant l'empreinte.

Dans le mécanisme de non-répudiation, il est préférable, compte-tenu de la technologie actuelle, d'employer l'algorithme de chiffrement MD5 pour 30 l'empreinte et l'algorithme de chiffrement RSA pour la signature. La taille choisie pour les clés est par exemple de 1042 bits.

Le mécanisme de non-rejeu a pour finalité d'empêcher toute personne d'utiliser des transactions, des preuves, etc., issues de communications préalables afin de s'en resservir à des fins illicites. Le problème des rejeux se pose à plusieurs niveaux différents dans l'architecture: Lorsque le client est débité: cette opération se fait à partir d'une transaction. Même si cette transaction est sécurisée, par SSL par exemple, rien n'empêche à un pirate de rejouer la transaction sécurisée sans en comprendre le sens. Le serveur comprendra le sens de la transaction et rejouera l'opération bancaire. Ce type de rejeu est appelé "rejeu de paiement". 10 - Lorsque le client recharge un document DOC pour la nième fois: le client peut rejouer la transaction d'un chargement précédent auprès du fournisseur. Ce type de rejeu est appelé "rejeu de chargement".

- Lorsque le fournisseur doit prouver que le client à bien reçu un document: il peut, dans le cas d'un chargement effectué pour la seconde fois 15 et plus, ne rien envoyer et présenter comme preuve les acquittements du client pendant le premier chargement. Ce type de rejeu est appelé "rejeu de preuve" Afin d'empêcher un rejeu de paiement, un identifiant unique à usage unique doit être inclus dans la transaction. Une solution adaptée au procédé 20 selon l'invention est l'intégration d'un système question-réponse: le CHALLENGE. L'autorité bancaire certificatrice ABC génère une information aléatoire qui doit être reprise dans la réponse. Cette solution est représentée à la Fig.1 0.

Le système du CHALLENGE est également utilisable pour le rejeu de 25 chargement. De préférence, le fournisseur FO gère son propre CHALLENGE de manière analogue à l'autorité bancaire certificatrice ABC. Comme montré à la Fig.11, avant de recevoir l'approbation de l'autorité bancaire certificatrice ABC, le fournisseur FO lui envoie un CHALLENGE à usage unique que celleci devra retourner avec l'approbation.

Pour contrecarrer un rejeu de preuve, il est nécessaire de lier le téléchargement de données à un élément variant au fil du temps. Un bon compromis pour cet élément variable dans le temps et l'utilisation du numéro d'autorisation NA fourni par l'autorité bancaire certificatrice ABC. Le numéro d'autorisation NA possède en effet les propriétés intéressantes suivantes: - le numéro NA évolue à chaque nouvelle demande de transaction validée auprès de l'autorité bancaire certificatrice ABC; le client ne peut pas falsifier le numéro NA sous peine de ne pas recevoir son document DOC; - le fournisseur FO ne doit pas modifier le numéro NA s'il veut être payé (c'est une preuve d'autorisation de paiement de la part de l'autorité bancaire certificatrice ABC); et - I'utilisation du numéro NA évite d'avoir à générer un surplus d'information.

Cette solution de l'utilisation du numéro d'autorisation NA est représentée de manière globale à la Fig.12.

Les mécanismes faisant appel à un chiffrement décrits jusqu'ici et 15 intégrés dans le procédé selon l'invention concernent les preuves qui accompagnent les documents. Il est nécessaire toutefois de chiffrer également les documents transmis par le fournisseur de manière à ce qu'ils ne soient relus que par leurs destinataires. Cette fonction est remplie par le mécanisme de confidentialité qui chiffre non seulement les documents 20 transmis mais également les preuves qui les accompagnent et qui ont été générées par les mécanismes d'authentification, d'intégrité et de nonrépudiation.

Le mécanisme de confidentialité utilise un algorithme de chiffrement avec une clé secrète symétrique de type DES. Compte-tenu que le 25 fournisseur FO doit dialoguer avec de très nombreux clients CL, il est fait appel à une clé de session Cs. Cette solution évite au fournisseur FO d'avoir à gérer autant de clés que de clients CL. L'homme du métier choisira la taille de la clé de manière à ne pas pénaliser les performances tout en garantissant la confidentialité. Bien que le chiffrement indiqué cidessus soit en lui-même déjà 30 très robuste, du fait de la technique SSL, pour certaines applications demandant encore plus de robustesse, des datagrammes "leurres" peuvent être inclus de manière aléatoire dans les données. Une technique simple adoptée dans le procédé selon l'invention consiste à envoyer un datagramme leurre dont un des bits de données est modifié. Du fait de cette modification d'un bit, la signature ne correspond pas aux données, et il est aisé pour l'application de discriminer le datagramme leurre.

Les mécanismes décrits ci-dessus nécessitent pour la plupart une clé pour fonctionner. En résumé, le procédé selon l'invention requiert trois couples de clé privée/clé publique, à savoir, un couple Apr/Apu pour l'autorité bancaire certificatrice ABC, un couple Fpr/Fpu pour le fournisseur FO et un couple Cpr/Cpu pour le client CL, et une clé de session Cs partagée par le o10 client CL et le fournisseur FO.

La distribution des clés est un problème délicat, car elles doivent être acheminées sans subir de falsification (clés publiques) et sans être lues par un tiers (clés privées, clés de session). Le mécanisme de gestion et distribution des clés selon l'invention met à contribution chacun des 15 interlocuteurs.

L'autorité bancaire certificatrice ABC génère ses clés asymétriques publique et privée, Apu et Apr, et met en libre service sa clé publique Apu qui sert pour la validation des certificats dont elle est l'auteur. Cette clé publique Apu doit faire l'objet d'un certificat afin d'empêcher toute falsification. De 2 0 préférence, le couple de clés, Apr et Apu, est renouvelé périodiquement.

Le fournisseur FO génère ses clés asymétriques publique et privée, Fpu et Fpr. La clé publique Fpu fait l'objet d'un certificat auprès de l'autorité bancaire certificatrice ABC. Le certificat délivré par l'autorité bancaire certificatrice ABC est valable pendant une durée déterminée. Le certificat est 25 remis aux clients CL au lieu de la clé publique Fpu.

Le client CL génère aussi ses clés asymétriques publique et privée, Cpu et Cpr. Les clés sont valides pendant une durée déterminée. Le client CL délivre sa clé publique Cpu au fournisseur FO avec lequel il dialogue. La clé de session Cs est générée par le fournisseur FO et est délivrée au client CL 3 0 de manière sécurisée. La clé CS est chiffrée par le fournisseur FO à l'aide de la clé publique Cpu du client CL.

Le procédé selon l'invention, compte-tenu de son haut niveau de sécurisation, génère un nombre important d'échanges. Afin de réduire le nombre des échanges, le procédé selon l'invention, dans certains modes de réalisation, utilise de préférence les échanges HTTP classiques afin d'y 5 adjoindre tous les éléments possibles. Ainsi, les échanges HTTP peuvent être mis à profit avec les dispositions suivantes: le client CL envoie le BAIL au fournisseur FO en même temps qu'il lui demande une page; les descriptifs et le certificat du fournisseur F0 sont livrés au client CL en 10 même temps que la page demandée par celui-ci; la demande de formulaire par le client CL auprès de l'autorité bancaire certificatrice ABC s'accompagne du certificat du fournisseur FO que le client CL veut vérifier; lors du renvoi du formulaire au client, I'autorité bancaire certificatrice 15 ABC joint la validité du certificat, et le CHALLENGE contre le rejeu de paiement; le client CL, en envoyant son numéro de compte et son mot de passe à l'autorité bancaire certificatrice ABC, joint la réponse au CHALLENGE. De plus, le client CL livre sa clé publique Cpu qui après quelques échanges et 2 o redirections parvient jusqu'au fournisseur F0; lorsque le fournisseur FO livre le numéro d'autorisation NA à l'autorité bancaire certificatrice ABC pour validation, il lui remet le CHALLENGE pour éviter le rejeu de toutes les transactions inhérentes à un document; l'autorité bancaire certificatrice ABC, en renvoyant l'approbation de 25 livraison au fournisseur FO, lui signifie également la réponse au CHALLENGE; dès le premier envoi du document au client CL par le fournisseur FO, ce dernier envoie, en plus du début du document, le descriptif DESF et le numéro d'autorisation NA.

De plus, les proxies 21, 31, peuvent être mis à contribution pour gérer des redirections à la place du navigateur 20 quand cela est possible. Cela représente un intérêt pour la demande de formulaire que le proxy client 21 peut gérer, et pour le numéro d'autorisation NA qui peut être validé par le proxy fournisseur 31. De plus, le protocole HTTP/1.1 est avantageux avec ses connexions persistantes qui apportent des économies de ressources en termes d'unité centrale CPU, de mémoire et de réseau.

Conformément à un autre mode de réalisation préféré du procédé selon l'invention, il est utilisé un codage source autorisant une compression des données au format gzip, et un codage canal autorisant une redondance d'information.

Avec le codage canal, il est possible de détecter et de corriger les l0 erreurs sans avoir à réémettre les données. Dans la majorité des cas, le temps de transmission est bien supérieur au temps de détection et correction des erreurs, et l'utilisation d'une détection et correction des erreurs conduit à une amélioration des performances.

Conformément au procédé de l'invention, il est fait appel à une 15 transformée Mojette pour le codage canal afin d'introduire une redondance d'information autorisant une correction d'erreurs. Le lecteur se reportera utilement à l'article "Internet distributed image information system" de J.P.

Guédon, B. Parrein et N. Normand, publié dans "Integrated Computer - Aided Engineering", 8 (2001), pages 205-214, ISSN 1069-2509, IOS Press, pour 20 tout complément d'information sur la transformée Mojette et ses propriétés.

Cette transformée génère une pluralité de N projections pour une image à transmettre. Les N projections sont transmises, et, à l'extrémité de réception, un nombre minimal de n projections suffit pour reconstruire l'image, avec n<N.

Le protocole de communication utilisé pour les échanges effectués conformément au procédé selon l'invention est maintenant plus particulièrement décrit. Il convient de noter que le protocole de communication utilisé dans le procédé selon l'invention, protocole appelé PTL dans la suite de la description, doit satisfaire à des contraintes de temps réel et d'intégrité des 3 o données. Le protocole PTL conçu par l'inventeur de la présente demande est basé sur des mécanismes présents dans les protocoles connus RTP et TCP, mais qui ont été adaptés et combinés pour répondre aux besoins du procédé selon l'invention. Le protocole PTL fait partie de la couche applicative et est véhiculé par le protocole UDP.

Une phase de négociation préalable est prévue afin que deux machines utilisant le protocole PTL conviennent de la version du protocole qui sera utilisé par la suite.

Le protocole PTL autorise une gestion des flux adaptée pour l'implantation du mécanisme de non-répudiation incrémentale décrit plus haut lors de la livraison d'un document DOC au client CL par le fournisseur FO.

Conformément à ce mécanisme de non-répudiation incrémentale, I'envoi de 10 données du document DOC par le fournisseur FO est conditionné par le renvoi de la signature du client CL, Signature-C, sur ce qui a été reçu par le client CL. Cependant, afin d'avoir un transfert rapide, il n'est en fait pas souhaitable d'attendre de manière systématique le renvoi de Signature-C pour transmettre la suite du document DOC, car le transfert tendra à s'éterniser. 1is L'approche avec le protocole PTL est d'envoyer par avance et sans contrainte tout ce qui peut l'être sans pour autant que l'information soit reconstructible chez le client CL. En d'autres termes, le fournisseur FO n'envoie la dernière partie de chaque information, celle permettant la régénération de l'information, que lorsqu'il aura reçu du client CL la signature attendue.

En référence à la Fig.13, il est décrit dans les paragraphes suivants un mécanisme de gestion de deux files implanté dans le serveur fournisseur 3 pour l'obtention du fonctionnement indiqué ci-dessus.

Comme montré à la Fig.13, un identifiant de transaction IDT et ajouté au document DOC à livrer. L'identifiant de transaction IDT permet de récupérer 25 les conditions de l'accord de l'étape S2 décrite en référence à la Fig.2.

L'ensemble DOC + IDT est découpé en M tronçons T1 à TM, avec M = 4 dans cet exemple et Tm étant un tronçon quelconque, m variant de 1 à M. Les tronçons T1 à TM sont signés chacun avec la clé privé Fpr du fournisseur FO et une transformée Mojette est appliquée à chacun des ensembles de tronçon 30 et signature, Tm + Signature-F. Pour chaque ensemble Tm + Signature-F, il est obtenu un nombre maximal de N projections Pm.1 à Pm.N. Conformément aux propriétés de la transformée Mojette, un nombre minimal de n projections, n < N, sont nécessaires pour reconstruire un ensemble Tm + Signature-F. La transmission des informations vers la machine client 2 est effectuée sous la forme de trames TR.

Deux files FC et FS sont utilisées. La file FC est une file conditionnelle 5 dont les envois sont soumis à condition, à savoir, la réception de la signature du client, Signature-C. La file FS est une file standard qui effectue des envois sans contrainte particulière.

Pour chaque ensemble Tm + Signature-F, n-1 projections correspondantes Pm sont envoyées dans la file standard FS et les N-(n-1) 10 projections Pm restantes sont envoyées dans la file conditionnelle FC. Dans l'exemple de la Fig.13, il est considéré pour des raisons de simplification que M = 4 et N = n, et donc, pour chaque ensemble Tm + Signature-F, une seule projection, Pm.1 dans cet exemple, est envoyée dans la file conditionnelle FC et les n-1 projections restantes, Pm.2 à Pm.n, sont placées dans la file 15 standard FS. Les n-1 projections Pm stockées dans la file standard FS sont envoyées sans aucune contrainte vers la machine client 2. En cas de retard sur un ensemble Tm + Signature-F, les ensembles Tm + Signature-F suivants du document DOC sont envoyés à la machine client 2 à hauteur de n-1 projections. La machine client 2 doit attendre la réception d'au moins une 2 0 projection Pm supplémentaire transmise par la file conditionnelle FC pour être en mesure de reconstruire l'ensemble Tm + Signature-F correspondant.

Lorsque le machine client 2 a correctement reçu n projections Pm, elle applique une transformée Mojette inverse aux n projections Pm reçues et reconstruit ainsi l'ensemble Tm + Signature-F. A ce stade, la machine client 2 25 vérifie la validité de Signature-F à l'aide de la clé publique Fpu du fournisseur FO. Si Signature-F n'est pas valide, la machine client 2 interrompt la transaction avec le serveur fournisseur 3. Si Signature-F est valide, la machine client 2 poursuit le processus en signant avec sa clé privé Cpr le tronçon Tm reçu, ou tous les tronçons Tm du document DOC qui ont été 30 reçus, selon le mode de réalisation du procédé de l'invention, et la signature obtenue, Signature-C, est envoyée au serveur fournisseur 3.

Lorsque le serveur fournisseur 3 reçoit la signature, Signature-C, du client CL, il vérifie en premier lieu la validité de celle-ci à l'aide de la clé publique Cpu du client CL. Si Signature-C n'est pas valide, le serveur fournisseur 3 interrompt la transaction avec la machine client 2. Si Signature5 C est valide, le serveur fournisseur 3 supprime dans les files les projections Pm restantes correspondant au dernier tronçon Tm reçu par la machine client 2 pour libérer de la place et poursuit l'envoi des ensembles Tm + Signature-F.

Ce n'est que lorsque le serveur fournisseur 3 reçoit une signature, SignatureC, de la machine client 2 qu'il envoie une projection Pm de la file 10 conditionnelle.

Pour démarrer le processus, au moins n projections Pm d'un premier ensemble Tm + Signature-F sont envoyées tout d'abord par le serveur fournisseur 3 afin de permettre à la machine client 2 de reconstituer un premier tronçon Tm et d'envoyer sa signature, Signature-C, sur ce tronçon.

Une priorité supérieure est octroyée à la file conditionnelle FC par rapport à la file standard FS, ce qui signifie que l'envoi d'une projection Pm par la file FC est prioritaire à l'envoi d'une projection Pm par la file FS. Tant qu'une file n'est pas pleine, I'envoi de projections à l'intérieur de celle-ci se fait sans contrainte. Lorsque la machine client 2 acquitte une projection Pm, celle2 0 ci est supprimée des files de manière à libérer de la place.

Le fonctionnement décrit ci-dessus correspond à un fonctionnement parfait du mécanisme, c'est-à-dire, au cas où toutes les trames TR sont reçues par la machine client 2 et sont acquittées et signées par celle-ci. Il est maintenant traité le cas ou les informations ne transitent pas correctement 25 entre les deux interlocuteurs, par exemple, consécutivement à une perte de trame, un engorgement du réseau, etc..

Dans le cas d'un envoi par la file standard FS, après l'expiration d'un délai prédéterminé DS, la projection Pm est réémise, si elle est toujours dans la file FS, même sans avoir été acquittée.

Dans le cas d'un envoi par la file conditionnelle FC, après l'expiration d'un délai prédéterminé DC, il est envoyé de nouvelles projections Pm, différentes de celles déjà envoyées. En effet, il est possible que certaines projections Pm aient été correctement reçues par la machine client 2 mais que le serveur fournisseur 3 n'ai pas reçu l'acquittement. Ne connaissant pas les projections Pm qui ont été reçues correctement, I'envoi de nouvelles projections Pm permettra néanmoins la reconstruction, ce qui est impossible s si la machine client 2 reçoit plusieurs fois la même projection Pm.

Toujours dans le cas d'un envoi par la file conditionnelle FC, le délai DC n'est pas calculé à partir du non-acquittement d'une projection Pm, mais à partir de la non-signature du tronçon Tm correspondant. En effet, il est possible que la projection Pm.n du tronçon Tm soit correctement acquittée 10 mais que l'une au moins des n-1 projections Pm restantes ne le soit pas.

Comme montré à la Fig.14, le protocole PTL fait appel à des trames TR de longueur variable comprenant un champ d'en-tête EN et différents champs optionnels CO. Les champs comportent chacun un bit BS signalant la présence éventuelle d'un champ suivant. Les différents champs s'assemblent 1_5 ainsi comme des briques pour former une trame TR. Cette structure autorise une adaptation aisée du protocole PTL en fonction des données à véhiculer sur le réseau.

Les champs optionnels CO comprennent notamment un champ de réponse attendue, un champ d'acquittement, un champ de tronçon, un champ 20 de clé publique, un champ de clé de session, un champ de certificat, un champ de CHALLENGE, un champ de réponse au CHALLENGE, un champ de chiffrement, un champ de signature, un champ de transformée Mojette, et un champ d'acquittement sécurisé de transformée Mojette.

Le champ d'en-tête EN indique la version du protocole PTL. La version 25 permettra d'identifier les champs optionnels CO possibles, leur format ainsi que les possibilités de dialogue entre les interlocuteurs. Des informations identifiant le document DOC auquel l'en-tête est rattaché sont également incluses dans le champ d'en-tête EN.

Le champ optionnel de réponse attendue est prévu de manière à ce que 30 le serveur fournisseur 3 puisse indiquer à la machine client 2 le type de réponse qu'il attend. En effet, lorsque le serveur fournisseur 3 envoie des données à la machine client 2, cette dernière doit les acquitter de manière appropriée. Ce champ est absent lorsque aucune réponse n'est attendue.

Le champ d'acquittement est utilisé par le serveur fournisseur 3 pour l'acquittement des trames envoyées. Il est ainsi évité une réémission de 5 trames qui ont été reçues, et la file d'émission correspondante est libérée pour un stockage d'autres trames à envoyer.

Le champ optionnel de tronçon est utilisé pour découper les données et les envoyer progressivement sous certaines conditions. Ce champ inclus des éléments d'information autorisant une reconstruction des données.

Le champ optionnel de clé publique est utilisé par la machine client 2 pour transférer la clé publique Cpu du client au serveur fournisseur 3. Le serveur fournisseur 3 utilise la clé publique Cpu notamment pour chiffrer la clé de session Cs qu'il envoie à la machine client 2. Un code d'algorithme pour la clé est inclus entre autres dans ce champ.

Le champ optionnel de clé de session est similaire au champ optionnel de clé publique décrit ci-dessus. Le champ optionnel de clé de session est employé par le serveur fournisseur 3 pour délivrer la clé de session Cs à la machine client 2. Un code d'algorithme pour la clé est inclus entre autres dans ce champ.

Le champ optionnel de certificat permet au serveur fournisseur 3 de s'identifier auprès de la machine client 2 et cela en lui envoyant son certificat.

Le champ optionnel de CHALLENGE est utilisé par le serveur fournisseur 3 pour envoyer le CHALLENGE à la machine client 2. Le champ optionnel deCHALLENGE inclus entre autres un identifiant du CHALLENGE 2 5 et un code pour l'opération à effectuer sur le CHALLENGE.

Le champ optionnel de réponse au CHALLENGE est employé par la machine client 2 pour transmettre sa réponse au CHALLENGE transmis par le serveur fournisseur 3. Le champ optionnel de réponse au CHALLENGE comprend entre autres un identifiant du CHALLENGE et la réponse au 3 0 CHALLENGE.

Le champ optionnel de chiffrement inclus notamment un code correspondant à l'algorithme utilisé pour chiffrer les données.

Le champ optionnel de signature comprend entre autres un code de chiffrement, correspondant à un couple d'algorithmes utilisés, et la signature.

Le champ optionnel de transformée Mojette est employé par le serveur fournisseur 3 pour transmettre à la machine client 2 les différents paramètres 5 nécessaires afin d'appliquer une transformée Mojette inverses aux projections P. En appliquant la transformée Mojette inverse aux projections P reçues, le document DOC transmis est reconstruit par la machine client 2.

Le champ d'acquittement Mojette sécurisé est utilisé par la machine client 2 pour indiquer au serveur fournisseur 3 qu'elle a réussi à reconstruire le 10 document DOC. La machine client 2 signe avec la clé privée Cpr du client et la signature, Signature-C, est incluse dans le champ afin de fournir au fournisseur FO une preuve de la réception du document DOC. Un code de chiffrement correspondant au couple d'algorithmes utilisé pour la signature est contenu entre autres dans le champ d'acquittement Mojette sécurisé.

Le procédé selon l'invention étant divulgué dans la présente description, il est aisé pour l'homme du métier d'y inclure d'autres fonctionnalités visant par exemple à améliorer l'ergonomie et à automatiser la saisie des informations. Ainsi, il est possible de prévoir sur la machine client une saisie unique du login et du mot de passe correspondant, ou un remplissage 2 o automatique de formulaire, afin d'éviter à l'utilisateur d'avoir à indiquer plusieurs fois son login, son numéro de comptes, ses mots de passe, etc..

Dans un tel mode de réalisation, ces informations pourront par exemple être stockées localement de manière simple par le navigateur en employant des témoins de connexion, ou cookies, chiffrés à l'aide d'une clé. Il doit être clair 2 5 dans l'esprit du lecteur que ces différentes variantes de réalisation sont comprises dans la portée des revendications annexées.

Claims (11)

REVENDICATIONS

1. Procédé sécurisé de fourniture de documents payants via un réseau de communication tel qu'lnternet incluant une étape d'identification (S1) de 5 plusieurs interlocuteurs (2, 3, 4) intervenant dans le procédé et comprenant entre autres un serveur fournisseur (3) et une machine client (2), une étape d'accord (S2) entre lesdits interlocuteurs (2, 3, 4) et une étape de livraison (S3) d'un document (DOC) à ladite machine client (2) par ledit serveur fournisseur (3), caractérisé en ce que ladite étape de livraison de document 10 (S3) comporte les sous-étapes consistant, pour ledit serveur fournisseur (3), à: fl) ajouter un identifiant de transaction (IDT) audit document (DOC) à livrer et former ainsi un ensemble de document et identifiant (DOC + IDT), f2) découper en une pluralité de M tronçons (T1 à TM) ledit ensemble de 15 document et identifiant (DOC + IDT), f3) signer chacun desdits M tronçons (T1 à TM) et former ainsi une pluralité de M ensembles de tronçon et signature de fournisseur correspondants (Tm + Signature-F), f4) appliquer une transformée Mojette à chacun desdits M ensembles de 20 tronçon et signature de fournisseur (Tm + Signature-F) pour décomposer chacun de ceux-ci en une pluralité de N projections correspondantes (Pm.1 à Pm.N), sachant qu'un dit ensemble de tronçon et signature de fournisseur (Tm + Signature-F) peut être reconstruit à l'aide d'une transformée Mojette inverse avec un nombre minimal de n projections, n < N, f5) envoyer à ladite machine client (2) au moins n desdites projections correspondantes (Pm.1 à Pm.N) pour un seul ensemble de tronçon et signature de fournisseur (Tm + Signature-F) à envoyer à ladite machine client (2), f6) envoyer à ladite machine client (2) n-1 desdites projections 30 correspondantes (Pm.1 à Pm.N) pour chacun des M-1 ensembles de tronçon et signature de fournisseur (Tm + Signature-F) restant à envoyer à ladite machine client (2); les sous-étapes consistant, pour ladite machine client (2), à: cl) reconstruire ledit ensemble de tronçon et signature de fournisseur (Tm + Signature-F) envoyé par ledit serveur fournisseur (3) par application de ladite transformée Mojette inverse auxdites au moins n projections correspondantes reçues (Pm), c2) vérifier la validité de la signature de fournisseur (Signature-F) incluse dans ledit ensemble de tronçon et signature de fournisseur reconstruit (Tm + Signature-F), et, si celle-ci est valide, signer le tronçon reçu (Tm) inclus dans ledit ensemble reconstruit pour former une signature de client (Signature-C), c3) envoyer audit serveur fournisseur (3) ladite signature de client (Signature-C); et la sous-étape consistant également, pour ledit serveur fournisseur (3), à: f7) vérifier ladite signature de client reçue (Signature-C), et, si celle-ci est valide, envoyer à ladite machine client (2) au moins une desdites N-n+1 projections restantes pour un dit ensemble de tronçon et signature de fournisseur (Tm + Signature-F) suivant à envoyer à ladite machine client (2); lesdites sous-étapes cl) à c3) et f7) étant répétées jusqu'à la reconstruction par ladite machine client (2) desdits M ensembles de tronçon et signature de fournisseur (Tm + Signature-F) afin de reconstituer ledit 2 0 document et ledit identifiant de transaction (IDT).

2. Procédé selon la revendication 1, caractérisé en ce que ladite signature de client (Signature-C) incluse dans ladite sous-étape c2) porte sur tous les tronçons reçus et reconstruits (T1 à Tm) dudit document (DOC). 25

3. Procédé selon la revendication I ou 2, caractérisé en ce que des couples de clés asymétriques constitués chacun d'une clé privée (Fpr, Cpr) et d'une clé publique (Fpu, Cpu) sont employés par ledit serveur fournisseur (3) et ladite machine client (2) pour signer et vérifier lesdites signatures (Signature3 0 F, Signature-C).

4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que la non-réception d'une signature valide (Signature-F, Signature- C) par ledit serveur fournisseur (3) ou par ladite machine client (2) ou un autre desdits interlocuteurs (2, 3, 4) met fin à la transaction.

5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que lorsqu'une projection (Pm) envoyée à ladite machine client (2) pendant la sous-étape f7) n'est pas acquittée par ladite machine client (2) avant l'expiration d'un délai prédéterminé (DC), ledit serveur fournisseur (3) envoie 10 au moins une nouvelle projection (Pm) différente de celles déjà envoyées, et lorsqu'une projection (Pm) envoyée à ladite machine client (2) pendant une sous-étape différente de la sous- étape f7) n'est pas acquittée par ladite machine client (2) avant l'expiration d'un autre délai prédéterminé (DS), ladite projection (Pm) est réémise.

6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'il utilise un protocole de communication (PTL) avec des trames (TR) de longueur variable comprenant un champ d'en-tête (EN) et une pluralité de champs optionnels (CO).

7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ladite étape d'identification (1) desdits interlocuteurs (2, 3, 4) inclut l'envoi d'un ou plusieurs certificats (CER) émanant d'un serveur d'organisme certificateur (4) et l'utilisation de couples de clés asymétriques constitués 25 chacun d'une clé privée (Cpr, Fpr, Apr) et d'une clé publique (Cpu, Fpu, Apu).

8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que ladite étape d'accord (S2) entre lesdits interlocuteurs (2, 3, 4) inclut une opération de signature d'un descriptif formant preuve (DESF) qui identifie un 30 document (DOC) objet de la transaction ainsi que le prix dudit document (DOC).

9. Procédé selon l'une quelconque des revendications I à 8, caractérisé en ce que ladite étape d'identification (S1) desdits interlocuteurs (2, 3, 4) inclut l'octroi par ledit serveur fournisseur (3) d'une autorisation d'accès (BAIL) de durée prédéterminée à un client identifié pour un accès auxdits documents (DOC).

10. Procédé selon l'une quelconque des revendications I à 9, caractérisé en ce que, afin de lutter contre d'éventuelles opérations de rejeu effectuées à des fins illicites, certains desdits interlocuteurs (3, 4) génèrent des informations 'o aléatoires (CHALLENGE) que ladite machine client (2) doit reprendre dans des réponses envoyées auxdits interlocuteurs (3, 4), et en ce qu'un numéro d'autorisation de transaction (NA) délivré par un serveur d'organisme financier (4) compris parmi lesdits interlocuteurs (2, 3, 4) est intégré dans les données transmises à ladite machine client (2) lors de la livraison par ledit serveur 15 fournisseur (3) du document acheté (DOC).

11. Procédé selon l'une quelconque des revendications 1 à 10, caractérisé en ce qu'une clé de session (CS) est utilisée entre ledit serveur fournisseur (3) et ladite machine client (2) pour le chiffrement des données envoyées.