FR 2793981 A1 20001124 FR 0002347 A 20000224 La présente invention concerne un appareillage et une méthode pour l'authentification de trafic Web. En particulier, la présente invention concerne la vérification des requêtes effectives reçues par un serveur Web, pour en démontrer l'intérêt réel de la part des utilisateurs, dans le but d'obtenir une authentification, d'une tierce partie du trafic Web et/ou de statistiques d'accès au serveur même, utiles pour démontrer l'importance du site, même dans le but de la vente de publicité. D'une manière analogue, la présente invention concerne le comptage certifié de chaque accès aux pages, aux images et à d'autres informations comprises dans des hypertextes ou dans des documents multimédias. De manière connue, pour évaluer et certifier les requêtes reçues par un serveur Web il faut, d'une façon ou d'une autre, réaliser une vérification du client (Browser) ou de l'utilisateur qui se connecte. Un contrôle sur le serveur est en effet facilement contournable : il suffit de produire des requêtes artificielles par un ordinateur placé à l'intérieur du réseau local où se trouve le serveur même. Il est important de remarquer que ces requêtes peuvent être faites, au niveau du réseau, avec une adresse IP modifiée. et résulter ainsi comme provenantes de plusieurs utilisateurs distribués géographiquement sur le réseau de l'Internet. Pour contrôler la connexion réelle du client, comme il résulte des fichiers de log du serveur même, restent donc trois possibilités : (a) pro-,,7oquer une connexion de contrôle du client même, au moment de la connexion à vérifier, à effectuer vers un ordinateur géré par l#organisation qui effectue la vérification ; (b) fournir à l'utilisateur un client (Brov'-ser) modifié qui enregistre les connexions effectuées ou une partie de celles-ci, rendant ensuite disponibles ces données à l'organisation d'authentification, oLi (c) réaliser des sondages ou des contrôles à posteriori, ou utiliser les données générales disponibles sur l'utilisateur final. Toutefois ces techniques présentent des inconvénients, avec des conséquences concrètes graves concernant la faisabilité du contrôle. La technique (a) produit un contrôle précis, mais ralentit la connexion du client, qui doit se connecter chaque fois aussi au site de contrôle. La technique (b) n'est pas envisageable, puisque concrètement la possibilité de fournir des Browser modifiés à un nombre suffisant d'utilisateurs n'existe pas. La technique (c) est efficace mais imprécise, puisqu'elle ne fournit que des indications approximatives sur le trafic enregistré par les sites plus C grands. De plus, elle est très coûteuse puisqu'elle exige une recherche sur 1# -- un nombre d'utilisateurs très éleNé. Il y a aussi des solutions basées sur les techniques (a) et (c), alors que, ne baser le contrôle que sur la technique (b) n'est pas envisageable. Il existe, toutefois des solutions qui intègrent les techniques (b) et (c), limitant (b) à un échantillon d'utilisateurs, comme il arrive pour l'audimat de la télévision. Dans la littérature scientifique et des bre#,-ets, on a proposé des solutions visant à résoudre, au moins partiellement, le problème de la vérification des requêtes réelles reçues par un serveur Web, pour en démontrer l'intérêt réel des utilisateurs, dans le but d'obtenir une authentification d'un tiers du trafic Web. Beaucoup de travail a été consacré à la compréhension, à la synthèse et à la correction des fichiers de log. L'étude de Pitkow, (Pitkow, In Search of Reliable Usage Data on the WWW, Proc. Int. WWW Conf., 1997) fournit un bon aperçu, avec des références spécifiques à lutilisation des "proxy". De toute façon, la majeure partie de ce travail ne traite pas le sujet de la falsification intentionnelle de la part de l'organisation qui gère le serveur. Quant à cet aspect du problème, important dans le but de cette invention, deux études récentes sont intéressantes. 1) Le travail de Naor et Pinkas, (Naor and Pink-as, Secure Efficient Metering, Proc. Eurocrypt, Springer-Verlag 1998) est basé sur le partage d'un secret parmi les différents clients, et sur la transmission des parties du secret du client au serveur, pour que le serveur puisse prouver sa quantité d'accès en reconstruisant le secret d'ori-ine. Pour ce faire, il faut une initialisation spéciale des clients ce qui n7est pas faisable dans le domaine du Web, où les Brov,,ser commerciaux ne peuvent pas être modifiés sur une grande échelle. 2) Le travail de Franklin et Malkhi (Franklin and Malk-hi, Auditable Metering ,,%-ith Lightweight Security, Proc. Financial Cryptography Workshop, Springer-Verlag, 1997) utilise un schéma de temporisation pour aucymenter les coûts des requêtes fausses de la part des clients, de sorte que la falsification d'un nombre d'accès élevés, devienne peu rentable. A ce travail correspond la demande de brevet international publié au n' W09826571 de 1998. La technique de Franklin et Malkhi demande à des clients normaux de réaliser des calculs additionnels dans le seul but d'une vérification, ce qui assurément n'est pas à conseiller pour les serveurs commerciaux. Le but principal de cette invention est la réalisation d'un appareillage et de la méthode relative pour l'authentification du trafic Web, qui permettent de réaliser un contrôle efficace et exempt des inconvénients cités de l'art antérieur. En particulier, l'un des buts de cette invention est celui d'obtenir un contrôle précis au niveau de chaque requête, qui n'introduise ni de retards ni de manques d'efficience, et dont les coûts soient limités. A cet effet, cette invention fournit un appareil pour la génération et la vérification des fichiers de loc, et/ou des statistiques d'accès à un serveur d'application, tel un serveur Web, soumis à un contrôle, dont la caractéristique essentielle fait l'objet de la revendication 1. De plus, cette invention fournit une méthode pour la vérification des fichiers de log et/ou des statistiques d'accès à un serveur d'application, tel un serveur Web, soumis à un contrôle, à réaliser utilisant le susdit appareillage et dont la caractéristique essentielle fait l'objet de la revendication 10. D'autres caractéristiques avantageuses de l'invention font l'objet des revendications dépendantes. Cette invention ressortira mieux de la description détaillée qui suit, avec référence aux dessins annexés, fournis seulement à titre d*exemple, dans lesquels : - les figures de 1 à 5 sont des schémas à blocs qui représentent, à titre d"exemple, respectivement plusieurs variantes d'exécution de l'appareillage selon la présente invention, pour la génération et la vérification des fichiers (le log et/ou des statistiques d'accès à un serveur d'application, tel un serveur Web, soumis à un contrôle. De plus, de la description de l'appareil illustrée dans les figures de 1 a 5 il ressort clairement aussi l'explication de la méthode selon l'invention pour la vérification des fichiers de log et/ou des statistiques d'accès à un serveur d'application, tel un serveur Web, soumis à un contrôle, laquelle méthode est mise en #uvre en utilisant l'appareil même. En premier lieu, en référence à la Fig. 1, l'appareillage selon Vinvention pour la génération et la vérification des fichiers de log et/ou des statistiques d'accès à un serveur d'application, tel un serveur Web, soumis à un contrôle, est indiqué dans son ensemble avec 10 et il comporte essentiellement : a) Un serveur d'application 11, tel un serveur Web, soumis à un contrôle. Le susdit serveur Web 11 comporte des moyens de traitement et de communication (X), qui en modifient le comportement, en sorte que toute requête reçue par un client (Browser) quelconque, mais connu, avant d'être servie, est transmise, après un éventuel retraitement, à un dispositif dédié (12). Cette modification est réalisée, pour la majeure partie des plates- formes, comme un "module" additionnel, sans la nécessité donc, de modifier le noyau fonctionnel du serveur même. Ces modules peuvent être réalisés dans le traitement même du serveur, en évitant l'utilisation de ressources additionnelles et sans augmenter le temps dans lequel sont servies les requêtes du client. Pour les trois plates-formes principales de la situation actuelle (Microsoft IIS, Apache et Netscape), des modules ISAPI, des modules Apache et des modules NSAPI sont réalisés respectivement. Dans tous les cas, les susdits moyens de traitement et de communication (X) peuvent être intégrés aussi dans la programmation du serveur même. b) Le susdit dispositif dédié 12, appelé par la suite simplement "box", qui est, dans l'exemple illustré, connecté dans le même réseau local du susdit serveur 11. Le susdit box 12 comporte des moyens (Y) de calcul et de communication avec le susdit serveur d'application (11), au travers desquels il reçoit une description de chaque requête provenant de n'importe quel client (Bro,%N#ser 13) connecté avec le susdit serveur d'application (l 1) et il fournit au serveur même, en réponse à la susdite requête, un bit (B), qui vaut alternativement 0 ou 1 (comme il ressortira mieux par la suite). Dans la réalisation de l'invention illustrée ici, le susdit box 12 est scellé. Ce sceau a les caractéristiques techniques de "tamper evidence" (l'ouverture non autorisée reste visible) ou de "tamper-resistance" (Vouverture non autorisée est techniquement difficile), ou encore de "tiiiiiper-responding" (Vouverture non autorisée compromet le fonctionnement du box même, voir le travail de Anderson et de Kuhn : "Taniper Resistance - a Cautionary Note.", publié en "Proceedings of the Usenix Workshop on Electronic Commerce, 1996"). Un sceau de ce type peut être obtenu en réalisant le box avec un ordinateur renfermé dans une boîte, par laquelle ne soient pas accessibles les ports de communications (par exemple le port série, le port USB, la connexion au clavier. la souris et la vidéo) ; ceci en ne laissant que Faccès aux moyens de communication (Y) avec le susdit serveur d'application 11 (par exemple avec une interface Ethernet), et en appliquant sur les bords d ouverture de la susdite boîte des sceaux adhésifs antifalsification. En alternative, le box peut être réalisé avec des composants matériels réalisées explicitement avec des caractéristiques de tamper evidence , qui coniportent des moyens de calcul et de mémorisation selon l'invention, et qui seront connectées. par exemple, comme carte interne au susdit serveur d'application (11), en communiquant avec celui-ci à travers un bus de sN-sième. comme un bus PCI. c) LT)n serveur de contrôle (14), tel un serveur Web, connecté au susdit sen-eur d'application (11) et comportant des moyens pour recevoir des requêtes par des client (Browser 13) et pour mémoriser des descriptions des susdites requêtes. Comme il ressortira mieux par ce qui suit, la connexion d'un client vers le serveur de contrôle 14 n'est effectué que très rarement - celui-ci est Liii point essentiel. En particulier. on réalise un contrôle échantillon, qui, dans les con figurations de serveurs Web typiques de ce service, peut être fait une fois toutes les 10 000 connexions ou même plus rarement. Pour cette raison, Vappareil 10 dans son complexe n'introduit pas d'inefficacités. D'un test réalisé sur la plate-forme Microsoft avec Windows NT et sen-eur IIS, il résulte qu'un serveur non contrôlé a pratiquement le même rendement d'un serveur contrôlé 11, déjà pour des contrôles réalisés une fois lowes les 10 connexions. Il faut toutefois, que le moment du contrôle écliantillon ne soit pas prévisible -pour cette raison dans Vappareil 10 est prévu le box scellé 12. La fonction principale du susdit box 12 est d"Indiquer. pour chaque requête reçue par le susdit serveur de contrôle Il par un client 13. si elle doit être contrôlée ou non. En particulier, les moyens de traitement et de communication (X) du susdit serveur (11) transmettent chaque requête reçue par un client (13) quelconque, éventuellement après l'avoir traitée, aux susdits moyens de calcul et de communication (Y) du susdit box (12), en obtenant en réponse le susdit bit (B) en sorte que, si 13=0, on fournit au susdit client la réponse correspondante à la requête faite, alors que, si 13=1, on fournit au susdit client une réponse telle à causer une connexion par le client même au susdit serveur de contrôle (14). En particulier, le box (12) va produire un bit B en sorte que la probabilité de 13=1 soit très limitée. par exemple 1/10 000, sur la base des paramètres de configuration du système. La génération du bit B pourra être faite moyennant un algorithme cryptographique pour la génération de chiffres aléatoires, tel celui standardisé en ANSI X9.17. En alternative, le bit B pourra être généré sur la base de quantités physiques mesurées à Vintérieur du box même (température, bruit, etc.). Dans le premier cas, sera utilisée le même procédé cryptographique, avec les mêmes clés symétriques, au moment de la vérification par Vorganisation d'authentification responsable du contrôle. Dans le deuxième cas, les chiffres aléatoires à l'intérieur du box devront être authentifiés par le box même pour permettre la vérification par l'organisation de l'authentification même. Quand le contrôle n'est pas réalisé, le comportement de l'appareil 10 est illustré dans la figure 1. En séquence : 1) Le Browser 13 envoie une requête "Req" au serveur Il. 2) Celui-ci envoie une description "D(Req)" de cette requête au box 12, qui 3) répond avec "13=0". 4) Par conséquent le sen7eur 11 fournit la réponse "Resp" au Browser 13. Puisque la communication du serveur 11 avec le box 12 a lieu sur le réseau local ou nio-vennant une connexion directe, et cela de façon extrêmement simple, on n'observe aucun ralentissement - ce qui arrive pratiquement toujours, comme expliqué plus haut. Quand, au contraire, le contrôle est réalisé, la réponse du box 12 est B= 1. Ce cas se produit très rarement et de façon imprévisible. Dans ce cas, le contrôle est réalisé comme illustré dans la Fig. 2, c'est-à-dire : - les moyens de traitement et de communication (X) intégrés dans le susdit serveur d'application (11), dans le cas où B= 1, fournissent audit client (13) un message de redirection au susdit serveur de contrôle (14), sachant comprendre l'adresse de la ressource indiquée dans la requête, ou bien illustré dans la Fi-. 3, c'est-à-dire comme 1 c - les moyens de traitement et de communication (X) intégrés dans le susdit serveur d'application (11), dans le cas où 13=1, ajoutent ou intègrent dans la réponse au susdit client (13) un objet ou une référence qui détermine la connexion du client même avec le susdit serveur de contrôle (14) après la réception de la réponse même. Plus précisément, dans le cas illustré dans la Fig. 2, après la réalisation des phases 1) - 3), comme décrit plus haut avec référence à la Fig. 1, dans la phase 4) le seneur 11 n'envoie pas la réponse au Browser (client) 13, mais il envoie à celui-ci un message de "Redirect". Ce message prévu par le protocole HTTP (voir travaux susmentionnés de Berners-Lee) et accepté par tous les Brov,-sers commerciaux, engendre dans la phase 5) une autre connexion "Req2" du susdit Browser 13 au serveur de contrôle 14, qui peut ainsi vérifier l'existence réelle de la requête. Ce message "Req2" comporte l'identification de la requête d'origine, par exemple sous forme de LIRL. Pour que le susdit Bro#Nser 13 puisse, en tout cas, visualiser l'information requise par l'utilisateur, dans les phases suivantes 6) et 7) le Serveur de contrôle 14, pourvoit à ce point, moyennant les messages correspondants de "Redirect", à diriger à nouveau le Brovser 13 même vers le Serveur contrôlé 11, qui peut ensuite, dans la phase 8), fournir la réponse (message "Resp") au susdit Browser 13. D'ailleurs, dans le cas illustré dans la Figure 3, après le déroulement des phases 1)- 3) comme décrit plus haut avec référence à la F I -. 1, clans la phase 4) le serveur 11 envoie au client 1 _31 le message "Resp", niodifié de façon à comprendre un objet qui provoque dans la phase 5) la connexion suivante (moyennant un message "Contrôle") du susdit Browser 13 au serveur de contrôle 14. Cette modification n'influence toutefois pas les informations visualisées par le Browser 13, qui sont déjà complètes après la réception du susdit message "Resp" dans la phase 4). L'objet inté-ré dans cette "Resp" peut être, par exemple, [Il une image "inline" d'une page HTNfL ; ['21 un cadre (frame) non visible ou autre pareille composante de la page visualisée, située sur le serveur de contrôle 1 4 : [31 un script, un applet ou un autre logiciel à exécuter sur le client 13, qui va se connecter au serveur de contrôle 14 en fournissant la URL requise à l'origine, ou encore [4] un objet non-visible de n'importe quel type, qui c 1 enuendre un message de "Redirect" au serveur de contrôle 14. Avec référence aux Figures de 1 à 3, il ressort de ce qui a été e-.\pliqué ci-dessus, la façon dont l'appareil 10 selon Vinvention, se comporte pendant le processus normal d'interaction client/serveur sur le Web. Dans ce qui suit, on explique au contraire comment le susdit appareil 10 fonctionne, en fin de période, pour terminer la vérification et fournir donc une authentification du trafic, des statistiques d'accès, et/ou des fichiers de log relatifs au serveur contrôlé. Celui-ci fait l'objet des revendications de 10 à 15. D'abord une observation importante s'impose : même les requêtes que nous avons indiquées auparavant comme "non contrôlées", c'est-à-dire les requêtes pour lesquelles le bit B foumi par le box scellé 12 correspond à 0. doivent être d'une façon ou d'une autre bloquées et rendues non niodifiables après le moment où ce bit B est reçu. Si ce n'était pas le cas, il serait en fait possible de réaliser un grand nombre de requêtes artificielles par le réseau local du serveur, avec l'adresse IP correcte de l'ordinateur qui les réalise, et de changer ensuite les requêtes pour lesquelles B=O à posteriori, "gonflant" à volonté le trafic reçu de l'extérieur. Ce "bloc" d'informations concernant les requêtes au moment où le bit devient connu, petit être réalisé en deux modes particuliers de réalisation de l'appareil 10 selon l'invention, illustrés respectivement dans les figures 4 et 5. faisant l'objet respectivement de la revendication 4, ou des revendications de 5 à 8. De la même façon. la méthode de vérification et (Patithentification expliquée en référence à l'appareil de la Figure 4 est conforme à la revendication 11, tandis que la méthode de vérification et d'atithentification expliquée en référence à l'appareil de la Figure 5 est conforme aux revendications 12-14. Comme décrit dans la revendication 4, le susdit dispositif dédié (12) comporte des moyens de calcul et de communication (Y), qui calculent et foLirnissent, de plus, comme réponse, au susdit serveur d'application (l 1) un code d*aLithentification Auth(D(Req . dans lequel D(Req) est la description (le la requête Req reçue par le susdit serveur d'application (11). De cette façon, le box scellé 12 bloque le contenu informatif des requêtes pour lesquelles B=O, en fournissant en réponse au serveur contrôlé 11., outre le susdit bit B, un code d'authentification pour chaque requête reçue. Le code peut être un code d'authentification de message (message authentication code - MAC), calculé par exemple comme HMAC (voir le tra#,,-ail de Kra-vvezyk, Bellare and Canetti, 'HMAC : Keyed Hashing for Message Authentication", IETF-RFC 2104, 1997), ou bien, même si moins efficace, une signature digitale. Ces codes d'authentification devront être mémorisés par le Serveur contrôlé 11 et transmis en fin de période à un organisme préposé à l'authentification, qui pourra ainsi vérifier l'intégrité et l'exactitude des requêtes pour lesquelles B=O. Par conséquent, la méthode d'authentification utilisée dans ce cas (Figure 4 et revendication 11) prévoit la communication, par le serveur contrôlé 11, à l'organisation d'authentification, des requêtes R reçues pendant la période, des codes d'authentification correspondants Auth(R)= 'Authffl(Req #ReqeRl reçus par le box scellé 12, et du sous-ensemble de requêtes RC pour lesquelles B=I. Pour ce sous-ensemble de requêtes RC, devront exister, auprès du serveur de contrôle 14, des connexions directes de la part des clients correspondants. Si un nombre élevé de ces connexions devait manquer, l'authentification pourrait être refusée. De la même façon elle serait refusée au cas où les requêtes R ne seraient pas authentiques par rapport aux codes Auth(R). L'authentification concernera, dans ce cas, l'ensemble des requêtes R. Comme décrit dans les revendications 5 à 8, le susdit dispositif dédié (12) comporte des moyens de calcul (Z2) et de mémoire (ZI), qui calculent et mémorisent des informations I(R) obtenues des susdites descriptions des requêtes reçues par le susdit serveur d'application (11). à utiliser comme indiqué dans la revendication 12. En particulier, comme indiqué dans la revendication 6, les susdites informations I(R) peuvent comprendre des statistiques calculées sur la base des descriptions de requêtes reçues par le susdit serveur d'application (1 l)# à utiliser comme indiqué dans la revendication 13. En alternative, les susdits moyens de calcul (Z-1) et de mémoire (ZI) traitent et mémorisent à l'intérieur du box, des informations I(R) comprenants un code de hash calculé sur la base des descriptions de requêtes reçues par le susdit serveur d'application (11), comme indiqué dans la revendication 7, à utiliser comme indiqué dans la revendication 14. Le susdit box comporte en outre des moyens (A) pour transmettre dans une forme authentifiée les susdites informations I(R) au susdit serveur de contrôle (14). Moyennant la susdite disposition, le box scellé 12 ne fournit pas au serveur contrôlé 11 des codes d'authentification pour chaque requête. Dans le susdit box 12 sont calculées au contraire des informations I(R) sur la base des requêtes R reçues de temps à autre. Ces informations peuvent comprendre des statistiques d'accès au serveur, même sous forme d'une liste explicite de certaines requêtes reçues. Elles peuvent en outre comprendre des codes de hash ou le résultat d'un algorithme de compression, calculés sur la base des mêmes requêtes R. La méthode d'authentification utilisée dans ce cas est illustrée en référence à l'appareil de la Figure 5 et fait l'objet des revendications de 12 à 14. Les informations I(R), sont communiquées par le box 12, directement ou moyennant le serveur contrôlé 11, à la susdite organisation d'authentification. Celle-ci reçoit en outre, en fin de période, le sous- ensemble des requêtes RC pour lesquelles 13=1. Pour ce sous-ensemble de requêtes RC devront exister, auprès du serveur de contrôle, des connexions directes de la part client correspondants. Si un nombre élevé de ces connexions devait manquer, l'authentification pourrait être refusée. L'authenti f i cation concernera, dans ce cas, les informations citées I(R). Ceux qui gèrent le serveur de contrôle pourront, à ce moment, connecter les informations certifiées I(R) avec les requêtes R ou avec des statistiques concernant celles-ci, et en démontrer l'exactitude vis-à-vis de tiers. Si, en particulier, l(R) comprenait des statistiques d'accès, l'authentification de l(R) pourrait être montrée directement à ceux qui s'intéressent à l'exactitude (les statistiques mêmes. Si, au contraire. 1 est une fonction de hash, on aura la possibilité de montrer, à ceux qui sont intéressés à Vexactitude des requêtes R, le code certifié I(R) avec les mêmes requêtes R. Ces derniers pourront ensuite vérifier l'exactitude de R par rapport au code l(R). Dans ce cas il est souhaitable d'utiliser une fonction de hash à une voie qui soit résistante aux collisions (c'est-à-dire pour laquelle il ne soit pas possible de trouver de façon efficace RI et R-1 pour lesquels l(Rl)= l(R2 . Discussion sur les avantages des différentes formes de réalisation de l'invention. Comme il résulte de ce qui précède, Vinvention fournit une solution efficiente au problème suivant : (A) engendrer une connexion à un serveur de contrôle pour certaines (rares) requêtes et (B) bloquer le contenu des autres requêtes, quand il résulte (avec B=O) que le contrôle ne sera pas réalisé. Aussi bien pour la partie (A) que pour la partie (B) du problème cité. la présente invention fournit deux formes différentes de réalisation de la solution. En ce qui concerne le point (A) du problème cité, la première forme de réalisation de la solution correspond à la revendication 2 et elle est illustrée dans la Figure 2, alors que la deuxième forme de réalisation de la solution correspond à la revendication 3 et elle est illustrée dans la Figure 3. En particulier, la première forme de réalisation de la solution utilise un concept de redirection, alors que la deuxième utilise l'insertion de plusieurs parties dans un document multimédia ou hypertextuel. La deuxième forme de réalisation de la solution, comme il apparaît évident sur les figures citées, est sans aucun doute plus simple. Cette simplicité la rend aussi plus forte, en évitant des interruptions de la connexion pendant le contrôle. Les deux formes de réalisation de la solution sont supportées par les Brov,-sers actuels. La deuxième forme de réalisation de la solution prévoie une palette plus ample de réalisations alternatives, qui peuvent garantir la faisabilité pendant une période de temps plus longue. En ce qui concerne le point (B) du problème spécifié, la première t'ori-ne de réalisation de la solution consiste dans l'appareillage selon la revendication 4 et dans la méthode correspondante décrite dans la revendication 11, alors que la deuxième forme de réalisation de la solution consiste dans l'appareillage selon les revendications de 5 à 8 et la méthode relative décrite dans les revendications de 12 à 14. La première forme de réalisation de la solution produit une authentification explicite de toutes les requêtes R reçues pendant la période de référence. La deuxième forme de réalisation de la solution fournit une authentification indirecte, concernant des informations dérivées I(R). Toutefois, ces informations dérivées, au cas où 1 est une fonction de hash à une -voie et résistante aux collisions, -arantissent l'exactitude de l'ensemble total des requêtes R, comme dans le cas de la première forme de réalisation de la solution. L'avantage de la deuxième forme de réalisation de la solution est double. En premier lieu, il ii#est pas nécessaire de fournir, en fin de période, l'ensemble total R des requêtes reçues. Cela est important, étant donné que les serveurs qui peuvent être intéressées à l'authentification peuvent recevoir des dizaines de millions de requêtes par mois, et le simple transfert et contrôle de ces données peut entraîner des coûts opérationnels et de gestion très élevés. En deuxième lieu, suivant cette deuxième forme de réalisation de la solution, l'organisation d'authentification ne voit pas l'ensemble complet des requêtes, mais seulement un traitement I(R), qui dans le cas du code de liash ne fournit pas de contenu informatif sur les requêtes mêmes. Cela peut être important au cas où les requêtes comprenaient des informations considérées confidentielles ou évaluable en termes économiques. S'il n'existe pas de réserves de ce genre et si le trafic à contrôler est d'une petite étendue, même la première et la plus simple forme de réalisation de la solution peut être adéquate. REVENDICATIONS 1 . Appareillage pour la génération et la vérification des fichiers de log et/ou des statistiques d'accès à un serveur d'application (11), tel un serveur Web, sous contrôle, caractérisé en ce qu'il comporte : - un dispositif dédié (12), connecté au susdit serveur d'application (11) et comportant des moyens de calcul et de communication (Y) avec le susdit serveur d'application (11), au travers desquels, le dispositif dédié (12) reçoit une description D(Req) de chaque requête Req provenant d'un client quelconque (Browser 13) connecté au susdit serveur d'application (11) et il fournit à celui-ci, en réponse à la susdite description D(Req), un bit (B), qui vaut alternativement 0 ou 1, - un serveur de contrôle (14) incluant des moyens pour recevoir des requêtes par des clients (Browser 13) et pour mémoriser des descriptions des susdites requêtes, et - des moyens de traitement et de communication (X) intégrés dans le susdit serveur d'application (11), qui en modifient le comportement, de sorte que chaque requête reçue par le susdit serveur d'application (11) par un client (Browser 13), avant d'être servie, est transmise, après un traitement éventuel, au susdit dispositif dédié (12), en obtenant en réponse le susdit bit B, de sorte que, si 13=0, il sera fourni au client la réponse correspondant à la requête faite, alors que, si B=1, il sera fourni au client une réponse telle à causer une connexion du client même au susdit serveur de contrôle (14). 2. Appareillage selon la revendication 1, caractérisé en ce qu'il comporte des moyens de traitement et de communication (X) intégrés dans le susdit serveur d'application (11) et qui, dans le cas où 13=1, fournissent au susdit client (13) un message de redirection au susdit serveur de contrôle 1 4), sachant comprendre l'adresse de la ressource indiquée dans la requête. 3. Appareillage selon la revendication 1, caractérisé en ce qu'il comporte des moyens de traitement et de communication (X) intégrés dans le susdit serveur d'application (l 1) et qui, dans le cas où 13=1, ajoutent ou iiitèçyrent dans la réponse au susdit client (13), un objet ou une référence qui détermine la connexion du client même avec le susdit serveur de contrôle 1 4) comme conséquence de la réception de la réponse même. 4. Appareillage selon Furie des revendications 2 ou 3, caractérisé en ce que le susdit dispositif dédié (12) comporte des moyens de calcul et de communication (Y), qui calculent et fournissent en outre, comme réponse, au susdit serveur d'application (11) un code d'authentification (ALith(D(Req ). 5. Appareillage selon Furie des revendications 2 ou 3, caractérisé en ce que le susdit dispositif dédié (12) comporte des moyens de calcul (Z2) et de mémoire (ZI), qui calculent et mémorisent des informations I(R) dérivées de l'ensemble R des susdites descriptions des requêtes reçues par le susdit serveur d'application (l 1). comportant un code d'authentification (le l'ensemble RC des requêtes Req pour lesquelles un bit B=l a été fourni en réponse au même serveur d'application. 6. Appareillage selon la revendication 5, caractérisé en ce que le susdit dispositif dédié (12) comporte des moyens de traitement (Z2) et de mémoire (ZI), qui traitent et mémorisent les susdites informations dérivées I(R), comportant des statistiques calculées sur la base des descriptions des requêtes reçues par le susdit sen-eur d'application (l 1). 7. Appareillage selon la revendication 5, caractérisé en ce que le 1 susdit dispositif dédié (12) comporte des moyens de traitement (Z2) et de 1 mémoire (ZI), qui traitent et mémorisent les susdites informations dérivées I(R), comportant un code de hash calculé sur la base des descriptions des requêtes reçues par le susdit sen-eur d'application (11). 8. Appareillage selon l'une des revendications 6 ou 7, caractérisé cri ce qu'il comporte des moyens (A) pour transmettre sous forme atithentifiée les susdites informations I(R) au susdit sen,-eur de contrôle (14). 9. Appareillage selon une ou plus des revendications précédentes, caractérisé en ce que le susdit dispositif dédié ( 12) est scellé et que le sceau a des caractéristiques de "tamper-evidence" ou "tamper- résistance", ou bien il est "tamper-responding", de sorte que Vouverture non autorisée du dispositif même, reste visible ou en compromet le fonctionnement successif. 10. Méthode pour la vérification de fichiers de log et/ou des statistiques d'accès à un serveur d'application (11), tel un serveur Web, sous contrôle, réalisé en utilisant l#appareillaLYe selon une ou plusieurs des revendications de 1 à 9, caractérisée en ce qu'elle comporte les phases opérationnelles suivantes : - traitement de l'ensemble R des requêtes envoyées par chaque client (13) au susdit serveur d'application (11) au travers d'un dispositif dédié (12) connecté au susdit serveur d'application (11) et comportant des moyens (Y) de calcul et de communication avec le susdit serveur d'application (11), au travers desquels le susdit dispositif dédié (12) reçoit une description D(Req) clé chaque requête Req provenant par un client (13) quelconque, connecté au susdit serveur d'application (11) et fournit à celui-ci, en réponse à la susdite description de la requête D(Req), un bit (B). qui vaut alternativement 0 ou 1 ; - le susdit serveur d'application (]. 1) envoie à une organisation d'authentification comportant un serveur Web de contrôle (14), une description d'un sous-ensemble (RC) des requêtes (R) envoyées par les clients (13) au serveur d'application nième (11) et correspondant aux requêtes pour lesquelles le susdit dispositif dédié (12), après avoir reçu la description correspondante par le susdit sen-eur d'application (11), a fourni à celui-ci en réponse un bit B=1 , - envoi à la susdite organisation d'authentification (14) des informations I(R) dérivées des susdites requêtes (R). reçues par le susdit serveur d'application (11) ; - vérification par la susdite organisation d'authentification (14) de l'authenticité et de l'exactitude des susdites informations (I(R reçues , - vérificiation par la susdite organisation d'authentification (14) de Vauthenticité et de l'exactitude du susdit sous-ensemble (RC) de requêtes reçues, visant à déterminer qu'à l'intérieur de RC, soient comprises toutes et seulement les requêtes pour lesquelles le susdit dispositif dédié (12) a foumi en réponse au susdit serveur d'application (11) un bit B=1 ; - Vérification par la susdite organisation d'authentification (14) de la correspondance du susdit sous-ensemble de requêtes (RC) avec les requêtes des clients (13) mêmes, reçues par la susdite organisation d'authentification (14), au moins pour la majeure partie des requêtes comprises à l'intérieur de RC ; (le sorte que, sur la base des résultats des phases précédentes, la susdite organisation d'authentification (14) émette l'authentification des accès au susdit serveur d'application (l 1), avec référence aux susdites informations (I(R dérivées des requêtes (R) reçues par le serveur même, si toutes les susdites phases de vérification ont un résultat positif. 11. Méthode selon la revendication 10, réalisée en utilisant l'appareillage selon la revendication 4, caractérisée en ce que les susdites informations (I(R , dérivées des requêtes (R) reçues par le serveur d'application (11), comportent une description D(Req) de chaque requête par un code Req appartenant à R, chacune étant accompagnée d'authentification Auth(Req), calculé par les mo-yens de calcul et de communication M du susdit dispositif dédié (12), et en ce que l'authenti fi cation fait référence à l'ensemble des descriptions des susdites requêtes (R). 12. Méthode selon la revendication 10, réalisée en utilisant l'appareillage selon la revendication 4, caractérisée en ce que les susdites informations (I(R dérivées des susdites requêtes (R) reçues par le susdit serveur d'application (11), sont mémorisées dans des moyens de mémoire (ZI) du susdit dispositif dédié (12), et en ce que l'authentification fait référence aux susdites informations (I(R . 13. Méthode selon la revendication 12, caractérisée en ce que les susdites informations (I(R mémorisées dans les susdits moyens de Mémoire (ZI) du susdit dispositif dédié (12). comportent des statistiques calculées sur la base des susdites requêtes (R), reçues par le susdit serveur d'application (l 1). 14. Méthode selon la revendication 12, caractérisée en ce que les susdites informations (I(R mémorisées dans les susdits moyens de i-nénioire (ZI) du susdit dispositif dédié (12), comportent un code de hash calculé sur la base des susdites requêtes (R), reçues par le susdit serveur d'application (11). et en ce que le susdit code de hash certifié est ensuite comparé avec les susdites requêtes R pour en démontrer l'exactitude.