Brevet FR2831364A1 — publié le 20030425

PROCEDE ET DISPOSITIF DE VERIFICATION DE DONNEES SIGNEES PAR GROUPE ET APPLICATION POUR LA TRANSMISSION DE DONNEES DEPUIS UNE MEMOIRE ANNEXE L'invention concerne la vérification de l'authenticité de données transmises, en utilisant la technique de signature de groupes de données. Les données en question peuvent être des instructions, des adresses en mémoire, des valeurs, ou tout autre message ou élément d'information. De manière générale, l'authentification de donnés s'opère par des algorithmes de signature. L'approche classique est alors la suivante : pour une donnée à émettre, l'émetteur produit sa signature obtenue à partir d'une clé privée et transmet cette signature avec la donnée au destinataire. Ce dernier authentifie la donnée en soumettant la signature à un algorithme de vérification utilisant une clé publique. Le destinataire n'a donc pas besoin de connaître la clé privée de l'émetteur pour établir la validité des données reçues, la clé publique utilisée étant générique et disponible à toute entité admise au protocole de signature. A titre d'exemple, une signature cr habituelle d'un message M à transmettre est établie, selon l'algorithme RSA (Rivest, Shamir, Adelman), par la formule : o = h (M) N............. (1) où N est le module du signataire, d est la clé privée du signataire et h est une fonction algorithmique convenue, du type IS09796-1 ou IS09796-2, généralement connu par le terme anglo-saxon de "padding" et "hash". On rappelle qu'un nombre exprimé en mod N est égal au reste de la division par N. La vérification de cette signature RSA consiste alors à tester si elle satisfait la formule : cre = h (M) mod N................ (2) où e est la clé publique du signataire. Sur ce principe, on peut établir un processus de vérification selon lequel chaque message Mi reçu d'un groupe d'un nombre donné de messages fait l'objet d'une vérification par sa signature ai. Cette approche est sûre, mais ralentit considérablement le temps de vérification. Aussi a-t-il été proposé non plus de transmettre la signature cri de chaque message Mi, mais seulement une signature cGj représentative de l'ensemble des messages Ml-Mm d'un groupe Gj de messages. Dans ce cas, l'émetteur des m messages du groupe Gj produit la signature de chacun des messages Mi, obtenue selon la formule (1), soit : ci = h (Mi)d mod N, pour établir une signature de groupe aGj donnée par la formule : oGj = n à m cri mod N............. (3) où n est le symbole usuel de multiplication sur la séquence i=l à m. La signature de chaque message peut être calculée au préalable et stockée en mémoire de l'émetteur, pour ne pas divulguer le clé privée d. Le destinataire effectue alors une seule vérification d'authenticité pour l'ensemble des m messages, en vérifiant la condition donnée par la formule : o-Gj e = nà m h (Mi) mod N............. (4) Ce processus de vérification par groupes de messages M (ou généralement de groupes de données) est connu par le terme anglo-saxon de"screening" (filtrage). Il a été proposé en 1998 par M. Bellare, J. A. Garay et T. Rabin (Eurocrypt, mai juin 1998, Espoo, Finlande ; publication intitulée :"Fast batch vérification for modular exponentiation and digital signatures"). Toutefois, il a été démontré dans l'article."On the Security of RSA Screening" (à propos de la sécurité du filtrage RSA) de J. S. Coron et D. Naccache, 1998 (PKC99, workshop, Japon) qu'une telle vérification par groupes est vulnérable à une attaque lorsqu'il se présente des messages Mi qui se répètent dans un même groupe. Le principe d'une telle attaque sera illustré par un exemple simple avec une clé publique e = 3 et la transmission d'un groupe G (Mi, ai) comprenant quatre messages transmis, dont les trois derniers sont identiques, soit Ml, M2, M2, M2. Supposons que l'émetteur de ce groupe ne signe pas correctement les messages répétés M2. Dans un cas de fraude, cette situation peut provenir du fait que l'émetteur a connaissance de la signature cl du message Ml de manière fortuite, mais pas de la clé privée d permettant de signer validement d'autres messages. Les messages M2 peuvent être tout texte frauduleux jamais signé par le détenteur de d. L'émetteur pourra alors faire correctement valider, sur la base de la formule (4), une signature de groupe égale à h (M2) x cl. Cette signature de groupe est établie en termes de pairs (message Mi, signature ci) sur la base du groupe suivant : (Ml, h (M2) x al), (M2,1), (M2,1), (M2,1). Autrement dit, le nombre 1 peut être substitué à la signature cr2 normalement attendue, moyennant une multiplication de la signature al par h (M2). En effet, la formule (4) donne alors age = n h (Mi) mod N, ce qui est perçu comme étant correct. Dans le but d'éviter ce type d'attaque, il a été proposé tout simplement d'interdire de faire apparaître plus d'une fois un même message Mi dans un groupe donné Gj. Cette contre-mesure est certes efficace, mais pénalisante lorsque des échanges de données font fréquemment intervenir des répétitions de messages. Cela est notamment le cas de messages exprimant des instructions contenues dans des boucles. Il est alors nécessaire, pour éviter les répétitions dans un groupe, de fractionner le flux de messages (ou autres données) en un nombre important de groupes restreints. Or, cela diminue l'intérêt initial de la vérification par groupes. Au vu de ce qui précède, l'invention propose une nouvelle approche de signature et de vérification par groupes selon laquelle on tolère une répétition de données signées dans un même groupe jusqu'à des limites qui ne dépendent, dans les modes de réalisation préférés, que de la valeur choisie pour la clé publique e. Cette approche ouvre la vérification par groupes à de nouvelles applications techniques fort avantageuses, par exemple pour le stockage de données en mémoire annexe dans le cadre de dispositifs communicants. A titre d'exemple la vérification peut intervenir lors de l'exécution d'un programme par un dispositif portatif communicant, tel qu'une carte à puce, à partir d'instructions stockées dans une mémoire annexe située en dehors de la carte, par exemple dans un terminal. Elle permet alors de s'assurer de l'authenticité des instructions fournies depuis cette mémoire. De ce fait, il devient possible de stocker avec sécurité une quantité de données au-delà des capacités de mémoire, par nature limitées, des dispositifs communicants portatifs. Plus particulièrement, l'invention propose, selon un premier objet, un procédé de sécurisation d'éléments de données, transmis depuis une source à au moins un destinataire, par vérification de signature groupée, le procédé consistant à constituer au moins un groupe d'éléments de données et, pour chaque groupe : au niveau de la source, à : avoir à disposition la signature de chaque élément de données ; - combiner les signatures de chaque élément du groupe pour réaliser une signature groupée ; - transmettre la signature groupée au destinataire ; et au niveau du destinataire, à : - soumettre chaque élément de données du groupe reçu à un calcul algorithmique ; - combiner les valeurs résultant du calcul algorithmique de chaque élément du groupe pour obtenir une valeur globale ; - obtenir à partir de la valeur globale une valeur de vérification, et - comparer la valeur de vérification avec la signature groupée, caractérisé en ce que, lors de la constitution d'un groupe, on autorise, le cas échéant, la présence d'éléments de données identiques dans un même groupe. On note que le processus de vérification conforme à l'invention ne nécessite pas de signature dans le terminal, du fait que les instructions sont signées au préalable par l'éditeur du programme. La source peut disposer des signatures de chaque élément du groupe sous forme préalablement mémorisée, par exemple lors du chargement des données. Les éléments de données peuvent être des instructions d'un programme à exécuter au niveau du destinataire. La signature peut être produite en signant, pour chaque élément de données, un ensemble constitué de l'élément de données lui-même et au moins une donnée d'identification associée à cet élément. Avantageusement, on peut utiliser à titre de donnée d'identification une identification spécifique au programme auquel est associée l'instruction à signer, et/ou l'adresse à laquelle est stockée l'instruction à signer. L'ensemble faisant l'objet de la signature est avantageusement formé par la concaténation des bits qui forment un élément de données et la ou chaque donnée d'identification associée à cet élément. La signature peut être du type RSA (Rivest, Shamir, Adelman), selon laquelle : pour un élément de données de rang i, la signature correspond à oi = Pi (oi) d mod N, où Pi est soit : i) une fonction dite de"hachage", éventuellement associée à un remplissage, soit ii) une fonction dite"système de signature avec récupération", Oi est une opérande comprenant l'élément de données et, le cas échéant, au moins une donnée d'identification, d est une clé privée, et mod N désigne l'arithmétique en modulo N, où N est un nombre prédéterminé ; - l'étape de combiner consiste à multiplier ensemble toutes les signatures d'un groupe de m éléments, la signature groupée pour un groupe crGj étant donnée par cGj = Di=1 à m cri i - l'étape de soumettre les éléments de données à un calcul algorithmique consiste à évaluer la valeur rendue par ladite fonction Pi, celle-ci étant la même que celle utilisée pour l'étape de signer, pour le cas de Pi (oi) ; - l'étape de combiner les valeurs consiste à multiplier ensemble toutes les valeurs de Pi (Oi) d'un groupe, ladite valeur globale étant donnée par ni=1 à n Pi (oi) ; - l'étape d'obtenir une valeur de vérification consiste à élever ladite valeur globale à la puissance d'une clé publique e ; et - l'étape de comparer consiste à vérifier s'il y a égalité entre ladite valeur de vérification et ladite signature groupée, en arithmétique modulo N. On peut établir une limite au nombre d'éléments identiques dans un même groupe sur la base d'un paramètre arbitraire utilisé pour l'étape d'obtention de la valeur de vérification, notamment la valeur attribuée à une clé publique e, le nombre limite d'éléments de données identiques admis dans un groupe (Gj) étant dans ce cas égal à e-1. Cette clé publique peut être fixée à une valeur suffisamment élevée, par exemple 216+1, pour qu'elle ne conditionne pas l'étendue d'un groupe lors de sa constitution. On note que puisque ce nombre limite ne concerne que les messages identiques, un groupe peut bien entendu comprendre un nombre arbitrairement grand de messages, dès lors qu'aucun des messages du groupe ne se répète plus de fois que ce nombre limite. Autrement dit, il n'y a pas de limite a priori au nombre de messages possibles dans un groupe donné. Cependant, la gestion de la création de groupes sans limite a priori nécessite une surveillance du contenu des messages et de la comptabilisation des répétitions de messages identiques. Ces tâches peuvent être pénalisantes dans certaines applications à ressources limitées. On peut alors alléger la gestion des groupes en imposant la contrainte qu'aucun groupe ne doit contenir un nombre de messages au-delà du nombre limite de répétitions possibles, ce qui assure que la protection est toujours assurée, même dans le cas d'un groupe formé uniquement de messages identiques. Dans une application envisagée, le destinataire est un dispositif portatif communicant et la source est un terminal. Le procédé peut être utilisé dans le cadre, de l'exécution d'un programme au niveau du destinataire à partir d'instructions dont certaines au moins sont stockées dans une mémoire au niveau de la source, le procédé consistant alors à : - constituer, au niveau de destinataire, au moins un groupe d'instructions reçues de la source ; - procéder à ladite sécurisation du groupe d'instructions par le procédé de vérification de groupe précité. Le groupe peut être déterminé au niveau du destinataire, celui-ci transmettant à la source une demande de signature groupée concernant des instructions dernièrement transmises. Avantageusement, le destinataire demande la signature groupée seulement lorsque le programme atteint une phase critique en ce qui concerne les conséquences de l'exécution d'une instruction reçue. Ces phases critiques peuvent être l'envoi par le destinataire d'informations vers le monde extérieur, une écriture, un effacement, une modification de la mémoire volatile (typiquement EEPROM) du destinataire, l'accès à une variable dont le contenu est considéré confidentiel, et la fin du programme. L'invention concerne aussi, selon un deuxième aspect, un dispositif communicant portatif, caractérisé en ce qu'il constitue ledit destinataire dans le procédé selon le premier aspect, le dispositif comportant : - des moyens d'exécution d'instructions - une interface de communication avec la source ; - des moyens pour exécuter les instructions reçues depuis la source ; - des moyens pour spécifier au moins un groupe d'instructions destinées à être soumises à une signature groupée, dont possiblement un groupe contenant des instructions identiques ; et - des moyens de vérification d'une signature de groupe. L'invention concerne aussi, selon un troisième aspect, un dispositif communicant, caractérisé en ce qu'il constitue la source dans le procédé selon le premier aspect, le dispositif comportant : une interface de communication avec le destinataire ; des moyens de stockage comportant les instructions et des signatures qui leur sont associées ou des moyens de calcul de ces signatures ; - des moyens pour transmettre au destinataire une des instructions en fonction de l'exécution du programme ; et des moyens pour réaliser, pour un groupe d'instructions transmises, une signature groupée des instructions et éventuellement de leurs données d'identification. Avantageusement, ce dispositif introduit une identification de programme pour constituer les données d'identification. L'invention concerne également, selon un quatrième aspect, un procédé de gestion de l'envoi d'instructions d'une source vers un dispositif d'exécution desdites instructions, l'envoi s'effectuant au fur et à mesure de l'avancement de l'exécution d'un programme, caractérisé en ce que l'on établit, au niveau de la source, une séquence prédéterminée d'instructions et en ce que le dispositif d'exécution émet une indication à la source si la prochaine instruction à envoyer est ou non celle qui suit l'instruction courante selon la séquence prédéterminée, la source envoyant l'instruction suivante en fonction de cette indication. L'indication comprend une de préférence une donnée binaire émise par le dispositif d'exécution, ce dernier positionnant la donnée à un premier ou à un second état logique respectivement si la source doit envoyer ou non l'instruction qui suit l'instruction courante selon la séquence prédéterminée. Le dispositif d'exécution peut émettre en outre à la source une identification de la prochaine instruction à envoyer, par exemple sous forme d'adresse de stockage de celle-ci, lorsqu'il émet à la source l'indication de ne pas envoyer l'instruction qui suit l'instruction courante selon la séquence prédéterminée. La première instruction du programme se situe avantageusement à une adresse standardisée de la mémoire de stockage des instructions. Le dispositif d'exécution émet par exemple une indication de ne pas envoyer l'instruction qui suit dans la séquence prédéterminée lorsque l'exécution de l'instruction en cours provoque un saut ou autre action impliquant une interruption dans une séquence prévue dans la séquence prédéterminée. Lorsque le dispositif d'exécution émet à la source une indication de ne pas envoyer l'instruction qui suit l'instruction courante selon la séquence prédéterminée, la source peut, selon le cas, identifier d'elle-même l'instruction attendue par le dispositif d'exécution. La source identifie la prochaine instruction attendue par le dispositif d'exécution par exemple à partir du contenu de l'instruction en cours ou une précédente. La source identifie d'elle-même l'instruction attendue par le dispositif d'exécution par exemple lorsque l'instruction en cours ou une précédente implique un branchement conditionnel. Le procédé peut être mis en oeuvre avec une source sous forme de terminal ou analogue et avec. un dispositif d'exécution portatif, par exemple une carte à puce. Selon un cinquième aspect, l'invention concerne un dispositif d'exécution de programme, par exemple une carte à puce, caractérisé en ce qu'il comprend des moyens de réception d'instructions d'un programme provenant d'une source externe et des moyens d'émettre à la source une indication que l'instruction suivante à envoyer est ou non celle qui suit dans une séquence prédéterminée au niveau de la source, conformément au procédé selon le quatrième aspect. Le dispositif peut comporter en outre des moyens de mise en oeuvre du procédé de vérification selon le premier aspect de l'invention. Selon un sixième aspect, l'invention concerne une source d'instructions de programme, par exemple un terminal, destiné à envoyer des instructions à un dispositif d'exécution de programme au fur et à mesure de l'avancement du programme, caractérisé en ce qu'il comprend des moyens de réception d'une indication que l'instruction suivante à envoyer est ou non celle qui suit selon une séquence prédéterminée au niveau de la source, et d'agir en conséquence conformément au procédé selon le quatrième aspect de l'invention. L'invention et les avantages qui en découlent apparaîtront plus clairement à la lecture des modes de réalisation préférés, donnés purement à titre d'exemples non-limitatifs par référence aux dessins annexés, dans lesquels : - la figure 1 est un schéma bloc simplifié des éléments fonctionnels d'un dispositif communicant portatif et d'un terminal pour la communication de messages signés conformément à l'invention ; - la figure 2 est un organigramme d'un mode de réalisation de l'invention appliqué à la transmission sécurisée d'instructions depuis une mémoire annexe située dans un terminal, pour exécution par une carte à puce, avec vérification par groupe d'instructions ; - la figure 3 est un organigramme d'un premier protocole d'envoi d'instructions d'un programme d'une source à un dispositif d'exécution de programme ; et - la figure 4 est un organigramme d'un deuxième protocole d'envoi d'instructions d'un programme d'une source à un dispositif d'exécution de programme. L'exemple décrit se situe dans le cadre d'une carte à puce 2 qui communique avec un terminal 4 lors de l'exécution d'une application de service, telle qu'une transaction bancaire ou analogue. Il est cependant clair que l'invention s'applique à tout système susceptible fonctionnant avec des données signées. La carte à puce 2 comporte un microprocesseur 6 associé à une mémoire préprogrammée 8 du type ROM, une mémoire réinsriptible du type RAM ou à mémoire rémanente du type programmable effaçable électriquement, connu par l'acronyme anglo-saxon de EEPROM 10 et un registre 12. La mémoire préprogrammée 8 comporte l'ensemble du code de programmation du microprocesseur destiné à être figé. Il s'agit notamment des modules de programme de gestion interne et de protocoles de la carte, et éventuellement de programmes applicatifs, par exemple des applications de service de base, en pré-émission de la carte. La mémoire réinscriptible 10, initialement vierge, peut être chargée de données provisoires ou évolutives, et éventuellement de code pour des applications de service ou autres programmes chargés en post émission de la carte. Le registre 12, qui peut être aussi fonctionnellement intégré à la mémoire réinscriptible 10, sert surtout pour stocker des données à court terme, telles que des résultats intermédiaires de calcul, des statuts de différents paramètres de fonctionnement, etc. La carte 2 échange des données avec l'environnement extérieur via une interface de communication 14, qui peut être du type à contacts et/ou sans contact. L'ensemble des éléments 8-14 de la carte 2 est relié par un bus interne 16 selon une architecture classique. Le terminal 4 comporte les mêmes éléments fonctionnels que la carte 2, à savoir : un microprocesseur 18, une mémoire préprogrammée du type ROM 20, une mémoire réinscriptible du type RAM ou EEPROM 22, un registre 24, une interface de communication 26 compatible avec celle de la carte 2, et un bus interne 28. Ces éléments ont sensiblement les mêmes fonctions que leurs homologues de la carte. La communication entre les interfaces de communication respectives 14 et 26 est établie via une liaison L, qui peut être simplement des contacts entre des plots pour une carte à contacts, une liaison hertzienne ou infrarouge pour une carte sans contact, ou encore un réseau du type Internet ou Intranet dans le cas d'une communication avec un terminal 4 distant. La mémoire préprogrammée 20 et la mémoire réinscriptible 22 comprennent respectivement du code figé et des données évolutives et/ou de mise à jour. On note cependant que pour des raisons de place et de coût, la capacité des mémoires 8 et 10 de la carte est limitée. Or, avec l'évolution des programmes exécutés par les cartes, le volume de code correspondant atteint rapidement les limites de stockage en mémoire de la carte. Le mode de réalisation de l'invention résout ce problème en permettant de faire stocker au moins une partie du code destiné à être exécuté par la carte 2 en dehors de celle-ci, tout en restant compatible : d'une part, avec la nécessité d'opérer un contrôle, au niveau de la carte, de la validité de ce code extérieur, et - d'autre part, de ne pas retarder outre mesure l'exécution du programme par ce contrôle. Ce double objectif est atteint par la mise en oeuvre d'un processus de traitement par groupes de signatures des instructions qui autorise des répétitions d'instructions identiques au sein d'un même groupe, tout en se protégeant contre les attaques décrites plus haut. De la sorte, il n'est plus nécessaire de restreindre les groupes, et donc de démultiplier leur nombre, pour éviter de telles répétitions, comme l'oblige la défense selon Bellare décrite supra. Ainsi, étant donné qu'une opération de vérification de signatures est à effectuer pour chaque groupe, le nombre de vérifications, et donc le temps de vérification, peut être réduit pour un ensemble donné d'instructions. Ce gain en temps et en ressources est d'autant plus important que les instructions comportent des répétitions rapprochées, ce qui est notamment le cas avec des boucles d'instructions. La taille du groupe d'instructions peut être alors fixée arbitrairement dans les limites du nombre d'instructions identiques admissibles dans un groupe la décision d'effectuer une vérification de signatures pouvant survenir, par exemple, à chaque phase critique durant une transaction. Une phase critique est typiquement : l'envoi par le destinataire d'informations vers le monde extérieur, une écriture, un effacement, une modification de la mémoire volatile (typiquement EEPROM) du destinataire, l'accès à une variable dont le contenu est considéré confidentiel, et la fin du programme. La figure 2 illustre un exemple de processus d'échange entre la carte 2 et le terminal 4 durant une transaction où la carte exécute du code dont les instructions li et les signatures qui leur correspondent sont stockées dans l'une des mémoires 20, 22 du terminal 4. On suppose que ces instructions et les signatures qui leur correspondent sont stockées dans la mémoire préprogrammée 20 du terminal, qui constitue la mémoire annexe (vis-à-vis de la carte 2), désignée ci-après mémoire hors carte. L'ensemble des instructions, indexées par leurs adresses dans la mémoire hors carte 20, peut constituer une bibliothèque générique d'instructions utilisables pour l'exécution de plusieurs programmes différents, en fonction de la séquence d'adresses demandée. Cependant, afin d'éviter des attaques, différentes signatures contenant une référence à l'identité du programme exécuté sont utilisées. La vérification de signature dans un tel contexte sert à s'assurer, au niveau de la carte 2, que les instructions Ii reçues du terminal sont bien conformes à ce qui est attendu dans le cadre du programme. Par exemple, elle doit permettre de déceler une signature incorrecte ou inexistante qui résulterait d'une tentative de fraude visant à faire exécuter un programme modifié. Pour exécuter la transaction, la carte 2 et le terminal 4 exécutent, chacun de leur côté, du code de sécurisation spécifique aux aspects respectivement de vérification et d'élaboration de signature groupée CYGJ pour un groupe Gj d'instructions. Au niveau de la carte 2, le protocole. de sécurisation utilise les éléments suivants : - P, une fonction algorithmique qui agit sur au moins une variable constituée par la valeur numérique attribuée à une instruction et des données d'identification. La fonction P peut être : i) une fonction dite de"hachage", désignée h (Ii,...), utilisée dans les algorithmes du type Rivest, Shamir, Adelman (RSA), par exemple une fonction dite"hachage de domaine complet" (soit FDH, de l'anglais"full domain hash"). Ce hachage peut être associé à un remplissage (connu sous le terme anglosaxon de"padding", dans lequel des bits de valeur fixe sont ajoutés au mot binaire de l'opérande de la fonction. Ces bits de remplissage sont typiquement ajoutés à une ou chaque extrémité du mot de l'opérande ; ou ii) une fonction dite"système de signature avec récupération" (soit PSS-R, de 11 anglais" signature scheme with recovery"), désignée F (Ii,...) ; - un ensemble d'instructions Il, 12,... Ii,..., It stockées à des adresses Dl, D2,..., Di,..., Dt dans le terminal T4, ainsi que des signatures ci associées à chacune des instructions Ii, stockées à un autre endroit de la mémoire du terminal. Dans ce qui suit, la numérotation (1 à t) en suffixe de la lettre I (ou D pour les adresses) indique l'ordre d'exécution des instructions dans un programme donnée, étant compris qu'il s'agit non pas d'un ordre de stockage séquentiel en mémoire, mais d'un ordre donné par calcul d'adresse suivante réalisé en direct dans la carte suivant l'adresse exécutée ; un nombre R qui constitue un numéro d'identification unique du programme exécuté ; - une clé publique e ; - le nombre N utilisé pour les calculs, en arithmétique mod N, définie plus haut ; et - un nombre variable A qui sert d'accumulateur de produits de résultats successifs dans le registre 12. Au niveau du terminal 4, le protocole de sécurisation utilise les éléments suivants : - la fonction algorithmique P précitée, celle-ci pouvant être une fonction de hachage h (Ii) ou une fonction"système de signature avec récupération" F (Ii) ; - la séquence d'instructions Il, 12,..., Ii,..., It contenue aux adresses correspondantes Dl, D2,..., Di,..., Dt dans la mémoire préprogrammée 20 (ou éventuellement dans la mémoire réinscriptible 22) et les signatures ci qui leur sont associées ; - le numéro d'identification R du programme précité ; - le nombre N précité utilisé pour les calculs en arithmétique mod N ; et - un nombre variable B qui sert d'accumulateur de produits de résultats successifs dans le registre 24. L'ensemble des instructions Il à It (où t est le nombre total des instructions) est divisé en groupes d'instructions devant faire l'objet d'une vérification groupée. Le découpage des groupes peut être réalisé lors de l'exécution par la carte, la clôture d'un groupe étant alors décidé en temps réel en fonction de l'apparition d'une instruction critique définie plus haut. Le nombre m d'instructions contenues dans un groupe est variable d'un groupe à l'autre. En ce qui concerne la taille d'un groupe, la condition imposée est que le nombre d'instructions identiques reste égal ou inférieur à e-1. Le mode de réalisation décrit met en oeuvre une simplification optionnelle de la gestion de la taille maximale des groupes en fixant systématiquement pour celle-ci le nombre maximale e-1 d'instructions identiques, ce qui assure automatiquement que les conditions de sécurisation seront toujours remplies, même avec un groupe composé que d'instructions identiques. Cet allègement de la gestion n'est pas pénalisant dans le pratique, vu que le nombre e-1 peut aisément être rendu suffisamment élevé pour une application considérée. Dans ce qui suit, on désignera par n le nombre d'instructions identiques admissibles dans un groupe d'instructions, soit n = e-1 dans le cas de l'algorithme utilisé. Ce nombre n est donc aussi le nombre maximal d'instructions admissibles dans un groupe donné dans le mode de réalisation décrit. La signature nécessite, par l'auteur de programme, la clé privée d, ce qui fait que seul le détenteur de cette clé d, soit le terminal 4, est à même de signer. Cependant, la vérification d'une signature peut se réaliser avec les éléments de clé publiques (e et N), ce qui permet à tous (ici la carte 2) de vérifier le message signé avec la clé d. Pour un groupe Gj d'instructions données, le processus commence (figure 2) par le positionnement à la valeur 1 des accumulateurs A et B (soit A=l, B=l) respectivement au niveau de la carte 2 et du terminal 4 (étapes E2 et E4 respectivement). Ensuite, la carte demande au terminal de lui transmettre l'instruction Il en lui transmettant l'adresse Dl à laquelle elle se situe dans la mémoire hors carte, soit la mémoire préprogrammée 20 (ou la mémoire réinscriptible 22) du terminal (étape E6). Cette instruction Il est la première de la séquence constitutive du groupe Gj. En réponse, le terminal extrait l'instruction Il de l'adresse Dl indiquée et l'envoie à la carte (étape E8). Ensuite, le terminal 4 extrait de la mémoire la signature de la valeur numérique de cette instruction Il et de données d'identification de cette instruction. Ces dernières ont pour but de permettre d'authentifier l'origine de l'instruction. Plus particulièrement, la signature porte sur une valeur (i. e. une opérande) Oi qui regroupe l'instruction Il et les données d'identification. L'opérande Oi (relative à l'instruction Ii) est obtenue par simple concaténation de l'instruction considérée li et des données d'identification. La concaténation consiste ici à créer un mot binaire en enchaînant le dernier bit d'un mot avec le premier bit du mot suivant, ces mots étant l'expression binaire de l'instruction Ii et des données d'identification. Dans l'exemple considéré, les données d'identification comprennent les éléments suivants : l'adresse Di de l'instruction Ii et le numéro unique P d'identification du programme. Ces éléments Di et P sont concaténés, et le résultat de cette concaténation est concaténé avec l'instruction Ii pour former l'opérande Oi. L'expression mathématique de l'opérande Oi pour le cas général d'une instruction Ii est alors : Oi = Ii)) Di)) R ; où le symbole "##" indique une concaténation. On note que l'algorithme RSA précité requiert que le nombre de bits exprimant l'opérande ai soit inférieur à celui exprimant la valeur de N, laquelle sera choisie en tenant compte de cette exigence. La signature de l'opérande Oi, désignée ai, est donnée par la formule générale : ai = pi (ai) d mod N, (d, N et Pi étant définis plus haut). Les signatures ci sont calculées par le concepteur du programme et stockées avec leurs instructions Ii correspondantes au terminal. Ainsi, pour la première instruction I1, la signature est al = Pl (Il JDljJR) d mod N. Cette signature al est introduite dans l'accumulateur B de produits successifs par l'opération : B : = B. al (étape E10). Au niveau de la carte 2, l'instruction I1 reçue est chargée provisoirement dans le registre 12 afin de permettre de calculer, de son côté, la valeur de la fonction Pl (IljJDljJR). Cette valeur PI est introduite dans l'accumulateur A de produits successifs par l'opération : A : = A. Pl (I1 ## D1 ## R) (étape E12). Ensuite, 11 instruction Il est exécutée dans le cadre normal de son programme applicatif (étape E14). Pour le traitement de l'instruction suivante 12, le processus se déroule de manière en tout point analogue, les étapes correspondantes portant les mêmes références ajoutées d'un symbole prime ('), soit E6'à E141. A l'issue de ce traitement de l'instruction 12, les accumulateurs A et B auront ainsi respectivement les valeurs A = crl. cr2, et B = p1 (I1 ## D1 ## R). P2 (I211 D2J) R). Le processus continue ainsi pour chaque instruction successive Ii de la séquence formant le groupe Gj, i étant la iième instruction traitée, où i vérification de la signature de groupe Gj (étape E16). On note que la terminaison d'un groupe d'instructions est décidée au niveau de la carte 2. Cette décision est gouvernée non pas par d'éventuelles répétitions de messages signés (les messages étant ici les instructions respectives), comme 11 imposerait. la contremesure de l'art antérieur selon Bellare et al, mais purement en fonction d'une stratégie de vérification choisie arbitrairement. Avantageusement, cette stratégie tient compte d'un équilibre judicieux entre la sécurité et le temps total à dédier aux vérifications. La décision (étape E16) peut alors intervenir avant chaque étape critique du programme en cours, par exemple : - avant de modifier en mémoire volatile, - avant écriture, effacement ou modification de la mémoire non volatile, par exemple si la mémoire 20 est en variante sous forme de mémoire rémanente du type programmable, électriquement effaçable, connu par l'acronyme EEPROM ; - l'accès par le programme à une donnée considérée comme sensible par le concepteur du programme ; - la fin du programme ; - etc.. ou, dans un cas extrême, si le nombre total d'instructions accumulées dans un groupe a atteint la limite de n précitée. En effet, la seule condition imposée est que le groupe ne contienne pas plus de e-1 répétitions d'un même message Mi. Dans la pratique, il suffit de choisir pour la clé publique e une valeur suffisamment élevée pour que cette condition n'apparaissent pas comme une restriction. Si la valeur de e est généralement très faible dans la cryptologie classique, par exemple égale à 3, il est relativement aisé de travailler avec des valeurs e bien plus élevées. A titre indicatif, on peut choisir une valeur de e égale à 216+1, ce qui autorise plus de 65.000 répétitions d'instructions dans un même groupe. Un groupe peut ainsi aisément contenir une ou plusieurs boucles à fort degré d'itération d'instructions. A titre d'exemple, la boucle peut être du type"Pour a = 1 à u, exécuter instruction i,". Des valeurs de e encore plus élevées peuvent être envisagées au besoin. Le processus de vérification de signature pour le groupe Gj d'instructions reçues par la carte 2 s'effectue comme suit. La carte demande au terminal de lui envoyer le produit de toutes les signatures o effectuées pour le groupe d'instructions, soit cGj = ni La vérification du groupe Gj consiste alors à déterminer si la condition suivante est satisfaite (étape E22) : e Be = A. (mod N), la valeur de l'accumulateur A à ce stade étant A = nui=1 Pi (Ii) JDij) R). On note que cette opération revient effectivement à vérifier l'hypothèse : est-ce que se = P (m) ? conformément à l'algorithme vérification de signature de groupe utilisé. Si cette condition est satisfaite, il sera considéré qu'il n'y a pas d'erreur dans les signatures (étape E24), et le processus continue avec le groupe d'instructions suivant Gj+1 (étape E26), avec repositionnement des accumulateurs A et B à la valeur 1 (étape E28). En revanche, si cette condition n'est pas satisfaite, il sera considéré qu'il y a erreur dans au moins l'une des signatures (étape E30). La carte 2 procède alors à interrompre le déroulement du programme applicatif et à annuler toutes les opérations effectuées antérieurement dans le déroulement de ce programme (opération E32). Dans l'exemple, il est prévu une étape supplémentaire d'élaboration d'un rapport des conditions d'erreur (étape E34) à des fins de diagnostic. Le fait d'introduire dans les données d'identification un identifiant unique R du programme, selon une caractéristique optionnelle de l'invention, offre une sécurité accrue contre les attaques. Cette disposition permet notamment de déjouer des tentatives consistant à combiner des éléments de différents programmes pour créer des séquences d'instructions illicites. A titre d'exemple, un fraudeur pourrait avoir accès à des instructions et à leur adresse associée telles que connues par la carte, mais provenant de différents programmes. S'il tente de créer par"mosaïque"un programme hybride basé sur ces instructions, les différents identifiants des programmes source fausseraient la signature groupée, et la fraude serait ainsi détectée. L'invention a été décrite dans le cadre d'une transaction entre une carte à puce 2 ou autre dispositif et un terminal 4. Elle offre alors des avantages remarquables, dont la possibilité de faire stocker des données propres au fonctionnement du dispositif, telles que des instructions d'un programme exécuté par le dispositif, dans une mémoire annexe 20 ou 22, d'où une levée de la contrainte de capacité de mémoire sur carte, sans pour autant compromettre la sécurisation des données ou la vitesse d'exécution par des vérifications trop fréquentes. Il est cependant clair que l'invention peut être mise en oeuvre dans de nombreuses autres applications et dans d'autres contextes en dehors des considérations de capacité de stockage limitée d'un dispositif communicant. Elle peut par exemple servir à améliorer la vitesse et la sécurité d'échange de données entre tout groupe de terminaux communicants, quelle que soit leur nature (ordinateurs, périphériques, microcontrôleurs, etc. ) ou les liens de communications (filaire, hertzien, satellite, réseau, etc.). Enfin, on comprendra que tout type de données peuvent faire l'objet du processus de signature conforme à l'invention : instructions, valeurs, paramètres, sorties de capteurs, commandes, etc. Il sera maintenant décrit une mise en oeuvre optionnelle qui permet d'accélérer de déroulement de l'exécution d'un programme lorsque le dispositif qui l'exécute reçoit les instructions du programme à partir d'un autre dispositif, désigné source, avec lequel il existe une communication bidirectionnelle. Il peut s'agir notamment, mais pas exclusivement, du mode de réalisation illustré aux figures 1 et 2, où une carte à puce exécute des instructions provenant d'un terminal avec lequel il peut communiquer. Cette mise en oeuvre est basée sur l'idée que si la source d'instructions ne peut pas toujours prévoir l'instruction suivante à transmettre pour exécution, elle peut néanmoins se baser sur un choix restreint d'hypothèses pour cette instruction suivante. On rappelle que l'organisation du stockage en mémoire des instructions d'un programme est normalement telle que les instructions à exécuter obligatoirement (ou possiblement) à la suite sont stockées à des adresses que la source accédera d'elle-même de manière successive selon une liste préétablie, s'agissant typiquement d'adresses consécutives. Cependant, un programme comporte généralement en outre des instructions dont l'ordre d'exécution ne peut correspondre à un ordre préétabli d'accès en mémoire, s'agissant notamment d'instructions de saut ou de branchement conditionnels. Du fait que la source ne possède pas tous les éléments que possède la carte, comme par exemple les variables, elle ne peut savoir dans le cas de certains tests si la prochaine instruction à fournir correspond ou pas à l'instruction suivante selon sa liste préétablie. Pour tenir compte de cette absence de prédictibilité, on peut envisager que le dispositif d'exécution du programme fournisse systématiquement à la source l'adresse de l'instruction. Toutefois, une telle approche grèverait considérablement le temps de chargement et la quantité d'informations à stocker sur le dispositif d'exécution du programme. Pour surmonter ce problème, la mise en oeuvre établit un premier protocole de chargement de la source d'instructions au dispositif qui les exécutent selon lequel ce dernier indique à la source, après chaque instruction reçue, si la prochaine instruction à fournir est la suivante selon sa liste préétablie ou une autre instruction. L'indication se fait par un message qui est plus court que la désignation de l'adresse de l'instruction elle-même, ce qui réduit d'autant la quantité de données émise par le dispositif d'exécution. Avantageusement, l'indication étant de nature dichotomique, elle est émise sous forme d'un bit dont l'état logique spécifie si l'instruction à fournir est ou non celle qui succède dans la liste préétablie de la source. La figure 3 indique les étapes d'échange de données lors d'une exécution conforme au premier protocole. On commence avec l'envoi par le dispositif d'exécution de programme, par exemple la carte 2, d'un ordre de début de chargement d'instructions (étape. P2) à destination de la source d'instructions, par exemple le terminal 4. A réception de cet ordre (étape P4), la source positionne à l'adresse de début le pointeur de mémoire à laquelle sont stockées les instructions (étape P6). Cette adresse est établie selon une convention établie, et se trouve être 0000 dans l'exemple. Ensuite, la source 4 envoie la première instruction du programme, située à l'adresse 0000 fixée par le pointeur (étape P8). A réception de cette instruction, le dispositif 2 l'exécute (étape P10) et détermine si la prochaine instruction qu'il doit exécuter se situe ou non à l'adresse suivante de la mémoire de programme (étape P12). La réponse dépend notamment de la nature de l'instruction venant d'être exécutée ; par exemple si cette instruction comprend une commande d'exécution d'un saut (instruction dite de type"jump"), l'instruction suivante se situera non pas à l'adresse incrémentale suivante de la mémoire mais à une adresse cible spécifiée dans l'instruction même. Si le dispositif d'exécution 2 détermine à l'étape P12 que la prochaine instruction à exécuter est simplement celle à l'adresse suivante de la mémoire de programme, il positionne un bit indicateur Z à la valeur Z=l (étape P14) et envoi l'indicateur Z=1. A l'inverse, si le dispositif détermine que la prochaine instruction à exécuter n'est à l'adresse suivante de la mémoire de programme, il positionne l'indicateur Z à la valeur Z=0 (étape P18), puis désigne nommément l'adresse à laquelle se situe cette prochaine instruction, soit l'adresse de l'instruction suivante désignée AISD (étape P20), et envoi à la source l'indicateur Z=0 suivi de l'adresse AISD (étape P22). La source 4, après envoi d'une instruction (étape P8), reste en attente de la réception de l'indicateur Z (étape P24). Dès que celui-ci est reçu, elle agit selon sa valeur (étape P26) comme suit : si l'indicateur Z a la valeur Z=I, elle positionne son pointeur mémoire à l'adresse incrémentale suivante (étape P28) ; - si l'indicateur Z a la valeur Z=0, elle détecte l'arrivée de l'adresse AISD transmise (cf. étape P22) et positionne son pointeur mémoire à cette adresse AISD (étape P30). La position du pointeur spécifiant l'adresse de l'instruction suivante transmise, le processus reboucle après l'étape P28 ou P30 sur l'étape P8 d'envoi de l'instruction de l'adresse pointeur. Le processus est ainsi itéré pour chaque instruction transmise. On comprend que cette approche est avantageuse du fait qu'elle ne requiert que l'envoi d'un bit après chaque instruction pour confirmer ou infirmer l'envoi systématique de l'instruction correspondant à l'adresse incrémentale suivante de la mémoire de la source. Selon un deuxième protocole, on confère à la source la possibilité de lire les instructions au point de lui permettre d'y identifier, le cas échéant, une adresse possible d'instruction suivante à transmettre. Il existe en effet des types d'instructions, notamment celles du type conditionnel connu par le terme"if" (si), qui initient un branchement conditionnel dans le déroulement du programme. Typiquement, ce type d'instruction offre seulement deux possibilités quant à l'instruction suivante à fournir : celle à l'adresse incrémentale suivante dans la source si une condition spécifiée est satisfaite (ou non satisfaite) et une autre instruction désignée explicitement au sein de cette instruction dans le cas contraire. Ainsi, après réception d'un tel type d'instruction, le dispositif d'exécution peut signaler à la source laquelle des deux instructions possibles doit être transmise. La figure 4 indique les étapes d'échange de données lors d'une exécution conforme au deuxième protocole. Dans l'exemple, les étapes déjà décrites dans le cadre du premier protocole portent les mêmes références et ne seront pas décrites à nouveau par souci de concision. L'exemple commence par l'étape P8 d'envoi d'une instruction de l'adresse désignée par le pointeur de la mémoire programme de la source 4 vers le dispositif d'exécution 2. Après exécution de cette instruction, le dispositif procède aux étapes P12, P14 et P16 précitées si la prochaine instruction à exécuter se trouve à l'adresse incrémentale suivante de la mémoire, ou aux étapes P12 et P18 dans le cas contraire. Seulement, après l'étape P18, le dispositif ne désigne pas d'adresse spécifique, car il est entendu que le positionnement de Z à la valeur 0 commandera à la source de chercher l'adresse suivante à transmettre dans l'instruction qu'elle vient de transmettre. Ainsi seulement la valeur Z=0 est transmise (étape P32). Au niveau de la source, si le bit Z venant d'être reçu a la valeur Z=l, on procède à l'étape P28 et on reboucle sur l'étape P8 pour un nouvel envoi d'instruction, comme pour le premier protocole. Si le bit Z venant d'être reçu a la valeur Z=0, la source lit l'adresse spécifiée dans l'instruction dernièrement envoyée, désignée adresse ASIE, (étape P34), et positionne son pointeur mémoire à cette adresse ASIE (étape P36). Ensuite, le processus reboucle sur l'étape P8 comme pour le premier protocole. On note que l'on peut mettre en oeuvre l'un seulement des premier et deuxième protocoles, ou les deux. Dans ce dernier cas, on peut prévoir diverses techniques permettant à la source d'identifier si la réception du bit Z à l'état Z=0 relève du premier protocole (soit de l'étape P22) ou du deuxième protocole (soit de l'étape P32). A titre d'exemple, on peut exploiter le fait que si les premier et deuxièmes protocoles sont mis en oeuvre pour un transfert d'instructions, la source est prévue pour lire d'éventuelles adresses contenues au sein des instructions qu'elle envoie, conformément au deuxième protocole. On peut prévoir que la source lit les adresses contenues dans les instructions qu'elle envoie et détecte les deux cas suivants : cas 1 : l'instruction envoyée contient deux adresses, et - cas 2 : l'instruction envoyée contient plus de deux adresses, afin de réagir différemment en fonction du cas qui se présente. Si la source détecte le cas 1, on se base sur l'hypothèse que l'une des deux adresses est simplement l'adresse incrémentale suivante de la mémoire de la source. Cette adresse est aisément identifiable puisqu'il s'agit typiquement de l'adresse de l'instruction lue par la source augmentée d'une unité d'adressage. La source applique alors le deuxième protocole (figure 4) pour ce cas 1, en envoyant comme prochaine instruction : - celle qui figure à cette adresse incrémentale suivante si l'indicateur Z a la valeur Z=l, ou - celle qui figure à l'autre adresse si l'indicateur Z a la valeur Z=0. Si la source détecte le cas 2, on retient toujours l'hypothèse que l'une des adresses est simplement l'adresse incrémentale suivante de la mémoire de la source. La source applique alors le premier protocole (figure 3) pour ce cas 2, en envoyant comme instruction suivante : - celle qui figure à cette adresse incrémentale suivante si l'indicateur Z a la valeur Z=l, ou - celle qui est explicitement désignée par le dispositif d'exécution de programme si l'indicateur Z a la valeur Z=0. On peut en outre prévoir un troisième protocole qui s'applique dans un troisième cas (cas 3) lorsque l'instruction envoyée ne comporte qu'une seule adresse. La source applique alors l'hypothèse que la prochaine instruction à envoyer est obligatoirement celle contenue à cette unique adresse. Il est donc inutile d'utiliser un indicateur. La source peut ainsi transmettre la prochaine instruction immédiatement sans qu'elle y soit invitée par dispositif d'exécution de programme de transmettre. Ces protocoles peuvent être étendus à tout type d'instruction dont l'instruction suivante à transmettre est susceptible d'être déterminée en interne au niveau de la source, et ce quelque soit le nombre d'instructions suivantes possibles. S'il existe plus de deux possibilités, on peut alors prévoir un codage de l'indication fournie par le dispositif d'exécution non pas sur un bit, mais plusieurs bits permettant d'identifier l'instruction suivante à fournir depuis la source selon un formalisme prédéterminé. On aura alors une variante du cas 2 (ou du premier protocole) précité selon laquelle le dispositif d'exécution de programme envoie à la source non pas l'adresse explicite AISD à l'étape P22 mais un mot binaire qui spécifie par exemple le rang de l'adresse de la prochaine instruction dans une suite d'adresses d'instructions contenue dans l'instruction courante. Il apparaît de ce qui précède que l'exécution du premier protocole (cas 2) ou du deuxième protocole (cas 1) dépend surtout du fait qu'il y a respectivement plusieurs adresses ou une seule adresse d'instruction possible pour la prochaine instruction si celle-ci ne doit pas être la suivante qui figure dans la liste incrémentale de la source. Ainsi, pour reprendre les exemples cités basés sur les instructions du type "jump"et"if", une instruction de type"jump" n'implique pas forcément le premier protocole et une instruction de type"if"n'implique pas forcément le deuxième protocole. En effet, certaines instructions de type"jump"peuvent tout aussi bien faire appel au deuxième protocole si elles ne comprennent que deux prochaines instructions possibles (dont la suivante dans ladite liste) ou au premier protocole si elles comprennent un nombre X supérieur à deux prochaines instructions possibles. La même remarque s'applique aux instructions du type"if", et généralement à toute autre instruction pour lesquelles ces protocoles peuvent être utilisés. On comprendra que les premier et deuxième protocoles se combinent avantageusement avec le procédé et dispositif de vérification décrits plus haut, mais peuvent également être appliqués en dehors d'une telle vérification, leurs domaines s'étendant à toutes applications impliquant une transmission d'instructions d'une source vers un dispositif d'exécution. REVENDICATIONS 1. Procédé de sécurisation d'éléments de données (Ii), transmis depuis une source (4) à au moins un destinataire (2), par vérification de signature groupée (cGj), le procédé consistant à constituer au moins un groupe (Gj) d'éléments de données (Ii) et, pour chaque groupe : au niveau de la source (4), à : - avoir à disposition la signature de chaque élément de données ; - combiner (E10) les signatures obtenues pour chaque élément du groupe pour réaliser une signature groupée (Gj) ; transmettre (E20) la signature groupée au destinataire (2) ; et au niveau du destinataire (2), à : - soumettre (E12) chaque élément de données (Ii) du groupe reçu à un calcul algorithmique ; - combiner (E12) les valeurs résultant du calcul algorithmique de chaque élément du groupe pour obtenir une valeur globale ; - obtenir (E22) à partir de la valeur globale une valeur de vérification, et - comparer (E22) la valeur de vérification avec la signature groupée, caractérisé en ce que, lors de la constitution d'un groupe (Gj), on autorise, le cas échéant, la présence d'éléments de données (Ii) identiques dans un même groupe. 2. Procédé selon la revendication 1, caractérisé en ce qu'au moins certains des éléments de données sont des instructions (Ii) d'un programme à exécuter au niveau destinataire (2). 3. Procédé selon la revendication 1 ou 2, caractérisé en ce que, pour chaque élément de données (Ii), la signature est réalisée sur un ensemble (Oi) constitué dudit élément de données (Ii) et d'au moins une donnée d'identification (Di, R) associée à cet élément. 4. Procédé selon la revendication 2 et 3, caractérisé en ce que ladite au moins une donnée d'identification comprend une identification (R) spécifique au programme auquel est associée l'instruction (Ii) à signer. 5. Procédé selon la revendication 2 et 3 ou selon la revendication 4, caractérisé en ce que ladite au moins une donnée d'identification comprend l'adresse (Di) à laquelle est stockée l'instruction à signer. 6. Procédé selon l'une quelconque des revendications 3 à 5, caractérisé en ce que ledit ensemble est formé par la concaténation des bits formant un élément de données (Ii) et la ou chaque donnée d'identification (Di, R) associée à cet élément. 7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que la signature est du type RSA (Rivest, Shamir, Adelman), selon laquelle : - la signature correspond, pour un élément de données de rang i, à ci = P (oi) d mod N, où P est soit : i) une fonction dite de"hachage", éventuellement associée à un remplissage, soit ii) une fonction dite "système de signature avec récupération", Oi est une opérande comprenant l'élément de données et, le cas échéant, au moins une donnée d'identification, d est une clé privée, et mod N désigne l'arithmétique en modulo N, où N est un nombre prédéterminé ; - l'étape de combiner consiste à multiplier ensemble toutes les signatures d'un groupe de m éléments, ladite signature groupée pour un groupe aGj étant donnée par aGj = rli., à m ci ; - l'étape de soumettre les éléments de données à un calcul algorithmique consiste à évaluer la valeur rendue par ladite fonction P, celle-ci étant la même que celle utilisée pour l'étape de signer, pour le cas de P (Oi) ; - l'étape de combiner les valeurs consiste à multiplier ensemble toutes les valeurs de P (ai) d'un groupe, ladite valeur globale étant donnée par ITi à m Pi (oi) ; - l'étape d'obtenir une valeur de vérification consiste à élever ladite valeur globale à la puissance d'une clé publique e ; et - l'étape de comparer consiste à vérifier s'il y a égalité entre ladite valeur de vérification et ladite signature groupée, en arithmétique modulo N. 8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que l'on établit une limite au nombre d'éléments identiques dans un même groupe (Gj) sur la base d'un paramètre arbitraire utilisé pour l'étape d'obtention de la valeur de vérification. 9. Procédé selon la revendication 8, caractérisé en ce que ledit paramètre arbitraire est la valeur attribuée à une clé publique e, le nombre limite n d'éléments de données identiques admis dans un groupe (Gj) étant égal à e-1. 10. Procédé selon la revendication 9, caractérisé en ce que la clé publique est fixée à une valeur suffisamment élevée, par exemple 216+1, pour qu'elle ne conditionne pas dans la pratique l'étendue d'un groupe (Gj) lors de ladite constitution de ce groupe. 11. Procédé selon l'une quelconque des revendications 1 à 10, caractérisé en ce que ledit destinataire est un dispositif portatif communicant (2) et la source est un terminal (4). 12. Procédé de sécurisation de l'exécution d'un programme par transmission d'instructions à exécuter d'une source (4) à un destinataire (2) qui les exécutent consistant, à : - constituer, au niveau de destinataire, au moins un groupe (Gj) d'instructions reçues de la source ; - procéder à ladite sécurisation du groupe d'instructions par le procédé de vérification selon l'une quelconque des revendications 2 à 11. 13. Procédé selon l'une quelconque des revendication 2 à 12, caractérisé en ce que le destinataire (2) demande ladite signature groupée (Gj) lorsque le programme atteint une phase critique en ce qui concerne les conséquences de l'exécution d'une instruction reçue. 14. Procédé selon la revendication 13, caractérisé en ce que ladite phase critique est identifiée par au moins l'un des évènements suivants : - l'envoi d'information depuis le destinataire (2) vers le monde extérieur, - l'écriture, l'effacement ou la modification d'une mémoire non volatile, notamment d'une mémoire de lecture effaçable électriquement (EEPROM) du destinataire, - l'accès par le programme exécuté à une donnée considérée comme sensible par le concepteur du programme ; et 1 - la fin du programme. 15. Dispositif communicant portatif (2), caractérisé en ce qu'il constitue ledit destinataire dans le procédé selon l'une quelconque des revendications 2 à 14, le dispositif comportant : - des moyens (6) d'exécution d'instructions ; une interface de communication (14) avec la source (4) ; - des moyens (6) pour exécuter les instructions reçues depuis la source (4) ; - des moyens (6,8, 10) pour spécifier au moins un groupe (Gj) d'instructions destinées à être soumises à une signature groupée, dont possiblement un groupe contenant des instructions identiques ; et des moyens (6,12) de vérification d'une signature de groupe. 16. Dispositif selon la revendication 15, caractérisé en ce qu'il s'agit d'une carte à puce (2). 17. Dispositif communicant, caractérisé en ce qu'il constitue ladite source (4) dans le procédé selon l'une quelconque des revendications 2 à 14, le dispositif comportant : une interface de communication (26) avec le destinataire (2) ; des moyens de stockage (20 ; 22) comportant lesdites instructions (Il, 12,...) et des signatures qui leur sont associées ; - des moyens (18) pour transmettre au destinataire (2) une des instructions (Il, 12,...) en fonction de l'exécution du programme ; et - des moyens (18,24) pour réaliser, pour un groupe d'instructions transmises, une signature groupée des instructions et éventuellement de leurs données d'identification. 18. Dispositif selon la revendication 17, caractérisé en ce qu'il introduit une identification de programme (R) pour constituer les données d'identification. 19. Procédé de gestion d'instructions d'un programme à exécuter par un dispositif communicant, caractérisé en ce qu'il consiste à : - stocker au moins une partie desdites instructions au niveau d'une source (4) extérieure au dispositif communicant (2), - établir, lors d'une phase d'exécution dudit programme, une liaison permettant le transfert des instructions de la source vers le dispositif au fur et à mesure de l'avancement de l'exécution dudit programme, avec mise en oeuvre du procédé de vérification selon l'une quelconque des revendications 1 à 14 des instructions transmises.