FR 2623309 A1 19890519 FR 8715718 A 19871113 Dispositif et procédé de sécurisation d'échange de données entre un terminal vidéotex et un serveur. L'invention concerne la sécurisation d'échange de données entre un terminal vidéotex et un serveur. Ces données con- cernent aussi bien le contrôle de l'accès au serveur que des messages transmis une fois la session établie. L'inven- tion s'applique à tous les terminaux vidéotex, notamment mais non exclusivement à ceux désignés sous la dénomination française "Minitel". Pour contrôler les accès aux systèmes télématiques, qui sont confrontés aux mêmes problèmes que les systèmes télé- informatiques, trois méthodes peuvent être utilisées. Une première méthode repose sur la reconnaissance d'un élément connu de l'utilisateur, généralement un mot de passe. Cepen- dant, ce mot de passe est très vulnérable aux écoutes et aucun terminal classique n'offre de protection contre cette menace. Une deuxième méthode repose sur la reconnaissan- ce d'un élément au sujet de cet individu, comme par exemple une caractéristique biométrique (voix, empreinte digitale). Cependant, si de telles méthodes paraissent très intéressan- tes, elles n'ont été l'objet d'aucune utilisation jusqu'à ce jour pour des raisons techniques et économiques. Une troisième méthode enfin repose sur la reconnaissance d'un élément possédé par l'individu. Dans cette catégorie, les cartes à microprocesseur et les dispositifs d'authentifica- tion semblent être les outils les plus fiables, puisqu'ils mettent en oeuvre un algorithme de calcul secret qui permet de les authentifier en toute certitude. Toutefois, ces sys- tèmes ne semblent pas rencontrer le succès attendu, pour des raisons économiques. La carte à microprocesseur, à vocation multi-services, néces- site la mise en oeuvre de matériels qui peuvent être jugés lourds et coûteux dans le cadre du seul contrôle d'accès logique. En effet, cette technique nécessite des lecteurs de cartes connectés aux terminaux vidéotex pour les cartes des usagers, des processeurs de sécurité pour les cartes du serveur, et enfin un logiciel de dialogue entre un couple (lecteur-carte) d'un côté et un couple (processeur de sécu- rité-carte) de l'autre côté. Les dispositifs d'authentification permettent de diminuer le coût du contrôle d'accès logique mais nécessitent l'em- ploi d'afficheurs et de claviers ou de capteurs optiques. De plus, l'absence de connexion avec le terminal vidéotex oblige l'usager à jouer le rôle d'interface entre le dispo- sitif d'authentification et le terminal. D'autre part, ces dispositifs utilisent généralement une alimentation électri- que autonome, ce qui complique encore leur utilisation. La présente invention remédie à ces inconvénients en propo- sant de sécuriser le contrôle d'accès à un serveur par l'au- thentification du terminal vidéotex et de sécuriser des messages, échangés lors de la session entre le serveur et le terminal vidéotex grâce à un dispositif simple à mettre en oeuvre, ne nécessitant aucune adaptation matérielle ni du terminal ni du serveur et aussi peu coûteux que possible. L'invention a également pour but de déconnecter le terminal vidéotex et le serveur en cas de tentative de modification des données véhiculées sur la ligne de transmission. Un autre but de l'invention est d'utiliser un boîtier addi- tionnel portable directement enfichable sur la prise péri- informatique du terminal vidéotex sans alimentation autonome. Un autre but de l'invention est de permettre, lors de la session, de sécuriser par chiffrement ou par signature le transport des messages entre ce serveur et le terminal vidéo- tex, afin de garantir la confidentialité et/ou l'intégrité de ces messages. L'invention a encore pour but d'obtenir un dispositif dont les caractéristiques permettent d'envisager le développement d'applications télématiques pouvant toucher un public très large (eu égard au coût), tout en personnalisant la presta- tion. L'invention a donc pour objet un dispositif de sécurisation d'échange de données entre, d'une part, un terminal vidéotex, possédant un organe de gestion d'aiguillage entre un interfa- ce ligne, un clavier, un écran et une prise aval dite péri- informatique, et, d'autre part, un serveur, à l'aide d'un boîtier additionnel propre à être connecté sur la prise péri-informatique du terminal vidéotex, caractérisé en ce que le boîtier comprend des premiers moyens de chiffrement/ déchiffrement et des premiers moyens de dialogue tandis que le serveur comprend des seconds moyens de chiffrement/ déchiffrement et des seconds moyens de dialogue, les premiers et seconds moyens de dialogue coopérant pour permettre ledit échange de données, et en ce que le boîtier possède un mode de pré-session dans lequel: - il agit sur l'organe d'aiguillage du terminal vidéotex en surveillant toute autre action sur cet organe d'aiguillage, - les premiers et seconds moyens de chiffrement/déchiffre- ment opèrent à l'aide d'une clé de base prédéterminée, - les premiers et seconds moyens de dialogue entament une suite prédéterminée d'opérations comportant la définition d'une clé de session transmise chiffrée selon ladite clé de base, - une dite autre action sur l'organe d'aiguillage ou toute anomalie dans l'ordre de ladite suite et/ou dans lé résultat d'une opération entraine l'avortement du mode de pré-session. Avantageusement, la suite prédéterminée d'opérations com- prend la saisie au clavier par l'utilisateur d'un code con- fidentiel, le boîtier agissant sur l'organe d'aiguillage pour interdire la liaison entre l'interface ligne et le clavier. La clé de session peut être générée à partir d'au moins un premier nombre aléatoire et comprend de préférence une première clé primaire générée par les seconds moyens de dialogue du serveur. Avantageusement, la suite prédéterminée d'opérations comprend l'envoi par le serveur vers le boîtier par l'intermédiaire du terminal vidéotex de la première clé primaire. Dans un mode préféré de réalisation, le boîtier comprend des premiers moyens de mémorisation, tandis que le serveur comprend des seconds moyens de mémorisation, les deux moyens de mémorisation contenant au moins une partie de ladite clé de base. Avantageusement, les premiers moyens de mémorisation com- prennent des moyens de mémoire morte figée et des moyens de mémoire morte programmable. Les moyens de mémoire morte programmable peuvent comprendre des informations particulières chiffrées par les premiers moyens de chiffrement/déchiffrement à l'aide d'une clé de stockage. De préférence, la clé de stockage est la combinaison au moins d'une clé initiale et d'une clé intermédiaire, la clé initiale étant stockée dans les moyens de mémoire morte figée tandis que la clé intermédiaire est stockée dans les moyens de mémoire morte programmable, chiffrée par les pre- miers moyens de chiffrement/déchiffrement à l'aide de la clé initiale. Dans une première variante de l'invention, ladite clé de base est une clé unique stockée à la fois dans les premiers et seconds moyens de mémorisation. Dans ce cas, la clé de session est avantageusement la combi- naison de la première clé primaire et d'une deuxième clé primaire générée par les premiers moyens de dialogue du boîtier. La deuxième clé primaire peut être générée également à par- tir d'un deuxième nombre aléatoire qui dépend de préférence du temps s'écoulant entre la demande de saisie du code con- fidentiel et la saisie proprement dite au clavier. Dans ce premier mode de réalisation, la suite prédéterminée d'opérations comprend de préférence l'envoi par le boîtier vers le serveur de la deuxième clé primaire et la clé de base est, de préférence, la clé de stockage. Dans une seconde variante de l'invention, la clé de base comprend une clé publique stockée dans les seconds moyens de mémorisation et une clé secrète stockée dans les premiers moyens de mémorisation, les clés publique et secrète étant complémentaires l'une de l'autre. Dans ce cas, la clé de session est avantageusement la pre- mière clé primaire. Selon l'invention, le boîtier additionnel peut comprendre en outre un mode particulier, activé au moins lors de la première mise sous tension du boftier, permettant de stocker dans le boîtier des informations personnalisées. Selon l'invention, le boîtier comprend un premier moyen de visualisation indiquant l'interdiction de la liaison entre l'interface ligne et le clavier, ainsi qu'un deuxième moyen de visualisation indiquant l'établissement de la clé de session. Avantageusement, le boîtier comprend un mode de session dans lequel les premiers et seconds moyens de dialogue coo- pèrent pour permettre l'échange de messages chiffrés ou signés selon la clé de session. D'une manière particulièrement avantageuse, le boîtier est alimenté en énergie par l'alimentation du terminal vidéotex. L'invention a également pour objet un procédé d'échange de données entre, d'une part, un terminal vidéotex, possédant un organe de gestion d'aiguillage entre un interface ligne, un clavier, un écran et une prise aval dite péri-informatique, et, d'autre part,un serveur, à l'aide d'un boîtier additionnel propre à être connecté sur la prise péri-informatique du terminal vidéotex, caractérisé en ce que l'on munit le boîtier et le serveur de premiers moyens de chiffrement/déchiffrement et de seconds moyens de chiffrement/déchiffrement respecti- vement, et en ce que le boîtier possède un mode de pré- session, accessible sur commande, dans lequel il agit sur l'organe d'aiguillage du terminal vidéotex, en ce que, dans ledit mode de présession, les premiers et seconds moyens de chiffrement/déchiffrement opèrent à l'aide d'une clé de base prédéterminée, et en ce que, dans ledit mode de pré-session, le boîtier et le serveur dialoguent par une suite prédéterminée d'opé- rations comportant la définition d'une clé de session trans- mise chiffrée selon ladite clé de base, tandis qu'une dite autre action sur l'organe d'aiguillage ou toute anomalie dans l'ordre de ladite suite et/ou dans le résultat d'une opération entraîne l'avortement du mode de pré-session. D'autres avantages et caractéristiques de l'invention appa- raîtront à la lecture de la description détaillée ci-après et des dessins annexés, sur lesquels: - la figure 1 est un schéma d'un dispositif selon l'inven- tion, - la figure 2 est un schéma d'un mode de réalisation d'un boîtier additionnel du dispositif de la figure 1; - la figure 3 est un synoptique schématique des principaux constituants du boîtier additionnel de la figure 2, - la figure 4 est un organigramme décrivant le début du mode de pré-session du boîtier additionnel selon l'invention, - la figure 5 est un organigramme décrivant une première variante de la fin du mode de présession du boîtier, - la figure 6 est un organigramme décrivant une seconde variante de la fin du mode de pré-session du boîtier, - la figure 7 est un organigramme décrivant une première partie du fonctionnement d'un mode particulier du boîtier selon l'invention, et - la figure 8 est un organigramme décrivant une deuxième partie du fonctionnement du mode particulier du bottier selon l'invention. Les dessins annexés comportant pour l'essentiel des éléments de caractère certain pourront servir non seulement à mieux faire comprendre la description détaillée ci-après mais aussi à la définition de l'invention le cas échéant. Le dispositif selon l'invention représenté sur la figure 1 comprend un serveur SE relié par l'intermédiaire d'une ligne télématique LST à un terminal vidéotex TVX. Dans la suite du texte, le terme "terminal vidéotex" sera remplacé par le terme "terminal". Le terminal TVX comprend de façon classi- que un interface ligne IL, un écran EC, un clavier CL et une prise périinformatique PPI située en aval de la liaison LST. Ces composants du terminal sont gérés par un organe de gestion d'aiguillage AIG contenant le logiciel de proto- cole du terminal. Le dispositif selon l'invention comprend un boîtier additionnel BA connecté à l'aide d'une prise spéciale PS par l'intermédiaire d'une ligne LBT à la prise péri-informatique PPI. Le boîtier BA est donc connecté en aval du terminal par opposition à une connexion en amont du terminal, c'est-à-dire entre l'interface ligne IL et le serveur SE. Le boîtier BA est représenté sous forme schématique sur la figure 2. La dimension de ce boîtier est environ de 8 cm de longueur sur 3 cm de largeur et 2 cm de profondeur. Il comporte deux diodes électroluminescentes LED1 et LED2 agen- cées de telle sorte qu'elles sont visibles par l'utilisateur lorsque le boîtier est enfiché sur la prise péri-informatique par l'intermédiaire de sa prise spéciale PS. Cette prise spéciale PS comprend cinq broches Pl à P5 dont les fonctions seront précisées ci-après. La prise PS permet d'alimenter en énergie le boîtier BA de telle sorte qu'il n'est pas utile de le munir d'une alimentation autonome. Les principaux constituants du boîtier BA sont représentés sur la figure 3. La borne P1 de la prise PS du boîtier BA fournit la tension de polarisation 5 Volts. Elle est reliée à la masse par l'intermédiaire d'un condensateur C2 d'une valeur de 0,1 microfarad et par l'intermédiaire d'un conden- sateur électrochimique Cl d'une valeur de 10 microfarads. La borne P2 de la prise du bottier BA fournit la référence de masse. La prise P5 est également reliée à la masse mais n'est pas représentée sur cette figure. Le boîtier BA comprend des moyens de dialogue MD1 comportant une unité centrale ICl cadencée par une horloge Q1. L'unité centrale IC1 comporte une mémoire vive MV et une mémoire morte MM. Cette mémoire morte MM est une mémoire morte figée, c'est-à-dire non programmable. Cette unité centrale est un microcontrôleur.du type de celui disponible sous la réfé- rence 8051 auprès de la Société des Etats-Unis "INTEL". La fréquence de l'horloge Q1 est de 10 MHz. Les bornes 18, 19 de l'unité centrale IC1 sont reliées aux bornes de l'hor- loge Q1 et respectivement à la masse par l'intermédiaire de deux condensateurs C6 et C7 d'une valeur de 22 picofarads. Les bornes 32 à 39 de' l'unité centrale IC1 sont reliées respectivement aux bornes 8 à 1 d'une mémoire-verrou IC2 ("latch"). Cette mémoire-verrou IC2 est du type de celle disponible sous la référence 8282 auprès de la Société "IN- TEL". Les bornes 1 à 8 de la mémoire-verrou IC2 sont égale- ment reliées à la tension de polarisation 5 Volts par l'in- termédiaire d'un circuit de mise en haute impédance L91 constitué de résistances d'une valeur de 10 kiloohms. La borne 31 de l'unité centrale IC1 est reliée à la tension de polarisation +5 Volts ainsi qu'à la masse à travers un condensateur C4 d'une valeur de 10 nanofarads. La borne de l'unité centrale ICl est reliée à la fois aux bornes 9 et 11 de la mémoire-verrou IC2. La borne 9 de l'unité centrale ICI est reliée à la tension de polarisation par l'intermédiaire d'un condensateur élec- trochimique C3 d'une valeur de 10 microfarads et à la masse par l'intermédiaire d'une résistance Rl (5,6 kiloohms) en parallèle avec une diode D1 du type de celle disponible sous la référence 1N4148 auprès de la Société française "SILEC". Les autres diodes citées dans la suite du texte seront identiques à la diode D1. Les bornes 10 et 11 de l'unité centrale IC1 sont reliées respectivement aux bornes P3 et P4 de la prise de sortie du boîtier BA. La borne P3 constitue la borne d'émission tandis que la borne P4 consti- tue la borne de réception. La borne 10 est reliée à la ten- sion de polarisation par l'intermédiaire d'une résistance R2 de 5,6 kiloohms et d'une diode de sécurité D2. La borne 10 est également reliée à la masse par l'intermédiaire d'une autre diode de sécurité D3. De la même façon, la borne 11 est reliée à la tension de polarisation par l'intermédiaire d'une résistance R3 de 5,6 kiloohms et d'une diode de sécu- rité D4 tandis qu'elle est reliée à la masse par l'intermé- diaire d'une diode de sécurité D5. Le boîtier BA comprend également une mémoire morte program- mable IC3 et un ensemble de portes logiques "ET" IC4. La mémoire IC3 est du type de celle disponible sous la référence 2864 auprès de la Société "INTEL" et l'ensemble IC4 est du type de celui disponible sous la référence 7408 auprès de la Société des Etats-Unis "TEXAS INSTRUMENT". Les bornes 12 à 19 de la mémoire-verrou IC2 sont reliées respectivement aux bornes 3 à 10 de la mémoire IC3. Les bornes 2, 11 à 13, 15 à 19, 21, 23 à 25 de la mémoire IC3 sont reliées respectivement aux bornes 25, 39 à 37, 36 à 32, 23, 24, 22, 21 de l'unité centrale IC1. La borne 28 de la mémoire IC3 est reliée d'une part à la tension de polarisation et, d'autre part, à la masse à travers un condensateur C9 de 10 nanofarads. Les bornes 14 et 27 de la mémoire IC3 sont reliées respectivement à la masse et à la borne 16 de l'unité centrale ICi. L'ensemble de portes logiques IC4 commande la diode électro- luminescente LED1 par l'intermédiaire d'une résistance R4 d'une valeur de 470 ohms reliée à sa borne 6 et la deuxième diode électroluminescente LED2 par l'intermédiaire d'une résistance R5 d'une valeur également de 470 ohms reliée à la borne 8. La diode LED1 est rouge et constitue un premier moyen de visualisation, tandis que la diode LED2 est vert et constitue un deuxième moyen de visualisation. La borne 14 de l'ensemble IC4 est reliée à la tension de polarisation Volts et à la masse à travers un condensateur C8 d'une valeur de 10 nanofarads. Les bornes 1, 2, 7 sont reliées à la masse, les bornes 4 et 5 à la borne 8 de l'unité cen- trale ICl, les bornes 9 et 10 à la borne 7 de l'unité cen- trale IC1 et les bornes 12 et 13 respectivement aux bornes 29 et 17 de l'unité centrale. L'unité centrale IC1 comporte deux algorithmes de chiffre- ment/déchiffrement qui sont pour le premier un algorithme "DES" (DATA ENCRYPTION STANDARD) et pour le second un algo- rithme "RSA" ("RIVEST SHAMIR ADLEMAN"). Ces deux algorithmes de chiffrement font partie de premiers moyens de chiffrement/ déchiffrement pour le boîtier BA. Les algorithmes "DES" et "RSA" sont stockés respectivement dans la mémoire morte MM de l'unité centrale IC1 et dans une partie IC30 de la mémoire IC3. Il est rappelé ici que l'algorithme de chiffrement/déchiffre- ment "DES" fonctionne à partir d'une clé de base KB. Aussi pour que le boîtier BA et le serveur SE puissent dialoguer à l'aide de "DES", est-il nécessaire que la clé KB soit stockée à la fois dans le boîtier BA et dans le serveur SE. L'algorithme "RSA" fonctionne à l'aide d'une clé de base qui est en fait la combinaison de deux clés dépendantes l'une de l'autre, l'une étant une clé publique KBP stockée dans le serveur et l'autre une clé secrète KBS stockée dans le boîtier. La mémoire morte MM de l'unité centrale IC1 comporte en outre la clé de base KB nécessaire pour l'algorithme "DES" et la clé secrète KBS nécessaire pour l'algorithme "RSA". Une autre partie IC31 de cette mémoire IC3 contient, sous forme chiffrée par l'algorithme "DES" à l'aide d'une clé de stockage KST, un code d'authentification I du boîtier BA et un code confidentiel CC propre à un utilisateur donné. La mémoire morte MM, la mémoire vive MV et la mémoire IC3 constituent des premiers moyens de mémorisation pour le boîtier. La partie IC31 de la mémoire IC3 constitue des moyens de mémoire morte programmable pour le boîtier BA. La mémoire morte MM constitue des moyens de mémoire morte figée pour le boîtier BA. Bien entendu, le choix du microcontrôleur ICi n'est pas limitatif. On pourrait par exemple choisir un microcontrôleur du type de celui disponible sous la référence 8052 auprès de la Société "INTEL". Dans ce cas, le code d'authentifica- tion I et le code confidentiel seraient stockés dans une petite mémoire morte programmable externe au microcontrôleur 8052, et le contenu de la partie IC30 ci-avant citée serait regroupé dans la mémoire morte figée du microcontrôleur 8052. De même, on pourrait choisir un microcontrôleur du type de celui disponible sous la référence 68HCll auprès de la Société des Etats-Unis "MOTOROLA". Dans ce cas, il ne serait plus nécessaire d'avoir une mémoire externe pour stocker les codes confidentiels CC et d'authentification I, car ceux-ci seraient mémorisés dans la mémoire morte programmable du microcontrôleur. Le serveur comprend, d'une façon analogue, des seconds mo- yens de dialogue et des seconds moyens de chiffrement/déchif- frement constitués soit par un algorithme "DES" soit par un algorithme "RSA". La clé de base KB de l'algorithme "DES" est également stockée dans des seconds moyens de mémorisa- tion. Ces seconds moyens de mémorisation comprennent égale- ment la clé publique KBP utilisée pour l'algorithme "RSA". Le dispositif selon l'invention ainsi décrit pourra donc soit fonctionner à l'aide d'un algorithme "DES", soit à l'aide d'un algorithme "RSA" selon les besoins, le choix de l'algorithme pouvant se faire à l'aide d'une information contenue dans le code d'authentification I. Le fonctionnement du dispositif ci-avant décrit va maintenant être expliqué en se référant plus particulièrement aux figu- res 4 à 8. D'une façon générale, le fonctionnement du boîtier comporte deux modes principaux: - un mode de pré-session dans lequel le boîtier va s'authen- tifier, - un mode de session, qui peut être mis en oeuvre postérieu- rement au mode de pré-session, pour sécuriser l'échange de messages entre le boîtier, par l'intermédiaire du terminal, et le serveur. Le mode de pré-session peut être effectué soit en utilisant l'algorithme "DES" soit en utilisant l'algorithme "RSA". Le mode de session sera avantageusement exécuté avec l'algo- rithme "DES". Dans le cas de l'utilisation de l'algorithme "DES" dans le mode de pré-session, il y a authentification mutuelle du serveur et du boîtier, et la clé de base KB est la clé de stockage KST. Le début du mode de pré-session est représenté sur l'organi- gramme de la figure 4, qui s'applique aux deux algorithmes; les organigrammes des figures 5 et 6 s'appliquent respecti- vement aux algorithmes "DES" et "RSA",-et représentent les deux variantes de la fin du mode de pré-session. Dans ce mode de pré-session, le boîtier agit sur l'organe d'aiguillage AIG pour configurer les divers aiguillages du terminal. Parallèlement, le boîtier surveille toute autre action sur cet organe d'aiguillage, c'est-àdire toute action d'origine externe au boîtier (serveur, ou tiers malveillant essayant de modifier les aiguillages). Toute autre action, c'est-à-dire par exemple une demande de modification d'aiguil- lage non requise par le boîtier, entraînera l'avortement de ce mode de pré-session. Egalement dans ce mode de pré-session, le boîtier interdira la liaison entre le clavier du terminal et l'interface-ligne, de façon qu'aucune information tapée par l'utilisateur ne puisse être transmise en clair sur la ligne LST. A chaque fois que cette interdiction est effective, les premiers moyens de visualisation LED1 s'allumeront. On va maintenant décrire l'utilisation du début du mode de pré-session par l'algorithme "DES". Après que l'utilisateur ait tapé sur son terminal le code d'accès au serveur choisi, le serveur envoie au boîtier dans l'étape 10 une demande d'identification. Cette identi- fication consiste à vérifier que l'adresse du boîtier est valide. Le bo tier reçoit cette demande dans l'étape 11, vérifie dans l'étape 12 la validité de l'adresse et si celle- ci est valide, envoie dans l'étape 13 un acquittement d'iden- tification au serveur. Celui-ci reçoit cet acquittement dans l'étape 14 qui marque le début d'une suite prédéterminée d'opérations entre les premiers moyens de dialogue du boîtier et les seconds moyens de dialogue du serveur. D'une façon générale, un message échangé entre le serveur et le boîtier comprend une série d'octets TLV dans laquelle l'octet T indique le type d'opération, l'octet V indique le champ des données proprement dites, et l'octet L indique la longueur en octets du champ V des données. Après avoir reçu l'acquittement dans l'étape 14, le serveur envoie au bottier une demande d'authentification. Cette demande d'authentification, correspondant à un octet T égal à 01, est reçue par le bottier dans l'étape 15 et, après avoir agi sur l'organe d'aiguillage AIG de façon à interdire la liaison clavier interface ligne, le bottier initialise, dans l'étape 16, un message à l'écran EC demandant la saisie du code confidentiel CC de l'utilisateur. Ce dernier saisit alors son code confidentiel au clavier. Après saisie de ce code confidentiel, le bottier vérifie, 2623309- dans l'étape 17, sa concordance avec la donnée mémorisée dans les moyens de mémoire morte programmable du boîtier. Pour effectuer cette comparaison, les premiers moyens de chiffrement/déchiffrement déchiffrent le code confidentiel à l'aide de la clé de stockage KST. En cas de concordance, le boîtier envoie son code d'authentification I, dans l'étape 18, vers le serveur. Celui-ci le reçoit dans l'étape 19 et l'octet T vaut alors 02. Le serveur choisit alors, dans l'étape 20, à l'aide d'un algorithme de génération du nombre aléatoire approprié, un nombre aléatoire X'. A l'aide de ce nombre X' du code d'authentification I et de la clé de base KB de l'algorithme "DES", les seconds moyens de chiffre- ment/déchiffrement du serveur calculent une donnée crypto- graphique Y' à l'aide de l'algorithme "DES" (étape 21). Le nombre X' constitue une première clé primaire dont la signification sera donnée ci-après. Dans la suite du texte, la série des étapes 10 à 21 sera désignée par la référence 1. La suite de l'organigramme se rapportant à la fin du mode de pré-session est représen- tée sur la figure 5. Après avoir calculé la donnée cryptographique Y', le serveur *envoie son code d'authentification S, dans l'étape 22, vers le boîtier. Celui-ci le reçoit dans l'étape 23, l'octet T valant également la valeur 02. A la réception de ce code d'authentification S, les premiers moyens de dialogue du boîtier choisissent (étape 24)un deuxième nombre aléatoire X et les premiers moyens de chiffrement/déchiffrement calcu- lent une donnée cryptographique Y à l'aide de l'algorithme "DES", de la clé de base KB, du deuxième nombre aléatoire X et du code d'authentification S (étape 25). Ce deuxième nombre aléatoire X, qui constitue une deuxième clé primaire, est généré par les premiers moyens de dialogue à partir du temps qui s'est écoulé entre le moment o le boîtier a demandé à l'utilisateur de saisir son code confi- dentiel et le moment o ce dernier l'a effectivement saisi au clavier. Ce temps est rapporté au nombre de cycles d'hor- loge. Après avoir déterminé la donnée cryptographique Y, le boîtier l'envoie dans l'étape 26 vers le serveur, l'octet T valant alors 03. Le serveur reçoit Y dans l'étape 27 et le déchiffre alors dans l'étape 34 à l'aide de l'algorithme "DES" en utilisant la clé de base KB. Ce déchiffrement permet donc au serveur de retrouver son code d'authentification S et de le vérifier. Si cette vérification est positive, le ser- veur obtient alors le deuxième nombre aléatoire X et la réunion du premier nombre aléatoire X' et de ce deuxième nombre aléatoire X constituera la clé de session définitive KSS utilisable par l'algorithme "DES" dans le mode de session (étape 36). Cette clé de session KSS sera stockée dans la mémoire vive MV. Avant de déchiffrer la donnée cryptographique Y dans l'étape 34, le serveur S envoie la donnée cryptographique Y' qu'il avait calculée dans l'étape 21. Le boîtier reçoit cette donnée cryptographique dans l'étape 29 et la déchiffre à l'aide de la clé de base KB de l'algorithme "DES". Ainsi, * dans l'étape 31, le boîtier retrouVe son code d'authentifi- cation I ainsi que le premier nombre aléatoire X'. La véri- fication de I est effectuée dans l'étape 32 et si cette vérification est positive, le boîtier envoie un acquittement que reçoit le serveur dans l'étape 37. Ceci étant fait, le boîtier calcule (étape'33) la clé de session définitive KSS de l'algorithme "DES" qui est la réunion des nombres aléatoires X et X'. Dans la suite du texte, les étapes 31 et 32 seront désignées par la référence 30. L'étape 37 marque la fin du mode de pré-session du boîtier BA. Cette fin de mode est marquée par l'activation des deu- xièmes moyens de visualisation LED2. Dans ce mode de pré- session, une anomalie dans la saisie du code confidentiel, dans l'étape 17, provoque un affichage sur l'écran du termi- nal d'un message indiquant que le code confidentiel est faux. L'utilisateur a droit à trois messages faux. Si le code confidentiel n'est pas correct après ces trois messages, il y a avortement du mode de-pré-session dans l'étape 38. De même, tout au long de ce mode de pré-session, il est important que la suite prédéterminée des opérations soit effectuée dans l'ordre voulu. Cet ordre est représenté par les valeurs croissantes 01, 02, 03 de l'octet T. Si le boi- tier ou le serveur reçoit un octet d'une valeur donnée sans avoir reçu l'octet de valeur précédente, il y a également avortement du mode de présession dans l'étape 38. Enfin, une anomalie dans le résultat d'une opération provoque l'avor- tement de ce mode de pré-session. Une telle anomalie peut être la nonconcordance du code d'authentification I reçu avec celui mémorisé (étape 32). Si le mode de pré-session s'est effectué correctement, le serveur et le boitier se sont donc authentifiés mutuellement et le boîtier peut passer dans son mode de session. L'utili- sateur peut alors envoyer vers le serveur (et réciproquement) des messages chiffrés ou signés. Ces messages seront chiffrés ou signés à l'aide de l'algorithme "DES" utilisant la clé de session KSS. Dans le cas o l'utilisateur ou le serveur ne souhaite pas transmettre des messages chiffrés ou signés, ceux-ci sont alors transmis en clair sur la ligne LST et le boîtier BA est alors "transparent" vis-à-vis du terminal tant qu'un chiffrement ou une signature n'est pas requis. Par contre, dans le mode de session, le serveur peut demander au boîtier d'effectuer une saisie chiffrée des données tapées au clavier par l'utilisateur. Dans ce cas, à la réception d'un tel message, caractérisé par un octet T égal à 04 et un octet L égal à 01, le boîtier BA va agir sur l'organe d'aiguillage AIG de façon que celui-ci interdise la sortie en clair sur la ligne LST des données tapées au clavier par l'utilisateur. Ces données seront préalablement chiffrées par l'algorithme "DES" avant leur envoi sur la ligne LST. 262330.9' Un exemple de donnée à saisir chiffrée peut être le montant d'une transaction dans le cas d'un service d'une banque à domicile. Ainsi, la confidentialité de cette transaction est sauvegardée. Le serveur peut également envoyer des infor- mations chiffrées (par exemple le solde d'un compte bancaire) sur la ligne LST et celles-ci seront déchiffrées à l'aide de l'algorithme "DES" et de la clé de session KSS. Il peut être parfois inutile de chiffrer un message mais par contre il peut être nécessaire de vérifier l'intégrité de ce message à sa réception. C'est pourquoi le serveur et/ou le boîtier ont la possibilité de signer les messages transmis. Un message contenant plusieurs blocs de huit octets de don- nées est signé de la façon suivante: le premier de ces blocs est, d'une part, envoyé en clair sur la ligne LST, d'autre part chiffré grâce à l'algorithme "DES"; le second bloc est d'une part envoyé en clair sur la ligne LST à la suite du premier bloc et, d'autre part, comparé, par exemple dans une porte logique "OU EXCLUSIF", avec le premier bloc chiffré, le résultat de cette comparaison étant à son tour chiffré par l'algorithme "DES". Le processus se répète ainsi jusqu'à épuisement des blocs du message. La signature finale est ensuite envoyée sur la ligne LST. A la réception du message, le serveur ou le boîtier, procédant selon la même méthode, vérifie la signature, et est ainsi assuré que le message reçu l'est bien dans son intégralité. L'annonce d'un message signé se caractérise par le fait que l'octet T prend la valeur 05. Dans le mode de session, le boîtier peut recevoir indifférem- ment soit un message référencé par un octet T égal à 4, soit un message référencé par un octet T égal à 5. Dans ce mode de session du boîtier, toute tentative d'action par un intrus sur la commande d'aiguillage du terminal entraî- ne l'avortement du mode de session et la déconnexion du boîtier. Cette déconnexion peut également être obtenue 2623309- par une demande de déconnexion de la part de l'utilisateur ou du serveur. La clé de session est alors effacée et sera remplacée par une autre clé lors d'une session future. Si l'on se réfère maintenant à la figure 6, on voit que l'on a représenté un organigramme de fonctionnement de la fin du mode de pré-session du bo tier utilisant l'algorithme de chiffrement "RSA". Le début du mode peut être lu sur la figure 4. Sur la figure 6, les éléments analogues ou présentant des fonctions analogues par rapport à ceux repré- sentés sur les figures 4 et 5 seront référencés à l'aide de références augmentées de 100 par rapport aux éléments des figures 4 et 5. On ne décrira ci-après que les diffé- rences entre la figure 6 et les figures 4 et 5. Bien que l'algorithme "RSA" soit utilisé, les données person- nalisées CC et I sont toujours déchiffrées par l'algorithme "DES" à l'aide de la clé de stockage KST. Après avoir effectué la série d'étapes 101 de la figure 4, le serveur a donc déterminé dans l'étape 121 la donnée cryp- tographique Y', à l'aide de l'algorithme "RSA", de la clé publique KBP, du code d'authentification I du boîtier et du nombre aléatoire X'. Dans la version de l'algorithme "RSA" utilisée par les Demandeurs, la donnée cryptographique est codée sur 40 octets. La transmission de la ligne LST ne permettant, dans ce mode de réalisation, qu'une transmis- sion de huit octets, il est donc nécessaire de diviser la donnée Y' en cinq données cryptographiques Y'l, Y'2, Y'3, Y'4, Y'5. Les cinq données cryptographiques Y'l à Y'5 sont successivement envoyées dans l'ordre, vers le boîtier, dans l'étape 40. Le boîtier les reçoit respectivement lors des étapes 41, 43, 45, 47 et 49 et émet alors vers le serveur un acquittement que celui-ci reçoit dans les étapes 42, 44, 46 et 48. A la suite de la réception de la donnée Y'5 dans l'étape 49, les premiers moyens de chiffrement/déchif- frement procèdent, dans la série d'étapes 130, au déchiffrage par l'algorithme "RSA" et la clé secrète KBS associée à la clé publique KBP, de la donnée cryptographique Y'. Bien entendu, il serait possible d'utiliser un mode de codage tel que la transmission de la donnée Y' s'effectue en une fois. Après avoir vérifié que le code d'authentification I était correct, on obtient donc le nombre aléatoire X' et un acquit- tement est envoyé vers le serveur que celui-ci reçoit dans l'étape 137. Le nombre aléatoire X' étant sur 32 octets (car le code d'authentification I est sur 8 octets), il est nécessaire d'effectuer un compactage de ce nombre X' dans l'étape 50 afin de le ramener sur huit octets. Ce nom- bre X' compacte constituera alors la clé de session KSS pour l'algorithme "DES" éventuellement utilisé par la suite lors du mode de session. On va maintenant décrire un mode particulier de fonctionne- ment du dispositif selon l'invention en se référant plus particulièrement aux figures 7 et 8. On a vu précédemment qu'il était nécessaire que le code d'authentification I du boîtier, ainsi que le code confiden- tiel de l'utilisateur, soient mémorisés dans les moyens de mémoire morte programmable IC31. Il est donc avantageux d'avoir dans l'unité centrale ICl un premier programme de chargement de ces données. Ce premier programme se mettra automatiquement en route lors de la première mise sous ten- sion du boîtier à un terminal approprié muni d'un écran. Un message s'affichera alors sur l'écran demandant d'intro- duire le code d'authentification I du boîtier ainsi que le code confidentiel de l'utilisateur potentiel. Ceci s'ef- fectue dans l'étape 200. L'étape 201 consiste en une récep- tion de ces données, puis dans l'étape 202, en un stockage de ces données dans la mémoire préalablement chiffrées par l'algorithme "DES" extérieurement au boîtier. L'étape 202 étant terminée, l'étape 203 est une étape dans laquelle on interdit un nouveau chargement de code d'authentification et de code confidentiel. On indique ensuite dans l'étape 204 la fin du changement des données par le fonctionnement des diodes électroluminescentes LED1 et LED2 et l'étape 205 met alors fin au premier programme de chargement. Le deuxième programme de chargement, dont l'organigramme est représenté sur la figure 8, est un programme permettant d'introduire des. données ou des logiciels spécifiques dans le boîtier. Ces données ou ces logiciels peuvent être par exemple un mémento téléphonique personnalisé avec connexion automatique sur le numéro choisi ou un éditeur de texte local. Ce deuxième programme se mettra automatiquement en route lors de la deuxième mise sous tension du boîtier. Si l'on admet que ce deuxième programme de chargement com- prend un certain nombre de blocs, le stockage d'un bloc dans la mémoire IC3 est effectué dans l'étape 302. Un acquit- tement est alors envoyé signifiant le bon stockage en mémoi- re de ce bloc et l'opération se déroule jusqu'à stockage en mémoire de tous les blocs du deuxième programme de char- gement. Dans l'étape 303, lorsque le nombre de blocs reçus est égal au nombre de blocs à recevoir, intervient alors une étape 305 identique à l'étape 203 interdisant un nouveau chargement d'un quelconque deuxième programme et l'étape 306 indique la fin du changement des blocs par le fonction- nement des diodes LED1 et LED2. L'étape 307 met fin à ce programme de chargement. Les blocs à stocker peuvent être accompagnés d'une signature prédéterminée permettant de vérifier que l'on stocke effectivement un programme autorisé. L'invention peut comporter des variantes, notamment les suivantes: - On a vu précédemment que le mode de pré-session était initialisé par le serveur. On peut cependant concevoir que ce mode soit initialisé sur commande de l'utilisateur au clavier du terminal par exemple. - Dans un souci d'augmenter encore la sécurité des données échangées, ainsi que le caractère personnalisé de l'inven- tion, on peut envisager que la clé de stockage KST utilisée par l'algorithme "DES" soit la combinaison d'au moins deux clés. Une première de ces deux clés ou clé initiale KF serait masquée dans la mémoire morte figée MM du microcontrôleur au moment de sa fabrication. La mémoire externe IC31 du microcontrôleur contiendrait alors le cryptogramme d'une clé intermédiaire KI. Enfin, la mémoire externe contiendrait, chiffrées par l'algorithme "DES" et la clé de stockage KST, les données personnalisées (CC, I). Ainsi, au moment de l'utilisation du boitier, la clé inter- médiaire KI sera déchiffrée à l'aide de son cryptogramme et de la clé initiale KF. La clé de stockage KST sera alors déchiffrée par son cryptogramme et par la clé intermédiaire KI et les données personnalisées seront déchiffrées par la clé de stockage. Dans le cas o l'algorithme "DES" est utilisé dans le mode de pré-session, la clé de stockage KST est la clé de base KB et la clé de session KSS sera transmise'chiffrée selon la clé de base KB, la clé de base étant également stockée dans les seconds moyens de mémorisa- tion du serveur. Dans le cas de l'utilisation de l'algorithme- "RSA", la clé de base est toujours la combinaison de la clé publique KBP et de la clé secrète KBS. Cette variante permet d'envisager une personnalisation plus importante du boîtier, car il est possible de fournir à des utilisateurs différents des boîtiers ayant la même clé KF, mais ayant des clés intermédiaire KI et de stockage KST propres à chaque utilisateur. De plus, le fait que cette clé de stockage soit présente sous forme de cryptogramme permet de la stocker dans une mémoire morte programmable externe et non plus dans la mémoire morte figée du microcon- trôleur. - Le séquencement de la suite des opérations est effectué en utilisant l'octet T. Cette utilisation dépend du protocole de transmission. En règle générale, il suffit que chaque opération soit pourvue d'un élément caractéristique permettant de l'identifier. Bien entendu, certains moyens décrits ci-dessus pourront être omis, dans les variantes o ils ne servent pas; notamment, l'algorithme "RSA" peut n'être pas implanté dans les moyens de mémorisation du boîtier si les applications prévues utilisent exclusivement le chiffrement "DES". Revendications. 1. Dispositif de sécurisation d'échange de données entre, d'une part, un terminal vidéotex (TVX), possédant un organe de gestion d'aiguillage (AIG) entre un interface ligne (IL), un clavier (CL), un écran (EC) et une prise aval dite péri- informatique (PPI), et, d'autre part, un serveur (SE), à l'aide d'un boîtier additionnel (BA) propre à être connecté sur la prise périinformatique (PPI) du terminal vidéotex (TVX), caractérisé en ce que le bo tier (BA) comprend des premiers moyens de chiffrement/déchiffrement et des premiers moyens de dialogue (MD1) tandis que le serveur comprend des seconds moyens de chiffrement/déchiffrement et des se- conds moyens de dialogue, les premiers (MDl) et seconds moyens de dialogue coopérant pour permettre ledit échange de données, et en ce que le bo tier possède un mode de pré- session dans lequel: - il agit sur l'organe d'aiguillage (AIG) du terminal vidéo- tex (TVX) en surveillant toute autre action sur cet organe d'aiguillage (AIG), - les premiers et seconds moyens de chiffrement/déchiffrement opèrent à l'aide d'une clé de base (KB, KBP, KBS) prédé- terminée, - les premiers (MD1) et seconds moyens de dialogue entament une suite prédéterminée d'opérations comportant la définition d'une clé de session (KSS) transmise chiffrée selon ladite clé de base, - une dite autre action sur l'organe d'aiguillage ou toute anomalie dans l'ordre de ladite suite et/ou dans le résultat d'une opération entraîne l'avortement du mode de pré-session. 2. Dispositif selon la revendication 1, caractérisé en ce que la suite prédéterminée d'opérations comprend la saisie au clavier (CL) par l'utilisateur d'un code confidentiel (CC), le boïtier agissant sur l'organe d'aiguillage (AIG) pour interdire la liaison entre l'interface ligne (IL) et le clavier (CL). 3. Dispositif selon l'une des revendications 1 et 2, caracté- risé en ce que la clé de session (KSS) est générée à partir d'au moins un premier nombre aléatoire (X'). 4. Dispositif selon l'une des revendications 1 à 3, caracté- risé en ce que la clé de session (KSS) comprend une première clé primaire (X') générée par les seconds moyens de dialogue du serveur. 5. Dispositif selon la revendication 4, caractérisé en ce que la suite prédéterminée d'opérations comprend l'envoi par le serveur vers le terminal vidéotex de la première clé primaire (X'). 6. Dispositif selon l'une des revendications précédentes, caractérisé en ce que le boîtier (BA) comprend des premiers moyens de mémorisation (MM, IC3), tandis que le serveur (SE) comprend des seconds moyens de mémorisation, les deux moyens de mémorisation contenant au moins une partie de ladite clé de base. 7. Dispositif selon la revendication 6, caractérisé en ce que les premiers moyens de mémorisation comprennent des moyens de mémoire morte figée (MM) et des moyens de mémoire morte programmable (IC31). 8. Dispositif selon la revendication 7, caractérisé en ce que les moyens de mémoire morte programmable (IC31) compren- nent des informations particulières (CC, I) chiffrées par les premiers moyens de chiffrement/déchiffrement à l'aide d'une clé de stockage (KST). 9. Dispositif selon la revendication 8, caractérisé en ce que la clé de stockage est la combinaison au moins d'une clé initiale (KF) et d'une clé intermédiaire (KI), la clé initiale (KF) étant stockée dans les moyens de mémoire morte (MM) tandis que la clé intermédiaire (KI) est stockée dans les moyens de mémoire morte programmable (IC31), chiffrée par les premiers moyens de chiffrement/déchiffrement à l'aide de la clé initiale (KF). 10. Dispositif selon l'une des revendications 6 à 9, caracté- risé en ce que ladite clé de base est une clé unique (KB) stockée à la fois dans les premiers et seconds moyens de mémorisation. 11. Dispositif selon les revendications 4 et 10, caractérisé en ce que la clé de session (KSS) est la combinaison de la première clé primaire (X') et d'une deuxième clé primaire (X) générée par les premiers moyens de dialogue (MD1) du boitier. 12. Dispositif selon la revendication 11, caractérisé en ce que la deuxième clé primaire (X) est générée à partir d'un deuxième nombre aléatoire. 13. Dispositif selon les revendications 2 et 12 prises en combinaison, caractérisé en ce que le deuxième nombre aléa- toire (X) dépend du temps s'écoulant entre la demande de saisie du code confidentiel (CC) et la saisie proprement dite au clavier (CL). 14. Dispositif selon l'une des revendications 11 à 13, carac- térisé en ce que la suite prédéterminée d'opérations comprend l'envoi par le boltier (BA) vers le serveur (SE) de la deu- xième clé primaire (X). 15. Dispositif selon l'une des revendications 8 et 9 prise en combinaison avec l'une des revendications 10 à 14, carac- térisé en ce que la clé de base (KB) est la clé de stockage (KST). 16. Dispositif selon l'une des revendications 6 à 9, carac- térisé en ce que la clé de base comprend une clé publique (KBP) stockée dans les seconds moyens de mémorisation et une clé secrète (KBS) stockée dans les premiers moyens de mémorisation (MM), les clés publique et secrète étant complé- mentaires l'une de l'autre. 17. Dispositif selon les revendications 4 et 16, caractérisé en ce que la clé de session (KSS)est la première clé primaire i0 (X'). 18. Dispositif selon l'une des revendications précédentes, caractérisé en ce que le boîtier additionnel comprend en outre un mode particulier, activé au moins lors de la pre- mière mise sous tension du terminal vidéotex permettant de stocker dans le boîtier des informations personnali- sées. 19. Dispositif selon l'une des revendications 2 à 18, carac- térisé en ce que le boîtier comprend un premier moyen de visualisation (LED1) indiquant l'interdiction de la liaison entre l'interface ligne (IL) et le clavier (CL). 20. Dispositif selon l'une des revendications précédentes, caractérisé en ce que le boîtier (BA) comprend un deuxième moyen de visualisation (LED2) indiquant l'établissement de la clé de session (KSS). 21. Dispositif selon l'une des revendications précédentes, caractérisé en ce que le bottier comprend un mode de session dans lequel les premiers et seconds moyens de dialogue coopè- rent pour permettre l'échange des messages chiffrés et/ou signés selon la clé de session (KSS). 22. Dispositif selon l'une des revendications précédentes, caractérisé en ce que le boîtier (BA) est alimenté en énergie par l'alimentation du terminal vidéotex (TVX). 23. Procédé d'échange de données entre, d'une part, un ter- minal vidéotex (TVX), possédant un organe de gestion d'ai- guillage (AIG) entre un interface ligne (ILl, un clavier (CL), un écran (EC) et une prise aval dite péri-informatique (PPI), et, d'autre part, un serveur (SE), à l'aide d'un bo5tier additionnel (BA) propre à être connecté sur la prise péri-informatique (PPI) du terminal vidéotex (TVX), caracté- risé en ce que l'on munit le boîtier (BA) et le serveur de premiers moyens de chiffrement/déchiffrement et de seconds moyens de chiffrement/déchiffrement respectivement, et en ce que le boîtier possède un mode de pré-session accessible sur commande, dans lequel il agit sur l'organe d'aiguillage (AIG) du ter- minal vidéotex (TVX) en surveillant toute autre action sur cet organe d'aiguillage (AIG), en ce que, dans ledit mode de pré-session, les premiers et seconds moyens de chiffrement/déchiffrement opèrent à l'aide d'une clé de base prédéterminée, et en ce que, dans ledit mode de présession, le boîtier et le serveur dialoguent par une suite prédéterminée d'opé- rations comportant la définition d'une clé de session (KSS) transmise chiffrée selon ladite clé de base, tandis qu'une dite autre opération sur l'organe d'aiguillage ou toute anomalie dans l'ordre de ladite suite et/ou dans le résultat d'une opération entraîne l'avortement du mode de pré-session.