Brevet FR2799078A1 — publié le 20010330

Description La présente invention concerne un ensemble de protocoles intégrant une authentification rapide pour des systèmes transactionnels ouverts de commerce d'information et de services sur Internet. L'objectif est d'apporter un système très sécurisé, adapté à l'achat en masse d'informations et de services multimédia. La solution est ouverte (capable de se coupler à des applications larges et d'autres systèmes de paiement). Les systèmes usuels de commerce d'information emploient soit des protocoles basés sur l'usage de monnaie virtuelle (pièces électroniques), soit des protocoles transactionnels mettant enjeu un ou plusieurs intermédiaires en plus du vendeur et du client. Ces derniers présentent un ou plusieurs des défauts suivants - protocoles d'échanges fortement sécurisés pour le paiement par carte bancaire, peu adaptés au trafic de masse du micro-paiement - usage d'un mode porte-monnaie électronique, permettant de réaliser des paiements groupés par agrégation avec un approvisionnement anticipé, ce qui contraint l'intermédiaire au statut d'organisme de crédit - usage de la liaison naturelle réseau-télécom ou du service d'accès Internet, déterminant un intermédiaire privilégié, ce qui permet d'intégrer les paiements agrégés dans une facturation pré existante avec cet intermédiaire, mais ferme le service aux clients de l'intermédiaire ; en général les services alors proposés sont spécifiques de l'intermédiaire. Le système proposé ici est caractérisé par trois éléments 1. Le protocole fonctionnel (dénommé "Commerce-Proxy") Il s'agit d'un protocole transactionnel (figure 1), mettant enjeu un terminal client, un serveur de données et un serveur intermédiaire. Il est très simple mécaniquement et adapté au micro-paiement d'immatériel sur Internet (information ou service). Il est caractérisé par - un échange triparties d'achat d'une paire (ticket /clé) (1/1) et (2/1) client -> intermédiaire> vendeur -> intermédiaire -> client cet échange permet au client d'obtenir auprès du vendeur, un ticket d'accès T et une clé de chiffrement K, déclenchant l'enregistrement de la transaction à travers l'intermédiaire - un échange biparties de transfert de données (3/1) et (4/1): client -> vendeur de données> client où le client fournit son ticket et reçoit en retour des données éventuellement chiffrées avec la clé K fournie par le vendeur. L'exploitation de l'information se fait après la réalisation des deux échanges précédents. Leur ordre peut être quelconque (enregistrement de la transaction avant ou près la récupération effective des données). Les requêtes (1/1) et (2/1) sont signées pour être authentiques et le ticket est garant de la validité la requête (3/1). Ce schéma peut être utilisé pour l'achat à la durée, en itération. Pour un schéma à la durée, chaque tronçon de flux est codé avec une clé achetée par une transaction de base selon une séquence indicée. Chaque bloc de données transmis est codé et précédé de l'indice de la clé. Le terminal client anticipe l'achat d'un ticket à l'avance de manière à basculer sur la nouvelle clé dès que l'indice d'un nouveau bloc est transmis par le serveur de donnée. La durée d'une section codée doit être supérieure au transfert d'une clé pour permettre l'anticipation. En outre le système d'authentification possède la flexibilité à évoluer vers d'autres protocoles transactionnels comme le paiement indirect (ex : imputation d'un annonceur lorsque qu'un visiteur anonyme visualise une bannière publicitaire sur un site publiant des annonces, comme les portails Internet). 2. Le protocole de signatures légères Il s'agit d'un protocole d'authentification et accessoirement de chiffrement, adapté aux transactions de faibles montants. Il combine des échanges chiffrés de manière robuste avec un algorithme à clés publiques (type RSA ou elliptique) et des échanges signés avec des clés de cycle. La procédure d'utilisation est la suivante (dans l'ordre A, B, C, D) A. Les trois composants système (serveur intermédiaire, serveur de données et terminal client) doivent être initialisés en générant à l'aide d'un programme local à chacun une paire de clés publique /privée. B. Le serveur de données, le terminal client et le serveur intermédiaire s'échangent leur clé publique C. Les échanges entre le serveur intermédiaire et un serveur de données ou un terminal client fonctionnent suivant un cycle de longueur fixe : au départ du cycle le serveur intermédiaire génère une clé de cycle et la diffuse au système opposé ; cette clé est utilisée pour générer une séquence de clés (dites clés de séquence de cycle) en nombre égal à la longueur du cycle, en lui appliquant une transformation pseudo-aléatoire ; chaque clé de séquence de cycle est ensuite utilisée comme clé de chiffrement symétrique pour chiffrer le résultat de hachage d'un message ; en version de message chiffrée, cette clé sert aussi à chiffrer tout le message. A chaque échange, l'indice de la séquence est transmis en clair et complète les données à signer pour éviter les réplications de messages ; chaque message transmis dans un sens ou dans l'autre consomme un indice de la séquence ; en cas de perte de message provoquant une désynchronisation des indices de clés de cycle, le correspondant détectant un indice de clé inférieur à son indice courant retourne son indice actuel ; si l'indice reçu est supérieur à son indice courant il l'utilise comme nouvel indice courant ce qui resynchronise les échanges automatiquement. D. Lorsque le cycle atteint son dernier message, une nouvelle clé de cycle est produite et diffusée par le serveur intermédiaire groupé dans le message de requête ou de réponse vers le système opposé puis le cycle reprend comme en C. Le stockage de la clé privée, côté terminal client, est assurée par un mot de passe choisi par l'utilisateur. Sur les serveurs le mot de passe est généré à la compilation des programmes (il peut être produit pseudo-aléatoirement) et copié en dur dans le programme. II n'est pas accessible simplement par les administrateurs des serveurs. 3. Le tunnel HTTP sécurisé Le système s'appuie en outre sur un tonnelage des messages sur HTTP permettant la fois - de traverser les "pare-feux" réseau (programmés de manière courante pour laisser passer le protocole HTTP) - de réaliser de manière flexible les protocoles fonctionnels et de signatures légères décrits précédemment, pour les systèmes à haute fréquentation. La mise en oeuvre du tonnelage s'appuie sur la structuration des messages au format XML où l'on attache des balises particulières de chiffrement ou de signature. Ce tonnelage est réalisable, soit de serveur à serveur par un module de formattage/déformattage sécurisé (figure 2 éléments 511 et 6I1) ou de serveur à terminal client par un module d'extension de navigateur côté terminal client et un module formattage/déformattage côté serveur (figure 3 éléments 8I1 et 9/1). Le protocole de Commerce-proxy s'applique dans tous les systèmes qui nécessitent d'enregistrer des transactions en masse. L'application majeure est le micro-paiement sur Internet (achat d'information multimédia ou de services). Le protocole du "Commerce-Proxy" est réalisé dans un système de micro-paiement avec un protocole de signatures légères utilisant - un cycle de longueur paramétrable, - l'algorithme de sécurité triple-DES pour la génération des clés de session, - l'algorithme de sécurité RSA pour le chiffrement et la signature du transport de clé de cycle, - l'algorithme de sécurité MD5 pour le "hachage" à la fois des messages de clés de cycle et des signatures légères. Ce système fonctionne sur machines de type ordinateur de bureau équipés comme suit 1. Pour le serveur intermédiaire et le serveur de données sur système d'exploitation multitâches multi- utilisateurs, équipé - d'un serveur HTTP - d'une bibliothèque de sécurité (chiffrement, signature, hachage) existante - de bibliothèques XML en langages Perl et en C 2. Pour le terminal client sur système d'exploitation équipé - d'un navigateur Web - d'un module d'extension pour navigateur réalisant le tunnel sécurisé vers le serveur intermédiaire pour l'achat de ticket et vers le serveur de données pour la récupération des contenus. Le tunnel a été réalisé à partir d'une bibliothèque existante pour la production générique de l'analyseur XML. Revendications (R1) Dispositif d'authentification et de signature électronique sur Internet à travers un intermédiaire, applicable au commerce électronique d'information et de services, caractérisé en ce qu'il comporte un protocole défini par les étapes suivantes - acquisition d'un ticket et d'une clé auprès de serveurs de données à travers l'intermédiaire de confiance en utilisant un service de relais HTTP (dénommé "Commerce-Proxy") - commande de l'information par le ticket - réception codée par la clé achetée, pour traiter un échange unitaire (applicable pour achat à l'acte). (R2) Dispositif selon la revendication 1, caractérisé en ce qu'il comporte un protocole d'échanges signés de manière légère, entre le serveur intermédiaire et les serveurs de données et les clients caractérisé par l'échange d'une séquence de clés de manière très sure puis l'utilisation des cette séquence pour la signature (et éventuellement le chiffrement) des messages au cours du cycle. (R3) Dispositif selon les revendications 1 et 2, caractérisé en ce qu'il comporte un protocole d'échange itératif applicable pour l'achat à la durée. (R4) Dispositif selon la revendication 1, caractérisé en ce qu'il comporte un protocole d'encapsulation sur le protocole HTTP, sur l'usage du format XML, permettant de transporter des messages signés et optionnellement chiffrés de manière spécifique, de manière à être transparent aux dispositifs pare-feu entre les clients et les serveurs et entre les serveurs intermédiaires et les serveurs de données (dénommé tunnel HTTPIXML sécurisé) et d'introduire les signatures légères selon la revendication 2.