FR 2828354 A1 20030207 FR 0110220 A 20010731 Le secteur technique de la présente invention est celui des systèmes d'échange d'informations sécurisées en temps réel sur Internet. Pour plus de clarté, on définira la notion de système sur Internet de la manière suivante. Il s'agit d'un moyen constitué d'un ordinateur relié au réseau Internet capable de recevoir et de traiter des demandes d'informations spécifiques, dénommé ci-après serveur, d'un ensemble d'ordinateurs reliés par le réseau au serveur, effectuant ces demandes et traitant les réponses dénommées les clients, et un support physique permettant le transfert des données numériques des clients au serveur dénommé ci-après le réseau Internet. La notion de temps réel doit être comprise de la manière suivante. Un traitement en temps réel s'entend de l'ensemble des traitements effectués dynamiquement dès réception du phénomène déclencheur en opposition à la notion de regroupement d'instructions pour traitement ultérieur. Actuellement les systèmes d'échange d'informations sont principalement sensibles à trois types d'actions malveillantes. La saturation : ce sont des attaques visant à saturer les serveurs jusqu'à cessation forcée de leur activité (sabotage). L'interception : A partir d'une interception/analyse/ interprétation, les attaquants peuvent reproduire une séquence logique induisant des actions logiques de comportements injustifiés, aussi bien au niveau du client que du serveur (espionnage). L'usurpation : Les usurpations d'identité permettent à des acteurs malveillants d'effectuer des opérations en lieu et place d'un autre acteur (vol). Des exemples récents dans l'actualité sont venus semer le trouble dans la solidité et la fiabilité des systèmes mis en place. Le but de la présente invention est de fournir un système interactif d'échange d'informations apte à éliminer les actions d'attaques par saturation et les actions d'attaques par interception de données, évoquées ci-dessus. Les usurpations d'identité, sous la responsabilité stricte du client, ne sont pas traitées par cette invention. L'invention a donc pour objet un système interactif permettant à un client d'émettre des informations et d'en recevoir au cours d'opérations de dialogue en temps réel avec le serveur, sans risque d'interception valide et sans que le serveur ne puisse être arrêté par une tentative de sabotage de type saturation. La présente invention est basée sur l'utilisation du protocole UDP ou équivalent de la couche IP, ayant pour caractéristique l'envoi d'un message court entre deux stations, ne nécessitant pas de connexion continue entre les deux postes. L'ensemble des informations nécessaires est contenu dans un seul paquet binaire et ne peut être segmenté. L'invention concerne donc un système interactif permettant à un client d'émettre des informations et d'en recevoir au cours d'opérations de dialogue en temps réel avec au moins un interlocuteur par l'intermédiaire de ports de communication, caractérisé en ce qu'il comprend : - 2 à n serveurs logiques d'acquisition (SLAC) d'un message sous forme de séquence binaire, n étant un nombre compris entre 2 et 32000 incorporant un ensemble de contrôleurs logiques d'une séquence binaire reçue, d'un contrôleur décodeur (CD), d'un contrôleur de formalisme (CF), et d'un contrôleur client (CC), - un superviseur de message (SM) auquel les serveurs logiques (SLAC) sont reliés, apte à vérifier l'ordre séquentiel des messages, - 1 à n superviseurs spécialisés (SSS) capables d'effectuer une gamme d'instructions dans le cadre d'une activité spécifiques, telle la vente aux enchères, un système de réservation, ou des ventes dégressives, - 1 à n superviseurs génériques (SGR) capables d'effectuer une large gamme d'instruction dans le cadre de services programmés en temps réel, - un superviseur client (SC) dont le rôle est de vérifier la cohérence et la confidentialité des informations émises ou reçues par rapport aux stratégies fixées avec le client, - un serveur logique d'émission (SLEM) apte à protéger les messages en accord avec les normes fixées par le superviseur client (SC) et le rendre interprétable par ce dernier. Avantageusement, le serveur logique d'acquisition (SLAC) est configuré pour écouter un port sélectionné de manière aléatoire. Avantageusement encore, le contrôleur de décodage (CD) assure la transformation d'un message binaire par décompression en séquence compréhensible par l'ensemble des serveurs. Avantageusement encore, pour éviter une interception une combinaison des ports de communication et des clés de cryptage entre le client et le serveur. Avantageusement encore, pour éviter une saturation une analyse formelle et logique du message transmis par les serveurs logiques d'acquisition (SLAC) est réalisée. Avantageusement encore, le superviseur de message (SM) est relié à un contrôleur de message (CM) lors d'une détection d'anomalie. Avantageusement encore, le serveur logique d'émission (SLEM) est connecté à un superviseur de message émis suivi d'un contrôleur codeur et d'un serveur de sortie. Avantageusement encore, les informations reçues par le serveur d'acquisition logique sont traitées uniquement par paquet binaire de taille fixe. Les SLAC sont configurés pour écouter sur un port sélectionné de manière aléatoire, parmi une fourchette prédéterminée de ports disponibles dans le cadre de la stratégie spécifique implémentée. Le contrôleur de décodage transforme le message binaire reçu en séquence compréhensible par l'ensemble des autres automates du système. Ce décodage est réalisé en utilisant des stratégies cycliques clients pré-déterminées. On entend par stratégies cycliques clients un ensemble de clés de chiffrement de taille limitée dans le cadre de la législation spécifique, associée à des ports de communication déterminés de manière aléatoire parmi un ensemble possible pour un client donné. Chaque message transmis utilise un couple clé/port de communication unique, le nombre de possibilité étant déterminé par l'utilisateur du système en fonction du niveau de sûreté désiré de ce système. Avec l'ensemble des combinaisons utilisées, le superviseur client (SC) communiquera à ce dernier une séquence de réinitialisation l'informant de l'indice de la prochaine séquence. Le chiffrement est toujours effectué au-dessus d'une information compressée par un algorithme non standard. Le formalisme de cette séquence est étudié par le contrôleur de formalisme (CF) afin de déterminer l'origine du message et des droits qui y sont associés. Le contrôleur client (CC) est chargé de vérifier la pertinence de l'action envisagée par rapport aux droits spécifiques du client. Le message n'ayant pas été éliminé suite à une anomalie de constitution ou une tentative d'infraction, il est transmis au superviseur de message (SM). Le superviseur de message (SM) va vérifier l'ordre séquentiel du message et le transmettre au contrôleur de message (CM) en cas d'anomalie dans le cadre de la séquence de transmission. Le contrôleur de message (CM) se chargeant de contacter le client pour lui redemander l'envoi d'un message manquant. Le message étant pertinent, le contrôleur de message (CM) va déterminer le service concerné, et le transférer au superviseur concerné (superviseur générique SGR ou superviseur spécialisé SSS). Dans le cadre d'une application de traitement d'ordres boursiers en temps réel, le superviseur de messages (SM) transmet les informations reçues à un superviseur spécialisé (SSS) dans le traitement boursier, lui-même relié à des contrôleurs de flux temps réel, des bases de données clients, des serveurs bancaires, etc... Les avantages du système dans le cadre d'attaques de type INTERCEPTION résident dans la combinaison cyclique des ports de communication et des clés de cryptage entre le client et le serveur. La combinaison port de communication et clé de cryptage utilisée n'est pas déterministe. Elle est générée de manière aléatoire par le client lors de la génération du message. Le contrôleur décodeur est capable de l'interpréter suite à une référence et à une stratégie spécifique à un client donné. L'organisation physique des données n'est jamais identique d'un message à l'autre et varie de manière aléatoire au cours d'une même cession. Aucune information n'est transmise en clair. Les informations transmises bénéficient d'une quintuple protection caractérisée par : - un port de communication non déterministe, - une clé de cryptage choisie, pour un client donné, parmi n qui lui sont attribuées, - une réorganisation interne des bits, - une réorganisation physique des données logiques, - une compression avant cryptage, Ce quintuple niveau de protection garantit une"presque parfaite inviolabilité". Sachant qu'il n'existe pas de code inviolable, ce système permet de garantir qu'un code percé, ne peut l'être que dans le cadre d'un seul message et ceci pendant quelques millisecondes et que l'effort en terme de puissance de calcul et de délai fourni pour le trouver est toujours infiniment supérieur à son délai de validité. Sur le plan de la protection logique, il existe un dernier niveau de protection utilisé qui consiste à ne transmettre que du code compilé seulement compréhensible par des automates d'exécution génériques ou spécialisés, ce qui interdit l'utilisation d'automates de décryptage. Les avantages du système dans le cadre d'attaques de type"SATURATION"réside dans un système de protection par élimination directe. Quelle que soit la nature de la transaction et la typologie du SLAC concerné, chaque message est analysé, de manière formelle et de manière logique. L'absence de reconnaissance de signature ou toutes autres anomalies de formalisme et/ou de logique contenues dans le message transmis implique un non-traitementt dudit message. La connexion permanente n'étant pas établie avec le client, les phases de déconnexion et d'identification empêche toute forme de pénalisation par ce genre de procéder d'attaque. Le système selon l'invention se caractérise donc par plusieurs niveaux de protection utilisant la combinaison cyclique des ports de communication et des clés de cryptage entre le client et le serveur sur des couches directement liées à IP suivant des protocoles de type UDP sans protocole de connexion et déconnexion afin d'interdire toute attaque par saturation et toute attaque par interception et d'assurer le traitement des informations à très haute vitesse. Les superviseurs logiques SLAC sont conçus pour traiter les ordres reçus sans avoir à passer par la phase de connexion et de déconnexion de protocoles plus évolués, il est en outre chargé du filtre et de la répartition des messages. D'autres caractéristiques, détails et avantages de l'invention ressortiront plus clairement de la description donnée ci-après à titre indicatif en relation avec la figure 1 unique qui illustre le synoptique d'organisation générale du système. Les serveurs logiques d'acquisition (SLAC) sont exclusivement conçus pour recevoir des messages sur un port d'écoute spécifique par l'intermédiaire duquel les clients communiquent. Ils sont incapables d'émettre. A la réception d'un message, le SLAC réalise : - une mise en liste de traitement du message (pile du type FIFO), - une détermination de l'identifiant client afin d'en déterminer la validité par un accès à la base de données clients locale, Le client déterminé, le SLAC recherche l'index de la clé utilisée pour le codage du message. Cette clé fait partie de la liste des clés possibles utilisable par un client donné. L'index de la clé déterminé, il en vérifie la cohérence. Si l'index de clé est plausible un décodage du message est effectué par un contrôleur décodeur (CD). Le décodage du message étant effectué, une décompression de la séquence binaire résultante est alors réalisée. La signature du message devient alors lisible. Le message est automatiquement détruit si l'identifiant client, l'index de clé, la séquence binaire n'est pas décompressible ou la signature du message, ou le formalisme sont invalides. L'étape suivante consiste à vérifier à l'aide d'un contrôleur de formalisme (CF) la structure du message, formalisme du compilé, complément cohérent pour les instructions, paramètres pertinents, etc... En cas d'incohérence, le message est éliminé. Une dernière étape de validation du message consiste à vérifier l'existence des services requis et des instructions spécifiées par rapport aux services à activer à l'aide d'un contrôleur client (CC). Le message étant pertinent, une vérification d'ordre chronologique est alors effectuée, chaque message de chaque client étant numéroté. Dans le cas de l'arrivée d'un message hors séquence, il est transféré à un superviseur de message (SM) qui se chargera soit d'attendre, soit de demander un duplicata au client. Le message étant chronologiquement et logiquement validé, il est envoyé à un superviseur de messages (SM) qui le dirigera vers un superviseur du service (SSS ou SGR) à activer. Les superviseurs peuvent recevoir deux types de messages soit des demandes de validation de la qualité du message reçu (superviseur spécialisé SSS) soit des ordres d'exécution (superviseur générique routeur SGR). A la réception d'une demande de validation, le superviseur spécialisé SSS va vérifier l'existence du service à solliciter et de l'instruction à exécuter. En cas d'anomalie, une invalidation du message a alors lieu. Si le message est considéré comme potentiellement valide, le superviseur SSS va effectuer. la qualification de ses compléments. Si les compléments sont plausibles et normés, le message est alors accepté. A la réception d'un ordre d'exécution, le message reçu est alors empilé dans une pile de type FILO jusqu'au transfert au service de destination. Si ledit service n'est pas en activité, il est alors activé. L'instruction lui est ensuite transmise et elle sera empilée localement jusqu'à exécution. Le résultat de l'exécution, s'il existe, sera transmis au serveur logique d'émission (SLEM) pour envoi au client. Le superviseur générique SGR est configuré suivant les principes exposés pour le SSS et le résultat de l'exécution, s'il existe, sera transmis au serveur logique d'émission (SLEM) pour envoi au client comme expliqué précédemment. Le superviseur client (SC) est relié au superviseur SM et à un serveur client et, outre ses nombreuses fonctionnalités de gestion des données du client qu'il assure, est conçu pour répondre aux sollicitations suivantes : - réception d'une demande de validation du numéro client (une anomalie est générée dans le cas de l'inexistence dudit client), - réception d'une demande de validation d'index. Pour un client donné, on vérifie que la clé de décryptage référencée par l'index existe. Dans ce cas, la clé est renvoyée et dans le cas contraire une anomalie est générée. - réception d'une demande de séquence d'un message, le numéro du possible prochain message est alors renvoyé, - réception d'une demande d'incrément de message après qu'un message reçu ait été traité, - réception d'un ordre de création d'un nouveau client. Lors de cette opération, les stratégies de cryptage sont alors déterminées ainsi que les possibles ports d'écoute et d'émission. Ces informations sont alors transmises au client via le serveur logique d'émission (SLEM). Le serveur SLEM permet d'envoyer au client des messages en respectant les protocoles de protection en vigueur. Après identification du client et détermination de la prochaine clé à utiliser, le message est alors compressé et crypté puis mis en liste d'attente pour envoi au superviseur de messages émis. REVENDICATIONS 1. Système interactif permettant à un client d'émettre des informations et d'en recevoir au cours d'opérations de dialogue en temps réel avec au moins un interlocuteur par l'intermédiaire de ports de communication, caractérisé en ce qu'il comprend : - 2 à n serveurs logiques d'acquisition (SLAC) d'un message sous forme de séquence binaire, n étant un nombre compris entre 2 et 32000 incorporant un ensemble de contrôleurs logiques d'une séquence binaire reçue, d'un contrôleur décodeur (CD), d'un contrôleur de formalisme (CF), et d'un contrôleur client (CC), - un superviseur de message (SM) auquel les serveurs logiques (SLAC) sont reliés, apte à vérifier l'ordre séquentiel des messages, - 1 à n superviseurs spécialisés (SSS) capables d'effectuer une gamme d'instructions dans le cadre d'une activité spécifiques, telle la vente aux enchères, un système de réservation, ou des ventes dégressives, - 1 à n superviseurs génériques (SGR) capables d'effectuer une large gamme d'instruction dans le cadre de services programmés en temps réel, - un superviseur client (SC) dont le rôle est de vérifier la cohérence et la confidentialité des informations émises ou reçues par rapport aux stratégies fixées avec le client, - un serveur logique d'émission (SLEM) apte à protéger les messages en accord avec les normes fixées par le superviseur client (SC) et le rendre interprétable par ce dernier. 2. Système interactif selon la revendication 1, caractérisé en ce que le serveur logique d'acquisition (SLAC) est configuré pour écouter un port sélectionné de manière aléatoire. 3. Système interactif selon la revendication 1 ou 2, caractérisé en ce que le contrôleur de décodage (CD) assure la transformation d'un message binaire par décompression en séquence compréhensible par l'ensemble des serveurs. 4. Système interactif selon la revendication 3, caractérisé en ce que, pour éviter une interception, les serveurs logiques (SLAC) réalisent une combinaison des ports de communication et des clés de cryptage entre le client et le serveur. 5. Système interactif selon la revendication 4, caractérisé en ce que, pour éviter une saturation, une analyse formelle et logique du message transmis par les serveurs logiques d'acquisition (SLAC) est réalisée. 6. Système interactif selon l'une quelconque des revendications précédentes, caractérisé en ce que le superviseur de message (SM) est relié à un contrôleur de message (CM) lors d'une détection d'anomalie. 7. Système interactif selon l'une quelconque des revendications précédentes, caractérisé en ce que le serveur logique d'émission (SLEM) est connecté à un superviseur de message émis suivi d'un contrôleur codeur et d'un serveur de sortie. 8. Système interactif selon l'une quelconque des revendications précédentes, caractérisé en ce que les informations reçues par le serveur d'acquisition logique sont traitées uniquement par paquet binaire de taille fixe.