FR 2767240 A1 19990212 FR 9710000 A 19970805 L'invention se rapporte à un procédé de signature électronique pouvant être mis en oeuvre sur un système informatique dont certains composants ne sont pas sécurisés. Comme tout procédé de signature électronique peut être utilisé comme procédé d'authentification, l'invention se rapporte aussi à un procédé d'authentification pouvant être mis en oeuvre sur un système informatique dont certains composants ne sont pas sécurisés. De plus, comme le procédé de signature électronique objet de l'invention inclut à la fois l'authentification du signataire par le programme mis en oeuvre et l'authentification du programme mis en oeuvre par le signataire, l'invention peut également être utilisée pour garantir l'intégrité de programmes ou de données sur un système informatique dont certains composants ne sont pas sécurisés, le programme une fois authentifié pouvant être utilisé ensuite pour vérifier cette intégrité. L'invention s'applique notamment dans le cas où les composants du système informatique utilisés par la personne signataire sont des composants non sécurisés, permettant par exemple à certains logiciels de s'exécuter contre le gré de la personne signataire et sans que cette personne signataire puisse s'en rendre compte, ces logiciels pouvant y avoir été introduits à son insu, dans certains cas en remplaçant des logiciels dont ils imitent le comportement. L'invention s'applique également dans le cas où est utilisé un réseau informatique non sécurisé, sur lequel tous les messages qui circulent peuvent être lus, modifiés, ou supprimés au cours de leur transit. L'invention peut donc par exemple être utilisée dans le cadre du commerce sur le réseau Internet, pour sécuriser la signature d'un document tel qu'une facturette émise par le serveur informatique d'une banque, depuis le micro-ordinateur personnel de l'un de ses clients. I1 faut noter, dans cet exemple, que même si le micro-ordinateur est sécurisé par un mécanisme mis en place par le client tel que la saisie d'un mot de passe au démarrage, il ne constitue en aucun cas pour la banque un système sécurise, dans la mesure où la banque ne peut ni en évaluer la pertinence, ni en contrôler la mise en oeuvre systématique. Plus généralement, dans l'exemple du commerce sur le réseau Internet, l'invention peut être utilisée pour authentifier une personne fournissant un numéro de compte, par exemple un numéro de carte bancaire, ou un numéro de client dans le cas de services dont l'accès est réservé à des abonnés. En effet, même si le numéro de compte est chiffré pour le protéger des indiscrétions pendant son transit sur le réseau, rien ne garantit que la personne ayant fourni ce numéro de compte en est bien le titulaire. Les procédés logiciels de signature électronique applicables au domaine auquel l'invention se rapporte reposent généralement sur des algorithmes de chiffrement utilisant de longues clés, pour que la probabilité de calcul de ces clés à partir d'un ensemble d'échantillons de signatures soit très faible, même en utilisant des moyens informatiques très puissants pendant une très longue durée. L'inconvénient majeur de ces procédés réside dans le fait que, les clés étant longues, elles ne peuvent pas être mémorisées par les personnes signataires, et la saisie d'une telle clé pour chaque signature prendrait en outre un temps inacceptable, notamment à cause des risques d'erreur de saisie induits. Une telle clé doit donc être stockée, ce qui pose un problème si le système sur lequel elle est stockée n'est pas un système sécurisé : elle peut alors être volée par un logiciel intrus. Un autre inconvénient majeur de ces procédés logiciels est que lorsque certains composants du système informatique utilisés par la personne signataire ne sont pas sécurisés, l'un des logiciels mis en oeuvre par la personne signataire peut avoir été modifié ou remplacé à son insu, et peut donc falsifier le document à signer, ou divulguer ce qu'il est suffisant de connaître pour imiter la signature de la personne signataire. Certains autres procédés de signature électronique reposent sur l'utilisation de matériel spécifique, tel qu'un lecteur de carte à puce, un dispositif de reconnaissance d'une empreinte digitale, ou un dispositif de reconnaissance du fond de l'oeil. L'inconvénient majeur de ces autres procédés est de nécessiter l'ajout de matériel spécifique, ce qui induit un surcoût significatif. L'invention résout ces problèmes et propose un procédé qui a l'avantage de ne nécessiter aucune modification ou extension matérielle des composants non sécurisés que sont les micro-ordinateurs personnels courants, équipés ou non d'un moyen local de stockage de masse permanent. L'invention a en effet pour objet un procédé de signature électronique, caractérisé en ce qu'au cours de l'exécution du protocole de communication entre l'émetteur du document à signer et le signataire, l'émetteur du document à signer envoie au signataire au moins un programme directement exécutable par le matériel constituant le poste de travail du signataire, et dont l'exécution comprend notamment les phases suivantes : le programme déchiffre un fichier détenu par le signataire à laide d'un masque qu'il construit en assemblant des portions de son propre code exécutable, tout en modifiant pendant cette phase certaines parties de son propre code exécutable; le programme utilise le résultat obtenu pour afficher au moins un ensemble d'images ; le programme affiche le document à signer et invite le signataire à désigner l'une des images dans chaque ensemble ; le programme calcule une empreinte du document en utilisant comme clés les identifiants des images désignées. Selon des modes particuliers de réalisation - les images affichées peuvent être animées de mouvements ou de changements de couleur périodiques. - chaque image peut avoir une période distincte de celles des autres images faisant partie du même ensemble. - la fréquence des changements de couleur de certaines parties d'images peut exploiter le phénomène de persistence rétinienne. - les positions relatives des images faisant partie d'un même ensemble peuvent varier à chaque exécution du programme qui les affiche, en fonction d'un tirage aléatoire effectué par ce programme. - la désignation d'une image par le signataire peut avoir à intervenir durant une phase donnée de la période de cette image. - chaque message retourné par le poste de travail du signataire à l'émetteur du document à signer peut être chiffré sous la forme du résultat d'une fonction à sens unique à brèche secrète. - les clés de déchiffrement d'un fichier peuvent être calculées par un programme en combinant un nombre A, résultant d'un tirage aléatoire effectué par l'exécution du programme sur le poste de travail du signataire, puis transmis à l'émetteur du document à signer sous forme chiffrée, à un autre nombre calculé en fonction du nombre A puis transmis au programme par l'émetteur du document à signer. - le délai accordé au signataire pour fournir une réponse peut être limité par l'émetteur du document à signer, à une valeur dépendant du temps nécessaire pour faire parvenir sur le poste de travail du signataire un fichier de la taille du fichier déchiffré par le programme. - le résultat d'un calcul effectué par un programme peut dépendre du temps d'exécution de certaines parties de ce programme. - un tel calcul peut consister à compter le nombre d'itérations d'une boucle qu'il reste possible d'exécuter avant la fin du cycle de balayage vidéo en cours. - la stabilité du résultat d'un tel calcul peut être assurée en divisant un résultat intermédiaire par un nombre N fixé à l'avance, après ajout d'un nombre calculé en fonction du résultat intermédiaire obtenu lors d'une précédente exécution modulo N. En corollaire, l'invention a aussi pour objet un système informatique comprenant notamment un poste de travail, un serveur, et un réseau auquel ils sont connectés, caractérisé en ce qu'il met en oeuvre ce procédé. Les caractéristiques et avantages de l'invention ressortiront de la description qui suit, donnée à titre d'exemple et illustrée dans les dessins annexés. Dans les dessins - la figure 1 illustre par une vue synoptique un système informatique comprenant un poste de travail, un serveur, et un réseau, conforme à l'invention; - la figure 2 illustre sous la forme d'une chronologie des échanges effectués par le poste de travail et le serveur, un exemple de signature électronique conforme au procédé de l'invention; - la figure 3 illustre un exemple de calculs effectués par le poste de travail et de calculs effectués par le serveur pour respectivement chiffrer et déchiffrer les informations devant être protégées contre les indiscrétions; - la figure 4 illustre les propriétés des programmes générés par le serveur qui garantissent la détection par le serveur de toute altération de ces programmes au cours de la mise en oeuvre du procédé; - la figure 5 illustre un exemple de technique de chiffrement permettant de rendre impossible la cryptanalyse des informations gérées par le procédé et résidant sur le poste de travail. La figure 1 illustre un exemple de système informatique où un poste de travail non sécurisé PNS est connecté à un serveur sécurisé SVS par l'intermédiaire d'un réseau non sécurisé RNS. Le poste de travail PNS comprend notamment un processeur central PPC, une mémoire centrale PMEM, un clavier PCL, un dispositif PCOM de communication avec le réseau RNS, et un dispositif d'affichage vidéo PAV comprenant en particulier une mémoire propre PAVM adressable directement par le processeur central PPC. Le dispositif d'affichage vidéo peut aussi comporter une interface de synchronisation PAVS sur la fin de cycle de balayage vidéo. Il peut aussi comporter une interface de configuration de la palette des couleurs PAVC. Le poste de travail PNS comprend également un système de stockage permettant de gérer un fichier PFCH dont la taille est telle que sa transmission par l'intermédiaire du réseau RNS prenne un temps supérieur aux délais de réponse accordés par le serveur SVS lors de la mise en oeuvre du procédé, compte tenu du débit maximal du dispositif de communication PCOM. Le serveur sécurisé SVS comprend notamment un système de stockage permettant de gérer un fichier SFCH. Dans la figure 2, le poste de travail PNS envoie, à l'étape 1, un message au serveur SVS pour demander la mise en oeuvre du protocole de signature, en fournissant une identification ID de la personne signataire, par exemple son numéro de compte. A l'étape 2, le serveur SVS génère puis envoie au poste de travail PNS une clé CO et un programme P1, immédiatement exécutable par le processeur central PPC du poste de travail PNS, et contenant le document à signer, sous forme chiffrée si l'on souhaite en assurer la confidentialité. A l'étape 3, le poste de travail PNS exécute le programme P1, ce qui a pour premiers effets de charger, dans une zone mémoire ZMEM de la mémoire centrale PMEM, le contenu du fichier PFCH, et d'initialiser les dispositifs du poste de travail PNS nécessaires à son fonctionnement. Par exemple, le dispositif d'affichage PAV est mis dans un mode permettant au programme Pî de le contrôler totalement par écritures directes dans la mémoire vidéo. A l'issue de cette étape, le programme P1 ne fait plus jamais appel aux services du système d'exploitation, car leur intégrité n'est pas certaine, et prend le contrôle exclusif du processeur en inhibant les interruptions, pour éviter tout risque d'indiscrétion de la part d'un autre processus en cours d'exécution sur le poste de travail PNS. Le programme P1 effectue ensuite une première passe de déchiffrement du contenu de la zone mémoire ZMEM conformément au principe illustré par la figure 4, en utilisant comme clé CO, puis génère un nombre aléatoire donnant une clé C1. A l'issue de cette étape, le programme P1 construit un message contenant la valeur de la clé C1, chiffrée conformément au principe illustré par la figure 3, et l'envoie au serveur SVS. A l'étape 4, le serveur SVS déchiffre le message envoyé par le poste de travail PNS à l'aide d'un algorithme tel que celui illustré par la figure 3, pour obtenir la valeur de la clé C1. Le serveur SVS calcule alors, en fonction de la clé C1 et du contenu du fichier SFCH, la clé C2 devant être combinée à la clé C1 par le programme P1 pour pouvoir transformer le contenu courant de la zone mémoire ZMEM en la définition d'un ensemble d'images. Le fait que l'ensemble d'images soit calculé à partir d'une représentation chiffrée, et le fait que la clé de déchiffrement ne transite jamais sur le réseau dans un format déchiffrable par un tiers, font que quiconque intercepte tous les messages échangés par le serveur SVS et le poste de travail PNS reste incapable de déterminer les ensembles d'images ayant été affichés sur le poste de travail PNS lors de la mise en oeuvre du procédé, même en disposant d'une copie de l'état du fichier PFCH juste avant la mise en oeuvre du procédé. En effet, la clé C2 nécessaire au déchiffrement du contenu du fichier PFCH varie d'une exécution à l'autre du programme P1. A l'étape 5, le programme P1 effectue une seconde passe de déchiffrement de la zone mémoire ZMEM conformément à l'algorithme illustré par la figure 5, en utilisant comme clé le résultat d'une opération ouexclusif ayant pour opérandes les valeurs des clés C1 et C2. Le programme P1 transforme ainsi la zone mémoire ZMEM en la définition d'un ensemble d'images. Le programme P1 exploite ensuite le résultat de cette transformation en l'interprétant comme des suites d'écritures à effectuer dans la mémoire vidéo, ce qui a pour effet d'afficher l'ensemble d'images. Le programme P1 y juxtapose, juste avant cela, l'affichage du document à signer, après l'avoir déchiffré si nécessaire en utilisant par exemple la même clé et le même algorithme. Le signataire désigne alors, après avoir vérifié qu'il est d'accord pour signer le document présenté, l'une des images affichées, par exemple en frappant une touche du clavier. On peut supposer à cet effet que chaque image est affichée associée à une lettre ou un chiffre, la relation entre les images et les lettres ou chiffres étant variable d'une mise en oeuvre à l'autre du procédé de signature, si l'on veut faire en sorte que la désignation des images par le signataire ne devienne jamais une opération machinale. Il est clair qu'à cette étape, on demande au signataire de vérifier, tout comme il le ferait pour un billet de banque, la conformité de l'image qui lui est présentée à ce qui a été préalablement convenu comme faisant partie de son code confidentiel. L'un des avantages de ce procédé est qu'il oblige l'ensemble des composants non sécurisés à s'authentifier les premiers, c'est à dire avant que le signataire ne divulgue l'élément correspondant de son code confidentiel. Cela ne demande pas pour autant au signataire un effort de mémorisation plus important que celui nécessaire à, de mémoire, l'entrée au clavier d'un code alphanumérique : il est en effet aisé de reconnaître une image, même lorsque l'alphabet des images possibles est de cardinalité élevée. Les images ainsi affichées constituent bien un procédé d'authentification du programme P1 car seul le programme P1 émis par le serveur SVS est capable d'afficher ces images sur le poste de travail PNS du signataire dans les délais accordés par le serveur SVS. Les paragraphes suivants en explicitent les raisons : la définition des images ne peut pas être transmise dans le format utilisé par le programme P1 par l'intermédiaire du réseau RNS dans les délais accordés par le serveur SVS, elle ne peut être extraite du fichier PFCH que par le programme P1 lui-même, et elle ne peut pas non plus être compilée, transmise, puis décompilée dans un format de type description condensée dans les délais accordés par le serveur SVS. Les images sont par exemple composées de figures géométriques et animées de mouvements et de changements de couleur périodiques, chaque image ayant sa période propre pour que la période de l'ensemble d'images soit très longue, de sorte que la transmission de ces images au poste de travail PNS prenne un temps ne permettant plus ensuite de retourner au serveur SVS une réponse dans les délais accordés par le serveur SVS, compte tenu des moyens de communication dont est équipé le poste de travail PNS. Ces propriétés du programme P1 exploitent l'importance de la différence entre, d'une part, la bande passante du dispositif PCOM, d'autre part, la bande passante du lien de communication entre le processeur central PPC et le dispositif d'affichage PAV du poste de travail PNS. Même lorsque la bande passante effective du dispositif PCOM atteint 3 mégabits par seconde, c'est à dire le débit nécessaire par exemple à la diffusion de vidéo en temps réel, la taille minimale du fichier PFCH requise, pour que le délai de réponse accordé par le serveur SVS puisse être d'au moins 30 secondes, est de 10 méga-octets, et reste donc parfaitement compatible avec les capacités des postes de travail disposant d'une capacité à communiquer à la vitesse de 3 mégabits par seconde. La technologie de ces postes de travail permet aussi d'afficher au minimum des images en 16 couleurs avec une définition de pixels de l'ordre de 640 colonnes sur 480 lignes, et de modifier la couleur de ces pixels à raison de 1 million par seconde en moyenne. La transmission sur le réseau RNS de 4 secondes d'animation par ensemble d'images, minimum nécessaire au signataire pour reconnaître les images qu'il doit désigner, prend alors plus de 30 secondes, si le procédé est mis en oeuvre en enchaînant au moins 4 ensembles d'images, car il faut compter environ 6 bits par pixel modifié : même en supposant qu'une adresse dans la mémoire vidéo permet d'atteindre 8 pixels simultanément, il faut compter 8 bits de masque et 16 bits d'adresse, par adresse d'accès à un groupe de 8 pixels, pour 4 pixels effectivement modifiés en moyenne par accès, en supposant que l'on peut factoriser les bits de couleur. Pour empêcher que l'on puisse compresser la définition en réduisant le nombre d'images par seconde, la couleur de certaines parties de chaque image varie à fréquence élevée, pour exploiter la capacité d'intégration du phénomène de persistence rétinienne : l'altération du rendu découlant de la suppression de certains états intermédiaires devient alors évidente pour le signataire. Le programme P1 peut tirer parti des possibilités offertes par l'interface de configuration de la palette des couleurs s'il existe : il est alors possible, en quelques instructions, de modifier rapidement la couleur de tous les pixels référençant un même registre de la palette. Par ailleurs, seul le programme P1 est capable de transformer dans les délais le contenu du fichier PFCH en une définition de ces images, grâce aux propriétés illustrées par la figure 4. Un programme installé par intrusion sur le poste de travail PNS du signataire peut effectivement être capable d'afficher les ensembles d'images, pourvu qu'on lui transmette une description de ces ensembles d'images dans un format de taille suffisamment petite pour être transmissible en un temps compatible avec les délais imposés par le serveur SVS. Cependant, la génération d'une telle description suppose l'existence, sur un poste de travail tiers ayant amorcé le dialogue avec le serveur SVS (car c'est le seul moyen de connaître les ensembles d'images), d'un programme capable d'analyser les formes et mouvements apparaissant dans les ensembles d'images, d'après les états successifs de la mémoire vidéo, et de convertir le tout en une description de suites d'écritures périodiques dans la mémoire vidéo. Ces états successifs pourraient être obtenus par exemple par logiciel en interprétant le programme P1, ou à l'aide d'un matériel spécifique. Mais la complexité des calculs nécessaires est telle que cela est difficilement faisable dans les délais accordés par le serveur SVS. Il est par ailleurs difficile de compresser une telle description sans induire, sur le poste de travail PNS, des délais de décompression incompatibles avec les délais accordés par le serveur SVS. Même si le poste de travail du signataire est équipé d'un dispositif matériel spécifique tel qu'une carte de décompression vidéo, le problème reste entier car un tel dispositif ne permet en aucun cas de reproduire le rendu authentique à partir d'un format plus compact que celui se trouvant dans le fichier PFCH. Et même si la bande passante du moyen de communication PCOM est suffisante pour transmettre les écritures à effectuer dans la mémoire vidéo au rythme nécessaire pour produire le rendu authentique, le processeur PPC ne peut pas à la fois acquérir les messages en provenance du dispositif de communication PCOM et effectuer les écritures dans la mémoire vidéo au rythme nécessaire pour produire le rendu authentique, puisque par définition les écritures à effectuer dans la mémoire vidéo pour produire le rendu authentique saturent à elles seules le processeur PPC. Le programme P1 peut naturellement enchaîner l'affichage d'un nombre quelconque d'ensembles d'images, en mémorisant pour chacune d'entre-elles l'image désignée par le signataire. Le niveau de sécurité du procédé, au sens de la probabilité de découverte du code confidentiel en désignant pour chaque ensemble une image au hasard, est ajustable. Pour terminer cette étape, le programme P1, après avoir lu les touches du clavier frappées par le signataire, calcule une empreinte du document à signer en utilisant comme clé la concaténation des représentations binaires des identifiants des images désignées par le signataire, ce qui donne une valeur EMS2. Le programme P1 chiffre ensuite la zone mémoire ZMEM conformément au principe illustré par la figure 5 en fonction d'une clé C3, puis chiffre à nouveau le résultat obtenu conformément au principe illustré par la figure 4 en fonction d'une clé C4, les clés C3 et C4 étant générées de façon aléatoire. Pour terminer, le programme P1 constitue un message, chiffré conformément au principe illustré par la figure 3, et destiné à retourner au serveur SVS les valeurs de EMS2, C3 et C4, puis le programme P1 envoie ce message, et enfin écrit l'état de la zone mémoire ZMEM après ces transformations successives dans le fichier PFCH. A l'étape 6, le serveur SVS déchiffre le message envoyé par le poste de travail PNS à l'aide d'un algorithme tel que celui illustré par la figure 3, et vérifie que cette réponse a bien été reçue dans les délais. Le serveur SVS vérifie également la conformité du chiffrement de l'empreinte du document à signer EMS2, et archive les clés C3 et C4, dans le fichier SFCH. Si la valeur EMS2 est conforme à ce qui attendu, le serveur SVS archive la signature, envoie un message d'accusé de réception AR au poste de travail PNS, et l'exécution du protocole est terminée. Dans le cas contraire, la signature est rejetée. La clé C4 est archivée de façon à jouer le rôle de la clé CO lors de la mise en oeuvre suivante du procédé. De même la clé C3 est archivée de façon à pouvoir calculer la future clé C2 en fonction de la future clé C1 lors de la mise en oeuvre suivante du procédé : la future clé C2 sera le résultat d'un OUexclusif ayant pour opérandes C3 et la future clé C1. La dernière passe de chiffrement, celle utilisant C4 comme clé, n'est pas véritablement destinée à chiffrer le contenu du fichier PFCH mais à faire en sorte que seul le futur programme P1, parfaitement intègre, sera capable de transformer, dans les délais accordés par le serveur SVS, le contenu du fichier PFCH en la définition des ensembles d' images. Il est clair que les étapes 2 à 5 peuvent être enchaînées plusieurs fois si nécessaire. Lorsqu'une anomalie est détectée au niveau de la signature de l'empreinte du document à signer, un deuxième essai, exigeant à nouveau l'ensemble des éléments du code confidentiel du signataire, peut être proposé au signataire. Dans tous les autres cas d'anomalie, y compris celui du dépassement du délai de réponse, il se peut qu'il y ait eu intrusion d'un tiers dans le protocole : le serveur SVS exige alors la modification du code confidentiel, ce qui suppose que le signataire réussisse, par un nouvel essai, à produire une signature conforme. Cela n'est toutefois envisageable que si les étapes 2 à 5 sont systématiquement enchaînées au moins deux fois dans le protocole de signature, pour qu'après détection d'une anomalie au cours de l'un des échanges, il reste encore au moins un échange pour protéger la procédure de modification du code confidentiel elle-même. Dans une variante du procédé, chaque élément du code confidentiel du signataire, qui est toujours constitué de l'identifiant d'une image, est systématiquement modifié dès son acquisition par application d'un masque de bits stocké sur le poste de travail PNS et non connu du serveur SVS, de sorte qu'il ne réside sur le serveur SVS aucun sous-ensemble d'informations permettant à lui seul de connaître un élément du code confidentiel du signataire. I1 est clair que la modification du code confidentiel du signataire peut être pilotée par une extension du protocole, dans laquelle chaque élément du nouveau code confidentiel est choisi par le signataire et signé à l'aide de l'élément correspondant du code confidentiel précédent. La taille des messages échangés au cours de la mise en oeuvre du procédé n'a qu'un impact limité sur les délais de réponse que le serveur SVS doit accorder. D'une part, la transmission des informations du serveur SVS vers le poste de travail PNS peut dans un premier temps être effectuée sous forme chiffrée, de sorte qu'on puisse ne faire courir les délais qu'à partir du moment où le serveur SVS en émet, dans un deuxième temps, la clé de déchiffrement, qui est toujours de petite taille. D'autre part, lors de la transmission des informations EMS2, C3, et C4, du poste de travail PNS vers le serveur SVS, qui se présente toujours sous la forme du résultat d'un chiffrement conformément au principe illustré par la figure 3, on peut arrêter de faire courir le délai dès que les premiers octets ont été reçus, car dans la quasitotalité des cas il n'existe qu'une seule suite d'octets cohérente avec ces premiers octets. La figure 3 illustre un exemple d'utilisation d'un mécanisme de type fonction à sens unique à brèche secrète permettant de sécuriser les informations transmises au serveur SVS par le poste de travail PNS. Naturellement, n'importe quelle fonction CR à sens unique à brèche secrète suffisamment sûre peut être utilisée, par exemple celle d'un algorithme de chiffrement à clef publique. Dans la figure 3, à l'étape A, le serveur SVS envoie au poste de travail le code de la fonction de chiffrement CR ainsi qu'une clé publique CPU. Dans l'exemple de la figure 2, ces éléments sont naturellement intégrés au code du programme P1. A l'étape B, le poste de travail PNS calcule la valeur de la fonction CR à l'aide de la clé publique CPU pour une valeur de la variable X égale à la concaténation IPI des représentations binaires des informations à protéger contre les indiscrétions, puis envoie la valeur résultat R au serveur SVS. A l'étape C, le serveur SVS récupère la valeur IPI en appliquant à R la fonction de déchiffrement DE à l'aide de la clé privée CPR correspondant à la clé publique CPU. I1 est clair que même dans le cas où les informations à protéger contre les indiscrétions tiennent sur peu de bits, on calculera, sur le poste de travail PNS, la valeur de la fonction CR pour une valeur de la variable complétée à un nombre suffisant de bits (par exemple, à 128 bits) par la représentation binaire d'un nombre aléatoire, de façon que le nombre de valeurs possibles de la variable reste dans tous les cas un nombre très élevé, dissuasif pour les attaques exhaustives. La figure 4 illustre les propriétés des programmes générés par le serveur SVS qui garantissent la détection par le serveur SVS de toute altération de ces programmes au cours de la mise en oeuvre du procédé. De telles propriétés sont indispensables, autrement un programme pourrait être altéré de façon à divulguer ou permettre l'accès à des informations dont la confidentialité est à la base de la sécurité du procédé, par exemple tout ou partie des informations retournées au serveur SVS, avant qu'elles ne soient chiffrées. Par exemple, la suppression des instructions d'inhibition des interruptions permettrait 1 ' accès aux informations confidentielles depuis un autre programme en cours d'exécution sur le poste de travail PNS. Ces propriétés sont les suivantes : premièrement, tout programme généré par le serveur SVS commence par une phase PH durant laquelle il modifie fréquemment certaines portions PA de son propre code exécutable, ces portions correspondant au code de cette phase PH ; deuxièmement, tout programme généré par le serveur SVS pioche durant cette phase des portions PM dans la représentation binaire de son propre code exécutable RBCE et les utilise comme opérandes dans le calcul d'un masque de déchiffrement qu'il applique à la zone mémoire ZMEM, sous la forme d'une opération de type OU exclusif (XOR) t troisièmement, tout programme généré par le serveur SVS pioche durant cette phase des portions PO dans la représentation binaire de son propre code exécutable RBCE et les utilise comme opérande dans les calculs qu'il effectue, notamment pour déterminer la localisation et le nouveau contenu des portions PA, et pour déterminer la localisation et la longueur des portions PM et PZ. Ces propriétés de tout programme généré par le serveur SVS font que toute altération de son code binaire le rend soit incapable de générer le masque de bits indispensable pour pouvoir déchiffrer le contenu du fichier PFCH, soit d'une taille au moins égale à celle du fichier PFCH, et donc tel que la durée de sa transmission sur le réseau RNS devient à elle seule supérieure au délai accordé par le serveur SVS. En effet, toute altération du code exécutable du programme modifie profondément le contenu du masque de bits qu'il génère, car le programme pioche dans son code exécutable un nombre de fois tel que la représentation binaire de toute instruction de son code exécutable intervient dès le début dans les calculs qu'il effectue. En outre, pour qu'après avoir altéré un programme, ce dernier génère toujours le même masque de bits, d'autres altérations sont nécessaires, pour compenser l'impact de la première altération ; les impacts de ces dernières à leur tour doivent alors être compensés par de nouvelles altérations, et ainsi de suite, ce qui fait que la taille des altérations nécessaires n'est finalement bornée que par la taille du masque à générer. Les modifications que le programme apporte à son propre code exécutable consistent par exemple à changer l'adresse ou le registre référencé par une instruction, ou à changer l'adresse de destination ou les conditions de déclenchement d'une instruction de saut. L'état initial de certaines des parties du code exécutable que le programme modifie au cours de son exécution constitue par définition la clé de génération du masque de bits produit par le programme. Dans la figure 2, C0 et C4 sont des exemples de telles clés. Pour que le temps d'exécution du programme reste parfaitement contrôlé, le code exécutable de la phase PH est divisé en sections S(1) à S(N), chaque section se terminant par le calcul de l'adresse de début de l'une quelconque des sections, puis par une instruction de saut JMP à cette adresse. Pour éviter tout risque de boucle, à la fin de chaque section, se trouve un mécanisme de comptage du nombre de sauts déjà effectués à chacune des adresses possibles, et l'adresse de saut piochée est changée lorsque le nombre maximum autorisé est atteint. Et pour que le temps d'exécution reste parfaitement contrôlé, les calculs sont arrêtés lorsque le nombre d'exécutions de section a atteint une quantité suffisante pour que le masque ainsi généré couvre la totalité de la zone mémoire ZMEM. Pour garantir qu'à la fin de la génération de ce masque de bits, le processeur est bien sous contrôle exclusif du programme, chaque section contient au moins une instruction d'inhibition des interruptions : si le programme ne contenait qu'une seule instruction de ce type au début de son exécution, un tiers pourrait en faire démarrer l'exécution peu après son début normal, et garder la possibilité de générer le même masque de bits sans pour autant avoir à transmettre un volume de données prohibitif vis à vis du délai accordé par le serveur SVS. Il est clair que la génération d'un programme dont l'exécution calcule le même masque de bits, et de taille très inférieure à celle de ce masque de bits, est impossible, excepté si cette exécution consiste à interpréter le programme généré par le serveur SVS. En effet, pour pouvoir générer le même masque de bits, il faut nécessairement exécuter l'ensemble des calculs effectués par ce programme, et ce programme ne peut pas être compilé dans un autre langage car il modifie son propre code exécutable pendant son exécution. Pour que l'interprétation du programme sur le poste de travail PNS ne puisse pas produire dans les délais accordés par le serveur SVS le masque de bits en question, certaines sections de code du programme calculent des clés qui dépendent du temps d'exécution du programme, et sont ensuite utilisées comme opérandes dans les calculs effectués par le programme. Le calcul d'une telle clé consiste par exemple à compter le nombre d'itérations d'une boucle qu'il reste possible d'exécuter avant la fin du cycle de balayage vidéo en cours. Pour que toutes les exécutions du programme produisent les même clés, le début de chaque exécution du programme est synchronisé sur la fin ou le début d'un cycle de balayage vidéo, et les clés sont calculées d'après les nombres d'itérations comptés de la façon suivante : si le nombre d'itérations compté lors de la première exécution du programme est divisible par 3, alors pour toutes les exécutions suivantes le nombre d'itérations compté est augmenté de 1, et le tout est divisé par 3 pour obtenir la clé ; si le nombre d'itérations compté lors de la première exécution du programme est congru à 1 modulo 3, alors pour toutes les exécutions suivantes le nombre d'itérations compté est simplement divisé par 3 pour obtenir la clé ; si le nombre d'itérations compté lors de la première exécution du programme est congru à 2 modulo 3, alors pour toutes les exécutions suivantes le nombre d'itérations compté est diminué de 1, et le tout est divisé par 3 pour obtenir la clé. Ces précautions sont indispensables car 2 exécutions successives peuvent donner des nombres d'itérations différents d'une unité, dans le cas où la fin de la dernière itération exécutable correspond exactement à la fin du cycle de balayage vidéo en cours. La correction appliquée avant chaque division par 3 est naturellement exécutée y compris lors de la première exécution, car la suite des instructions exécutées doit être identique dans tous les cas. Dans tous les cas, chaque correction à appliquer est lue dans une variable externe VEXTIN, qui se trouve simplement être initialisée à 0 lors de la première exécution. Dans tous les cas également, la valeur modulo 3 du nombre d'itérations ayant pu être exécutées est écrite dans une variable externe VEXTOUT, dont la valeur n'est utilisée, à la fin de l'exécution du programme, que dans le cas de la première exécution, pour calculer la valeur initiale de la variable VEXTIN à utiliser pour toutes les exécutions suivantes du programme. Chaque valeur initiale ainsi calculée tient sur 2 bits, et fait naturellement partie de la clé de génération du masque de bits. Dans la figure 2, à l'étape 5, la zone mémoire ZMEM est chiffrée à l'aide d'une clé C4 dans laquelle ces paires de bits ont préalablement été forcées à zéro, mais, dans la valeur de la clé C4 retournée ensuite au serveur SVS, ces paires de bits contiennent les valeurs initiales calculées en fonction des valeurs des variables VEXTOUT à la fin de la passe de chiffrement. Il est clair que l'interprétation d'un programme dure au minimum 2 fois plus longtemps que son exécution cette propriété à elle seule est suffisante pour que le serveur SVS puisse dans tous les cas détecter que le programme a été interprété et non exécuté, sur le poste de travail PNS, pourvu que la durée de la passe de déchiffrement représente une part suffisante du délai accordé par le serveur SVS. L'intégration de mesures du temps d'exécution, comme présenté dans les paragraphes précédents, permet de diminuer considérablement la durée minimale relative de la passe de déchiffrement, car un interpréteur capable de calculer à tout instant de façon précise le temps d'exécution du programme qu'il interprète est considérablement plus lent que l'exécution de ce programme. De plus, la complexité des processeurs équipant aujourd'hui les postes de travail est telle que l'écriture et l'installation d'un tel interpréteur sont à elles seules dissuasives. Dans la figure 5, est présenté un exemple d'algorithme destiné à chiffrer le contenu d'une zone mémoire à l'aide d'une clé, cette zone mémoire contenant par exemple la définition d'ensembles d'images, ou un document devant rester confidentiel. Cette passe de chiffrement sert, dans le procédé, à rendre impossible la cryptanalyse du contenu du fichier PFCH autrement que par attaque exhaustive, ainsi que celle des documents à signer, lorsqu'il sont transmis sous forme chiffrée. Naturellement, n'importe quel algorithme de chiffrement qui est suffisamment sûr peut être utilisé à cet effet. Par ailleurs, la cryptanalyse d'un fichier chiffré contenant la définition d'ensembles d'images, sous la forme de commandes successives définissant les écritures à effectuer dans la mémoire vidéo, peut déjà être rendue très difficile en choisissant un système de codage tel que la taille d'une commande soit égale à un nombre variable et non entier d'octets ; par exemple, les commandes de sélection de la plage d'adresses courante, de sélection du masque courant, de sélection de la couleur courante, de mise à jour de la palette des couleurs, et d'écriture à un endroit donné dans la plage d'adresses courante, peuvent avoir des longueurs différentes. L'algorithme présenté consiste à traiter la zone mémoire comme un hypercube de bits H. Lorsque la zone mémoire à chiffrer est par exemple de 1 kilo-octet, l'hypercube a donc 13 dimensions. Chacune des dimensions correspond à un bit d'adressage de l'ensemble des bits de la zone mémoire. Dans l'exemple de la figure 5, l'hypercube n'a que 3 dimensions D(0), D(1), et D(2). Conformément à l'algorithme, le bit courant BC de la clé de chiffrement K est tout d'abord initialisé à celui se trouvant en première position, puis, pour chaque dimension D(I), l'hypercube subit une transformation qui consiste à échanger, si et seulement si le bit courant de la clé de chiffrement est à 1, la valeur de chaque bit B1 de l'hypercube avec celle du bit B2 se trouvant à l'adresse A2 obtenue en inversant dans l'adresse Al du bit B1 le bit correspondant à la dimension D(I). Chaque fois qu'un tel bit B1 a été pris en compte, le bit courant, dans la clé de chiffrement, est avancé d'une position, et, lorsque la fin de la clé de chiffrement est atteinte, le bit courant devient à nouveau celui se trouvant en première position. Au total, pour une zone mémoire de 1 kilo-octet, il y a donc 13 fois 4096 échanges de bits potentiels. Comme la clé comporte en moyenne autant de bits 0 que de bits 1, en pratique seulement 26624 permutations de bits sont candidates. Et comme dans un cas sur 2 les bits à échanger sont identiques, il n'y a que 13312 échanges de bits à effectuer pour chiffrer un kilo-octet de données, soit environ 1,5 échanges de bits par bit de données à chiffrer. Cet algorithme est peu sensible à la taille du bloc de données à chiffrer puisque, pour chiffrer un bloc de 8 méga-octets, le coût des calculs ne s'élève qu'à environ 3 échanges de bits par bit de données à chiffrer. I1 est évidemment possible de supprimer les permutations relatives à certaines dimensions, pour limiter la puissance de calcul nécessaire au chiffrement et au déchiffrement. Les dimensions en question peuvent elles aussi être déterminées par exemple en fonction de la valeur de la clé de chiffrement. Il va de soi que l'algorithme de déchiffrement consiste à effectuer les permutations dans l'ordre inverse de celui de l'algorithme de chiffrement. Dans une variante du procédé, chaque ensemble d'images forme un tout et constitue en fait une scène unique comportant diverses animations. Dans une variante du procédé, les positions relatives des images faisant partie d'un même ensemble varient à chaque exécution du programme qui les affiche, en fonction d'un tirage aléatoire effectué par ce programme, pour que la réaction du signataire ne puisse pas se réduire à une lecture du code d'image se trouvant à une position donnée sur l'écran sans réel effort de reconnaissance d'une image. Dans une variante du procédé, la désignation d'une image par le signataire doit intervenir durant une phase donnée de la période de cette image. Par exemple, si l'image désignée se compose d'un disque vert et d'un carré rouge en mouvement l'un par rapport à l'autre, la désignation doit intervenir lorsque le carré rouge se trouve au-dessus du disque vert. Cette contrainte supplémentaire imposée au signataire permet, pour un même nombre d'ensembles d'images affichés, d'augmenter la longueur de la clé de chiffrement de l'empreinte du document à signer, en ajoutant à l'identifiant de chaque image désignée un identifiant de la phase durant laquelle elle a été désignée, pour former la clé. Dans une variante du procédé, un extrait du contenu courant du fichier PFCH est utilisé comme moyen d'authentification préalable, pour protéger le procédé du vandalisme, c'est à dire de tiers malveillants amorçant le dialogue avec le serveur SVS en usurpant l'identité d'autrui, dans l'unique but de provoquer la fermeture définitive du compte associé, seul objectif atteignable lorsqu'on ne connaît pas le code confidentiel correspondant. Le vol, c'est à dire l'obtention d'une copie, du fichier PFCH par un tiers est en effet possible, mais élimine déjà une grande partie des vandales potentiels, notamment parce que ce fichier est volumineux. Par ailleurs, comme le contenu du fichier PFCH varie à chaque mise en oeuvre du procédé, son vol est détectable. Dans une variante du procédé adaptée au cas où le poste de travail PNS ne dispose en local d'aucun moyen de stockage de masse permanent, c'est à dire par exemple dans le cas d'un micro-ordinateur sans dispositif de stockage sur support magnétique ou optique, le fichier PFCH est transmis par le serveur SVS sous forme chiffrée juste avant la mise en oeuvre du procédé, et stocké directement dans la mémoire PMEM du poste de travail PNS. Peu importe le temps nécessaire à cette transmission, puisque le contenu du fichier PFCH reste inexploitable tant que le serveur SVS n'en émet pas la clé de déchiffrement. Il va de soi que cette variante n'est viable que dans le cas où le débit du réseau RNS est important, compte tenu du volume du fichier PFCH, mais c'est en général le cas des environnements des postes de travail sans moyen local de stockage de masse permanent. REVENDICATIONS 1. Procédé de signature électronique, caractérisé en ce qu'au cours de l'exécution du protocole de communication entre l'émetteur du document à signer et le signataire, l'émetteur du document à signer envoie au signataire au moins un programme directement exécutable par le matériel constituant le poste de travail du signataire, et dont l'exécution comprend notamment les phases suivantes : le programme déchiffre un fichier détenu par le signataire à laide d'un masque qu'il construit en assemblant des portions de son propre code exécutable, tout en modifiant pendant cette phase certaines parties de son propre code exécutable; le programme utilise le résultat obtenu pour afficher au moins un ensemble d'images ; le programme affiche le document à signer et invite le signataire à désigner l'une des images dans chaque ensemble ; le programme calcule une empreinte du document en utilisant comme clés les identifiants des images désignées. 2. Procédé selon la revendication 1, caractérisé en ce que les images sont animées de mouvements ou de changements de couleur périodiques. 3. Procédé selon la revendication 2, caractérisé en ce que certaines images ont une période distincte de celles des autres images faisant partie du même ensemble. 4. Procédé selon la revendication 2 ou 3, caractérisé en ce que la fréquence des changements de couleur de certaines parties d'images exploite le phénomène de persistance rétinienne. 5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce que les positions relatives des images faisant partie d'un même ensemble varient à chaque exécution du programme qui les affiche, en fonction d'un tirage aléatoire effectué par ce programme. 6. Procédé selon l'une des revendications 2 à 5, caractérisé en ce que la désignation d'une image par le signataire doit intervenir durant une phase donnée de la période de cette image. 7. Procédé selon l'une des revendications 1 à 6, caractérisé en ce que chaque message retourné à l'émetteur du document à signer est chiffré sous la forme du résultat d'une fonction à sens unique à brèche secrète. 8. Procédé selon l'une des revendications 1 à 7, caractérisé en ce que les clés de déchiffrement d'un fichier sont calculées par un programme en combinant un nombre A, résultant d'un tirage aléatoire effectué par l'exécution du programme sur le poste de travail du signataire, puis transmis à l'émetteur du document à signer sous forme chiffrée, à un autre nombre calculé en fonction du nombre A puis transmis au programme par l'émetteur du document à signer. 9. Procédé selon l'une des revendications 1 à 8, caractérisé en ce que le délai accordé au signataire pour fournir une réponse est limité par l'émetteur du document à signer, à une valeur dépendant du temps nécessaire pour faire parvenir sur le poste de travail du signataire un fichier de la taille du fichier déchiffré par le programme, compte tenu des moyens de communication dont est équipé le poste de travail du signataire. 10. Procédé selon l'une des revendications 1 à 9, caractérisé en ce que le résultat d'un calcul, effectué par un programme transmis par l'émetteur du document à signer, dépend du temps d'exécution de certaines parties de ce programme. 11. Procédé selon la revendication 10, caractérisé en ce qu'un tel calcul consiste à compter le nombre d'itérations d'une boucle qu'il reste possible d'exécuter avant la fin du cycle de balayage vidéo en cours. 12. Procédé selon la revendication 10 ou 11, caractérisé en ce que la stabilité du résultat d'un tel calcul est assurée en divisant un résultat intermédiaire par un nombre N fixé à l'avance, après ajout d'un nombre calculé en fonction du résultat intermédiaire obtenu lors d'une précédente exécution modulo N. 13. Système informatique comprenant notamment un poste de travail, un serveur, et un réseau auquel ils sont connectés, caractérisé en ce qu'il met en oeuvre un procédé défini par l'une des revendications 1 à 12.