FR 3013477 A1 20150522 FR 1361482 A 20131121 DOMAINE DE L'INVENTION L'invention concerne le domaine de la cryptographie. Elle concerne plus particulièrement un procédé et un système pour la vérification de la validité d'une signature numérique de message. CONTEXTE DE L'INVENTION Les mécanismes de signature et de vérification de signature permettent de certifier l'origine de données échangées entre deux dispositifs. Les données peuvent par exemple être des messages contenant des informations fournies par un dispositif d'origine vers un dispositif de destination. Par exemple encore, les données peuvent être une application transmise par un dispositif d'origine à un dispositif de destination pour l'exécution de l'application par ce dernier. De manière générale, ainsi que dans ce qui suit, il est fait référence à un message échangé entre le dispositif d'origine et le dispositif de destination, bien que les données échangées peuvent être d'une autre nature. Lorsque le dispositif d'origine transmet un message à un dispositif de destination, il lui adjoint des données (la « signature » du message) qui vont permettre au dispositif de destination de vérifier que le message émane bien du dispositif d'origine. Le mécanisme de signature permet ainsi au dispositif de destination, si la signature est valide, de faire confiance au message reçu. Par exemple, si le message reçu est une application, le dispositif d'origine peut l'exécuter sans risque. A contrario, si un message non signé ou signé avec une signature non valide est reçu, il n'est pas traité (ou pas exécuté s'il s'agit d'une application) afin de ne pas compromettre la sécurité du dispositif. Par exemple, l'ECDSA (pour « Elliptic Curve Digital Signature Algorithm ») et le RSA (pour « Rivest Shamir Adleman »), sont des mécanismes de signature connus, réputés difficiles à contourner. Une attaque possible contre les mécanismes de signature est de tenter de retrouver la signature du dispositif d'origine pour l'adjoindre à des données afin de leur donner l'apparence d'une origine qu'elles n'ont pas. Ainsi, par exemple, il est possible de faire exécuter des applications par un dispositif de destination en lui faisant croire que les applications proviennent d'un dispositif d'origine de confiance alors que ce n'est pas le cas. Pour éviter de telles attaques, les mécanismes de signature mettent en oeuvre des procédés permettant notamment de complexifier la tâche consistant à calculer la signature et en particulier de rendre inefficace la recherche de la signature par essais aléatoires. De façon générale, les calculs cryptographiques mis en oeuvre dans la vérification de signature sont complexes et requièrent une puissance et une capacité de calcul conséquentes. A titre d'exemple, l'ECDSA sur la courbe elliptique P-192, normalisée par le NIST (National Institute of Standards and Technology) met en jeu une double multiplication scalaire requérant l'exécution de 3584 multiplications modulaires sur un corps de Galois GF(p) où p est un nombre premier de 192 bits. L'algorithme de signature RSA 1024, quant à lui, repose sur une exponentiation modulaire requérant l'exécution de 1536 multiplications modulaires entre des nombres de 1024 bits. Or, les dispositifs sécurisés mettant typiquement en oeuvre les calculs de vérification de signature peuvent être limités en capacité de calcul. Par exemple, certains composants classiquement utilisés pour vérifier les signatures disposent d'une mémoire vive (RAM) d'au plus 32Ko et d'une unité de traitement (CPU) fonctionnant en moyenne à 30MHz, alors que ces composants peuvent être intégrés dans des téléphones portables avec par exemple 2Go de mémoire vive et avec des processeurs par exemple 4 coeurs fonctionnant à plus de 2GHz. Dans ce contexte, il est intéressant de pouvoir déléguer ces calculs de vérification à des dispositifs plus puissants. Cette délégation est particulièrement intéressante lorsque le dispositif sécurisé fonctionne en association avec un autre dispositif dont la capacité de calcul est plus grande. Par exemple, le dispositif sécurisé peut être une clé USB sécurisée (token) branchée sur un PC. Par exemple encore, les calculs de vérification peuvent être délégués à un dispositif hôte accueillant le dispositif sécurisé. De façon générale, les dispositifs plus puissants chargés de faire une partie des calculs de vérification délégués peuvent ne pas être sécurisés, c'est-à-dire qu'un attaquant peut accéder et modifier les données manipulées par ces dispositifs. Ils peuvent ainsi être particulièrement exposés aux attaques. L'avantage associé à la délégation de calcul en termes de charge de calcul peut alors être obtenu au prix de compromettre la sécurité du mécanisme de signature. Au cours d'un calcul de vérification de signature mis en oeuvre par un dispositif auquel il est délégué, un attaquant peut modifier les données manipulées et ainsi provoquer par exemple la validation artificielle d'une signature alors que celle-ci est erronée, typiquement dans le but de faire exécuter une application malveillante. Ainsi, il existe un besoin pour améliorer la sécurité des calculs de vérification de signature numérique, notamment dans le cas où ceux-ci sont délégués à un dispositif non sécurisé. La présente invention s'inscrit dans ce cadre. RESUME DE L'INVENTION Un premier aspect de l'invention concerne un procédé de vérification de la validité d'une signature numérique de message, comportant les étapes suivantes : - de détermination de premières données de signature de message, - de transmission, à un dispositif de calcul, de deuxièmes données de calcul basées sur les premières données de signature de message, - de réception, de la part du dispositif de calcul, d'un résultat intermédiaire de calcul sur les deuxièmes données, et - de vérification de (ou de délibération sur) la validité de la signature à partir du résultat intermédiaire. Selon l'invention, ce procédé de vérification comporte en outre une étape de masquage, d'au moins une partie des premières données de signature de message, à partir d'au moins une donnée de masquage, et l'étape de vérification (ou de délibération) fait intervenir cette donnée de masquage. Ainsi, une partie des calculs de vérification est déléguée au dispositif de calcul, sans pour autant que celui-ci ait accès à des données sensibles permettant à un attaquant de parvenir artificiellement à la validation d'une (fausse) signature. En effet, il sera très difficile pour un attaquant de retrouver la signature numérique pour l'adjoindre à des données afin de donner l'impression qu'elles proviennent d'un dispositif de confiance. De plus, l'invention permet de bénéficier des avantages associés à la délégation de calcul en termes de charge de calcul, sans toutefois compromettre la sécurité du mécanisme de vérification de signature, notamment lorsque le dispositif de calcul n'est pas sécurisé. Le procédé est par exemple mis en oeuvre par un dispositif sécurisé dont la capacité de calcul est plus faible que la capacité de calcul dudit dispositif de calcul. La vitesse d'exécution ou de réalisation du mécanisme (global) de vérification en est ainsi globalement augmentée. En outre, les capacités de calcul du dispositif sécurisé peuvent ainsi être dédiées entièrement aux tâches de sécurité (e.g. validation finale ou délibération sur la validité de la signature en fonction du résultat des calculs) sans être monopolisées par une charge trop importante de calcul. Les calculs sur les deuxièmes données par le dispositif de calcul comprennent par exemple une opération d'exponentiation modulaire, et/ou une opération de multiplication scalaire. Ces deux opérations sont réputées coûteuses en termes de calculs. Ainsi, par exemple dans le cas d'une signature de type RSA, le résultat intermédiaire de calcul peut être obtenu au moins à partir d'une opération d'exponentiation modulaire sur les deuxièmes données. En variante, par exemple dans le cas d'une signature sur courbe elliptique (e.g. ECDSA), le résultat intermédiaire de calcul peut être obtenu au moins à partir d'au moins une multiplication scalaire sur les deuxièmes données. Par exemple, le résultat intermédiaire de calcul est obtenu au moins à partir d'au moins une double multiplication scalaire sur les deuxièmes données. Selon des modes de réalisation, l'étape de vérification comprend : - une étape de démasquage de ladite au moins une partie des premières données masquée au cours de l'étape de masquage, - une étape d'application d'une première fonction cryptographique au résultat de l'étape de démasquage, et - une étape de comparaison du résultat intermédiaire de calcul avec le résultat de l'application de la première fonction cryptographique. Le procédé peut ainsi être mis en oeuvre même dans les cas où le message n'est pas reçu par le dispositif sécurisé via un canal de communication sécurisé avec le fournisseur de la signature (i.e. le dispositif signataire ou le dispositif d'origine). En outre, le masquage et le démasquage du message peuvent se faire via l'utilisation d'une donnée de masquage basée sur un secret partagé entre l'entité d'origine émettant le message (e.g. le signataire) et l'entité de destination le recevant (dispositif sécurisé). Selon des modes de réalisation, les deuxièmes données de calcul transmises au dispositif de calcul au cours de l'étape de transmission peuvent correspondre au résultat de l'étape de masquage. Par exemple, les deuxièmes données peuvent comporter ou être fonction du résultat de l'étape de masquage. Selon des modes de réalisation, l'étape de vérification comprend : - l'étape de masquage précitée, laquelle comprend l'application d'une deuxième fonction cryptographique à au moins une partie des premières données de signature de message, et le masquage du résultat de l'application de la deuxième fonction cryptographique, à partir de la donnée de masquage précitée, et - une étape de comparaison du résultat intermédiaire de calcul avec le résultat du masquage. Par exemple, l'étape de vérification comprend une étape de comparaison du résultat intermédiaire de calcul avec la donnée de masquage. La donnée de masquage étant par exemple un nombre aléatoire très grand (typiquement supérieur à 100 bits), la probabilité qu'un attaquant tombe précisément sur cette donnée est très faible. C'est pourquoi il peut être avantageux de s'en servir comme élément de comparaison pour déterminer si la signature est valide ou non. Selon des modes de réalisation, l'étape de détermination comprend la réception des premières données de signature de message. Par exemple, la partie des premières données de signature de message masquée au cours de l'étape de masquage sont reçues par un dispositif sécurisé dont la capacité de calcul est plus faible que la capacité de calcul du dispositif de calcul, et les étapes de transmission de deuxièmes données, de réception d'un résultat intermédiaire et de vérification de la validité de la signature sont mises en oeuvre dans le dispositif sécurisé. Un deuxième aspect de l'invention concerne un programme d'ordinateur ainsi qu'un produit programme d'ordinateur et un support de stockage pour de tels programme et produit, permettant la mise en oeuvre d'un procédé selon le premier aspect lorsque le programme est chargé et exécuté par un processeur d'un dispositif informatique. Le support peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comprendre un moyen de stockage, tel qu'une ROM, par exemple une ROM de microcircuit, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur, ou encore une mémoire flash. D'autre part, le support peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur une plateforme de stockage d'un réseau de type Internet. Alternativement, le support peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Un troisième aspect de l'invention concerne un dispositif pour la vérification de la validité d'une signature numérique de message, comportant : - un module de réception de premières données de signature de message, - un module de transmission, à un dispositif de calcul, de deuxièmes données de calcul basées sur les premières données de signature de message, - un module de réception, de la part du dispositif de calcul, d'un résultat intermédiaire de calcul sur les deuxièmes données, et - un module de vérification de (ou de délibération sur) la validité de la signature à partir du résultat intermédiaire. Selon l'invention, au moins une partie des premières données de signature de message sont masquées à partir d'au moins une donnée de masquage, et le module de vérification (ou de délibération) utilise cette donnée de masquage. Par exemple, le dispositif selon le troisième aspect de l'invention est un dispositif sécurisé. De manière générale, le dispositif sécurisé peut être conforme aux Critères Communs (ISO/CEI 15408) ou à la norme FIPS. Dans des modes de réalisation, le dispositif comprend en outre un module de masquage de ladite au moins une partie des premières données de signature de message à partir de ladite au moins une donnée de masquage. Ainsi, le dispositif peut masquer lui-même une partie des données reçues du dispositif générant la signature du message. En variante, le dispositif peut comporter en outre un module de masquage, d'au moins une partie des premières données de signature de message, à partir d'au moins une donnée de masquage, et le module de vérification (ou de délibération) utilise cette donnée de masquage. Un quatrième aspect de l'invention concerne un système pour la vérification de la validité d'une signature numérique de message, comportant : un module de détermination de premières données de signature de message, un module de transmission, à un dispositif de calcul, de deuxièmes données de calcul basées sur les premières données de signature de message, - un module de réception, de la part du dispositif de calcul, d'un résultat intermédiaire de calcul sur les deuxièmes données, et - un module de vérification de (ou de délibération sur) la validité de la signature à partir du résultat intermédiaire. Selon des modes de réalisation, le système comprend un dispositif sécurisé et un dispositif signataire, le dispositif signataire comprenant le module de détermination des premières données, et le dispositif sécurisé comprenant le module de transmission des deuxièmes données, le module de réception du résultat intermédiaire et le module de vérification du résultat intermédiaire. Le dispositif signataire et le dispositif sécurisé peuvent communiquer via un canal sécurisé de communication. Ainsi, le message et la signature peuvent transiter par ce canal de communication sans forcément être masqués. Par exemple, le système précité comprend le dispositif de calcul. Le dispositif de calcul comprend le dispositif sécurisé. Le dispositif sécurisé peut être une carte à puce (par exemple conforme à la norme ISO 7816, amovible par rapport à un terminal hôte. Cette carte à puce amovible peut être insérée dans un terminal hôte, par exemple un téléphone mobile. En variante, un dispositif sécurisé peut être un élément sécurisé embarqué eSE (pour embedded Secure Element) inamovible par rapport à un terminal hôte (par exemple un téléphone mobile) dans lequel l'eSE serait inséré. Le dispositif sécurisé peut par exemple avoir la fonction d'un module d'identité de souscripteur auprès d'un opérateur de télécommunications (e.g. une UICC pour Universal Integrated Circuit Card, amovible ou embarquée, par exemple une carte SIM ou USIM). Le dispositif de calcul peut être par exemple un terminal hôte (e.g. téléphone mobile) comprenant le dispositif sécurisé. Les échanges entre le dispositif de calcul et le dispositif sécurisé sont par exemple conformes à la norme ISO 7816 et les messages et requêtes échangés sont par exemple des trames APDU. Ainsi, par exemple, lorsque la signature numérique d'un message est valide, un programme (ou une application) contenu(e) au moins en partie (e.g. mise à jour du dispositif sécurisé) dans le message vérifié peut être chargée en mémoire non volatile du dispositif sécurisé ou bien être exécutée dans le dispositif sécurisé. Puis, dans le cas du chargement de l'application ou du programme en mémoire non volatile du dispositif sécurisé, lors de la réception par celui-ci d'une commande (par exemple APDU) visant ce programme (ou cette application), le dispositif sécurisé peut exécuter la commande, par exemple à l'aide du programme (ou de l'application), et renvoyer une réponse (par exemple sous la forme d'une réponse APDU) à cette commande. La réponse à la commande est par exemple formée à partir du résultat du traitement, par le programme (ou l'application), d'une partie des données comprises dans la commande. Par exemple, le dispositif signataire et le dispositif de sécurisation communiquent via un réseau de téléphonie mobile. Les avantages, buts et caractéristiques particuliers du dispositif, du système, du programme d'ordinateur et du support d'informations sont similaires à ceux du procédé selon le premier aspect. BREVE DESCRIPTION DES FIGURES D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après, illustrée par les figures ci-jointes qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures : - Les Figures la et lb illustrent des exemples de contexte de mise en oeuvre de modes de réalisation, - La Figure 2 représente un exemple d'architecture pour les dispositifs représentés sur les Figures la et 1 b, - La Figure 3 représente les étapes générales d'un procédé de vérification conforme à l'invention, - Les Figures 4 à 7 représentent des étapes de procédés de vérification selon des modes de réalisation. DESCRIPTION DETAILLEE DE L'INVENTION La Figure la illustre un contexte de mise en oeuvre de modes de réalisation. Un dispositif 10a génère un message à destination d'un dispositif 14a. Afin de permettre au dispositif 14a de vérifier l'origine du message, le dispositif 10a lui adjoint une signature numérique. Le dispositif 10a sera appelé dispositif signataire 10a. Le dispositif 14a est en charge de la vérification de la validité de la signature numérique du message. Afin d'éviter les attaques pouvant consister à « forcer » la vérification positive de la validité de signatures ne provenant pas du dispositif 10a, le dispositif 14a est sécurisé. Afin d'alléger la charge de calcul du dispositif sécurisé 14a, une partie des calculs de vérification sont délégués, de manière sécurisée, à un dispositif de calcul 12a, présentant une puissance de calcul plus importante que le dispositif sécurisé 14a habituellement en charge de la vérification. Ainsi, le système de la Figure la comporte un dispositif signataire 10a (dispositif d'origine du message et de la signature), un dispositif sécurisé 14a (dispositif de destination du message et de la signature) et un dispositif de calcul 12a. Par exemple, le dispositif sécurisé 14a est un dispositif déporté tel qu'une clé USB, pouvant être branché à un dispositif de calcul 12a, par exemple un PC. Cependant, les dispositifs 12a et 14a peuvent être intégrés dans un même dispositif. Le dispositif signataire 10a est capable de générer une signature numérique d'un message, et de transmettre la signature numérique et le message au dispositif sécurisé 14a, possiblement sous forme masquée, via un canal sécurisé de communication 16a. En pratique, un canal est dit sécurisé lorsque par les données transmises par ce canal sont encryptées et qu'une clé est nécessaire pour les décrypter. Par exemple, un jeu de une ou plusieurs clés mémorisées par le dispositif signataire et le dispositif sécurisé peut être utilisé pour encrypter et décrypter les données transmises par ce canal. Le canal sécurisé 16a est par exemple établi directement entre les dispositifs 10a et 14a. Il s'agit par exemple d'un canal de communication RF (Radio fréquence), infrarouge, ou par connexion filaire (par exemple selon le protocole USB), ou autre. La Figure lb illustre un autre contexte de mise en oeuvre de modes de réalisation. Un dispositif 10b transmet un message signé à un dispositif sécurisé 14b intégré à un dispositif hôte 12b. Par exemple, le dispositif 14b est un module d'identification de souscripteur à un réseau 16b (par exemple une carte SIM) et le dispositif 12b est un terminal mobile (e.g. téléphone mobile intelligent ou Smartphone en anglais). Les dispositifs 10b et 14b communiquent via le réseau 16b. Le réseau 16b peut être sécurisé ou non. Il s'agit par exemple d'un réseau de communications téléphonique et/ou Internet. Ainsi, dans cet exemple de contexte, le signataire 10b et le terminal mobile 12b communiquent par exemple via le réseau téléphonique 16b, à l'aide du module d'identification 14b. Les contextes illustrés par les Figures la et lb ne sont pas incompatibles. Les caractéristiques présentées dans un contexte peuvent être mises en oeuvre dans l'autre. Le message transmis par le signataire au dispositif sécurisé peut par exemple comprendre un programme (ou une application ou une partie d'application, par exemple une mise à jour). Ce programme peut être sécurisé ou non. Ce programme peut être mémorisé dans une mémoire par exemple non-volatile du dispositif sécurisé, une fois que la signature du message correspondant a été vérifiée par un procédé de vérification conforme à l'invention. Il peut être ensuite exécuté en partie ou entièrement par le dispositif sécurisé. La Figure 2 représente un exemple d'architecture pour les dispositifs de la Figure la ou 1 b, c'est-à-dire le dispositif signataire 10a ou 10b, le dispositif de calcul 12a ou 12b et/ou le dispositif sécurisé 14a ou 14b. Selon cette architecture, un dispositif peut comprendre un bus de communication 2 relié aux éléments suivants : - une unité de traitement 20 notée CPU (sigle de Central Processing Unit en anglais), pouvant comporter un ou plusieurs processeurs; - une ou plusieurs mémoires non volatiles 22 par exemple ROM (acronyme de Read Only Memory en anglais) pouvant constituer un support au sens de l'invention, c'est-à- dire pouvant comprendre un programme informatique comprenant des instructions pour la mise en oeuvre des procédés selon l'invention ; - une mémoire vive 24 ou mémoire cache ou mémoire volatile par exemple RAM (acronyme de Random Access Memory en anglais) comprenant des registres adaptés à l'enregistrement des variables et paramètres créés et modifiés au cours de l'exécution du programme précité ; lors de la mise en oeuvre de l'invention. Les codes d'instructions du programme stocké en mémoire non volatile sont chargés en mémoire RAM en vue d'être exécutés par l'unité de traitement CPU ; - une interface de communication 26 adaptée à transmettre et à recevoir des données, par exemple via un réseau de télécommunications ou une interface de lecture/écriture. C'est par exemple via cette interface que les dispositifs signataire et sécurisé peuvent envoyer/recevoir un message et sa signature. C'est également par cette interface que le dispositif sécurisé peut déléguer les calculs de vérification au dispositif de calcul. De façon optionnelle, cette architecture comprend également une interface d'entrées/sorties 28 I/O (pour Input/Output en anglais), par exemple un écran, un clavier, une souris ou un autre dispositif de pointage tel qu'un écran tactile. Cette interface permet par exemple à un utilisateur de lancer l'exécution d'instructions par l'unité de traitement 20. Le dispositif signataire et/ou le dispositif sécurisé peuvent en outre comprendre un crypto-processeur 29 recevant des instructions de la part de l'unité de traitement 20 pour crypter et/ou décrypter des données, par exemple une signature numérique ou un message. Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité de traitement est susceptible de communiquer des instructions à tout élément du dispositif directement ou par l'intermédiaire d'un autre élément de ce dispositif. La Figure 3 représente les étapes générales d'un procédé de vérification de signature numérique d'un message selon l'invention. Un tel procédé peut être mis en oeuvre par un dispositif sécurisé ou un système de vérification de signature numérique, par exemple tels que décrits en référence aux Figures la, 1b ou 2. Lors d'une étape 300, des premières données de signature de message sont déterminées. Ces premières données peuvent comprendre un ou plusieurs éléments de signature et éventuellement le message correspondant. Notamment, le dispositif signataire peut appliquer une fonction cryptographique au message, de sorte qu'au moins une partie des premières données de signature dépende du résultat de cette fonction. Par exemple, la fonction cryptographique peut être une fonction de hachage (e.g. SHA-1). Cette étape peut aussi être mise en oeuvre au moins partiellement par le dispositif sécurisé, en collaboration avec le dispositif signataire qui génère la signature. Ainsi, l'étape de détermination peut comprendre la réception, par un canal sécurisé entre le dispositif signataire et le dispositif sécurisé, des premières données de signature. Pour simplifier, on utilisera simplement le terme « premières données » pour désigner l'ensemble. En variante, l'étape de détermination peut comprendre la réception par une communication classique (i.e. pas forcément sécurisée) des premières données de signature, accompagnées du message correspondant sous forme masquée. Afin de garantir la sécurité du message, le dispositif signataire et le dispositif sécurisé peuvent partager un secret leur permettant de masquer/démasquer les données échangées (i.e. le message et/ou les données de signature). Le secret partagé peut être par exemple utilisé en entrée d'un générateur de nombre pseudo-aléatoire (en anglais PRNG pour « Pseudo Random Number Generator ») afin d'obtenir des valeurs de masquage/démasquage. Selon des modes de réalisation, les premières données de signature déterminées à l'étape 300 sont masquées au cours d'une étape 310 dans le dispositif signataire puis reçues par le dispositif sécurisé sous forme masquée. En variante, le dispositif sécurisé peut masquer lui-même les premières données reçues. Ainsi, l'étape de masquage 310 est réalisée soit par le dispositif signataire, soit par le dispositif sécurisé, à partir d'une donnée de masquage. La donnée de masquage peut être par exemple un nombre aléatoire (aléa) ou comme expliqué précédemment, un nombre pseudo-aléatoire basé sur un secret partagé entre le dispositif signataire et le dispositif sécurisé. Comme expliqué précédemment, le masquage peut porter sur les données de signature et/ou sur le message lui-même. L'opération de masquage consiste par exemple en une addition faisant intervenir un opérateur de type OU exclusif (aussi appelé XOR). Le procédé comporte en outre une étape de transmission 320 (au dispositif de calcul) de données de calcul (deuxièmes données) basées sur les données de signature (premières données) de message. C'est ainsi qu'une partie des calculs de vérification de signature est déléguée au dispositif de calcul, plus puissant que le dispositif sécurisé. Les données de calcul peuvent être directement une partie des premières données (e.g. signature). En variante, les données de calcul peuvent être issues du masquage des premières données, par exemple par le dispositif sécurisé. Une fois les calculs réalisés avec les deuxièmes données par le dispositif de calcul, le dispositif sécurisé reçoit (étape 330) le résultat correspondant, dit « résultat intermédiaire ». Au cours d'une étape de vérification 340, le résultat intermédiaire est utilisé pour déterminer si la signature numérique du message est valide ou non. La délibération finale (vérification 340) sur la validité de la signature est réalisée dans le dispositif sécurisé. En effet, une partie des calculs de vérification est déléguée au dispositif de calcul, plus puissant, mais la mise en oeuvre de la partie critique des calculs, à savoir la délibération, se fait dans le dispositif sécurisé. Cette étape de vérification 340 peut utiliser directement la donnée de masquage de l'étape de masquage 310 comme élément de comparaison avec le résultat intermédiaire. En variante, l'étape de vérification 340 peut utiliser la donnée de masquage dans des calculs permettant d'obtenir un élément de comparaison avec le résultat intermédiaire. Comme expliqué plus en détail ci-après en référence aux Figures 4 à 7, ce résultat intermédiaire est comparé par exemple au résultat d'une fonction cryptographique appliquée au message m, ou encore à la donnée de masquage (e.g. nombre aléatoire ou pseudo-aléatoire) utilisée dans le masquage 310. Dans la suite de la description, des mises en oeuvre des étapes générales évoquées ci-dessus sont décrites dans le cadre de signatures numériques de type ECDSA et RSA. L'invention ne se limite toutefois pas à ces mises en oeuvre. D'autres types de signature numérique peuvent être mises en oeuvre conformément à des modes de réalisation de l'invention. En outre, les modes de réalisation décrits ci-dessous ne sont pas exclusifs les uns des autres, certaines caractéristiques décrites en regard d'une mise en oeuvre peuvent être utilisées et/ou adaptées pour d'autres mises en oeuvre. En référence à la Figure 4, des étapes d'un procédé de vérification dans le cadre d'une signature de type ECDSA sont décrites. Le procédé peut être mis en oeuvre par exemple dans l'un des systèmes décrits précédemment, entre un dispositif signataire, un dispositif sécurisé et un dispositif de calcul. Au cours d'une étape 400, le dispositif signataire génère une signature (s, r) à partir d'un message m, selon l'algorithme de génération de signature ECDSA. Au cours d'une étape 410, le dispositif sécurisé reçoit le message m avec la signature générée (s, r), l'ensemble étant désigné par 'premières données'. Ces premières données sont reçues par exemple via un canal sécurisé avec le dispositif signataire. Au cours d'une étape 420, une fonction cryptographique h est appliquée au message m reçu à l'étape 410, par le dispositif sécurisé, de sorte que la valeur obtenue h(m) ne permet pas de remonter au message m. La fonction cryptographique h est par exemple une fonction de hachage. Au cours d'une étape 430, le dispositif sécurisé effectue un masquage de la valeur h(m) ainsi que d'une partie des premières données constituée par les éléments de signature s et r, à partir d'une donnée de masquage I. Cette donnée de masquage est par exemple un nombre aléatoire. En pratique, le masquage d'une de ces valeurs (h(m), s ou r) peut se faire par une opération de multiplication modulaire avec la donnée de masquage I. Au cours d'une étape 440, les valeurs masquées à l'étape 430 (désignées par 'deuxièmes données') sont ensuite transmises sous forme masquée au dispositif de calcul. Celui-ci utilise les valeurs masquées reçues pour obtenir un résultat intermédiaire I,'. Le dispositif de calcul procède aux calculs de vérification standards de l'ECDSA, mais sur les valeurs masquées reçues. Ici, les calculs réalisés par le dispositif de calcul visent à retrouver le nombre aléatoire I, utilisé comme donnée de masquage à l'étape 430. Le résultat intermédiaire I,' est ensuite transmis au dispositif sécurisé (étape de réception 460) pour être utilisé pour la vérification de la validité de la signature numérique précitée. Pour ce faire, le dispositif sécurisé compare le résultat intermédiaire I,' avec le nombre aléatoire I, utilisé pour le masquage (à l'étape 430). Lorsque cette comparaison est positive, c'est-à-dire si le résultat intermédiaire I,' et le nombre aléatoire I, correspondent, la signature numérique est considérée comme valide par le dispositif sécurisé. En conséquence, le message afférant est certifié, autrement dit, le dispositif sécurisé (de destination du message) est assuré que le message émane bien d'un dispositif de confiance (le dispositif signataire). Dans ce cas, le message peut être traité sans danger apparent pour le dispositif sécurisé. Au contraire, lorsque le résultat intermédiaire I,' et le nombre aléatoire I, ne correspondent pas, la signature numérique n'est pas validée et le message n'est pas certifié. Il représente potentiellement un danger puisque sa source n'est pas authentifiée par le dispositif sécurisé. Ainsi, l'avantage associé à la délégation des calculs à un dispositif plus puissant (dispositif de calcul) est obtenu sans compromettre la sécurité du mécanisme de signature. Un exemple non limitatif de pseudo code pour l'implémentation de ce mode de réalisation est donné ci-dessous : Dispositif signataire Dispositif sécurisé Dispositif de calcul r= [k]P li = random(21°g2(q))1{0} h = hash(m) s = k-1(h + rd) mod(q) m, s, r-> -> m, s, r h = hash(m) hi = li * h mod(q) si = li * s mod(q) ri = ii * r mod(q) hb sb ri -> -> hb sb ri r= [5i4 hiy + [sil t'in li' = ri * ri mod(q) Ij'+_ et Ces modes de réalisation peuvent facilement être implémentés avec les signatures obtenues par des algorithmes classiques de fourniture de signature comme l'ECDSA. En effet, seul le mécanisme de vérification de la signature est modifié. En pratique, afin de garantir un niveau optimal de sécurisation, le nombre aléatoire lest avantageusement de la taille du module q, typiquement 192 bits. En référence à la Figure 5, des étapes d'un procédé de vérification dans le cadre d'une signature de type RSA sont décrites. Le procédé peut être mis en oeuvre par exemple dans l'un des systèmes décrits précédemment, entre un dispositif signataire, un dispositif sécurisé et un dispositif de calcul. Ici, la procédure de signature par le dispositif signataire est modifiée. En effet, une fonction cryptographique h est appliquée au message m que le dispositif signataire entreprend de signer. Par exemple, la fonction cryptographique peut être une fonction de hachage (e.g. SHA-1). Le résultat h(m), aussi appelé condensat ou haché (ou hash en anglais), est ensuite masqué (étape 500) à l'aide d'une donnée de masquage I, (par exemple un nombre aléatoire généré par le dispositif signataire) au cours d'une addition modulaire par exemple. En pratique, afin de garantir un niveau optimal de sécurisation, le nombre aléatoire I, comporte avantageusement le même nombre d'octets que le module utilisé dans les calculs de vérification RSA. Le dispositif signataire génère ensuite (étape 510) une signature S, à partir de la valeur masquée h(m) obtenue à l'étape 500. Par exemple, cette étape peut mettre en oeuvre une exponentiation modulaire, de façon similaire à l'algorithme de signature RSA. Ainsi, cette étape comporte par exemple la mise en oeuvre la fonction de signature RSA sur la signature S. Le dispositif sécurisé reçoit, via un canal de communication sécurisé avec le dispositif signataire, le message m avec la signature générée S, ainsi que la donnée de masquage I,. L'ensemble de ces données reçues sont désignées par 'premières données'. Au cours d'une étape 520, le dispositif sécurisé transmet la signature S, (désignée par les 'deuxièmes données') au dispositif de calcul. Le dispositif de calcul utilise la signature reçue pour obtenir un résultat intermédiaire h,' au cours d'une étape 530. Ici, les calculs réalisés par le dispositif de calcul à l'étape 530 comprennent une exponentiation modulaire visant à retrouver la valeur masquée h(m), auquel le dispositif signataire a appliqué une exponentiation modulaire à l'étape 510. Les calculs effectués par le dispositif de calcul correspondent à la mise en oeuvre classique de la fonction de vérification selon l'algorithme RSA, mis à part qu'ils sont effectués sur des données masquées, à savoir ici sur la signature S. Au cours d'une étape 540, une fonction cryptographique (par exemple la même qui est utilisée dans le calcul de la signature par le signataire) est appliquée au message m reçu par le dispositif sécurisé. Le résultat h(m) de cette fonction cryptographique h, est ensuite masqué au cours d'une seconde étape de masquage 550, similaire à la première étape de masquage 500, à partir de la donnée de masquage I, reçue par le dispositif sécurisé. Autrement dit, cette étape consiste à masquer indirectement (via la fonction h) une partie des premières données, c'est-à- dire ici le message m. Le dispositif sécurisé reçoit (étape 560) le résultat intermédiaire h,' de la part du dispositif de calcul en vue d'être utilisé pour la vérification de la validité de la signature numérique précitée. Cette étape de réception peut indifféremment avoir lieu avant, pendant ou après l'une des étapes 540 ou 550. Au cours d'une étape 570 (et après l'étape de réception 560), le dispositif sécurisé confronte le résultat intermédiaire h,' au résultat de la seconde étape de masquage h,. Si le résultat intermédiaire h,' et la valeur masquée h, correspondent, la signature numérique est considérée comme valide par le dispositif sécurisé. En conséquence, le message associé est certifié et peut être traité par le dispositif sécurisé. Au contraire, lorsque le résultat intermédiaire h,' et la valeur masquée h, ne correspondent pas, la signature numérique n'est pas validée et le message n'est alors pas certifié. Un exemple non limitatif de pseudo code pour l'implémentation de ces modes de réalisation est donné ci-dessous : Dispositif signataire Dispositif sécurisé Dispositif de calcul Ii = random(210g2(N))1{0} -> ni, Sb Ii Si -> -> Si hi' = Sie mod(N) h = hash(m) h = hash(m) hi = li + h mod(N) hi' Dans cet exemple de pseudo code : N est un le produit de deux nombres premiers aléatoires p et q, e est une clé publique, d est une clé secrète, correspondant typiquement à l'inverse modulaire de e modulo le plus petit commun multiple (PPCM) de p-1 et q-1, - les flèches -> et Contrairement à l'état de l'art, l'opération d'exponentiation modulaire mise en jeu dans le processus de vérification de la signature n'est pas effectuée dans le dispositif sécurisé mais dans le dispositif de calcul. La puissance de calcul du dispositif de calcul est avantageusement exploitée pour mettre en oeuvre cette opération présentant un coût calculatoire très important (près de 90% du coût des calculs du mécanisme de vérification). De plus, les données transmises (deuxièmes données) au dispositif de calcul pour effectuer cette opération ne sont pas « en clair » (autrement dit, la signature transmise à l'étape 520 ne dépend pas directement de la valeur h(m), mais de la valeur masquée h,) dans le dispositif signataire (étape 500). Ainsi, les calculs sont réalisés « à l'aveugle » pour le dispositif de calcul. La validité de la signature revenant toujours au dispositif sécurisé, le processus de vérification en est d'autant plus difficile à détourner. Par conséquent, la sécurité des données n'est pas mise en danger par la délégation de ce calcul au dispositif de calcul. Les exemples de mise en oeuvre décrits ci-dessus peuvent être adaptés lorsque le dispositif de sécurité et le dispositif signataire partagent un secret. En référence à la Figure 6, des étapes d'un procédé de vérification de type ECDSA sont décrites dans le cas d'un partage de secret entre le dispositif de sécurité et le dispositif signataire. Le procédé peut être mis en oeuvre par exemple dans l'un des systèmes décrits précédemment, entre un dispositif signataire, un dispositif sécurisé et un dispositif de calcul. Ici, le dispositif signataire et le dispositif sécurisé partagent une donnée secrète t, par exemple une clé cryptographique. Ce secret t leur permet de masquer les données échangées (notamment les données de signature). Le secret partagé t peut être par exemple utilisé en entrée d'un générateur de nombre pseudo-aléatoire (en anglais PRNG pour « Pseudo Random Number Generator ») afin d'obtenir des valeurs de masquage, e.g. I, = PRNG(t)', = PRNG(t)1-1. Au cours d'une étape 600, le dispositif signataire génère une signature (s, r) (désignée par 'premières données') à partir d'un message m, selon l'algorithme de génération de signature ECDSA. Plus précisément, une fonction cryptographique, par exemple de hachage est appliquée au message m pour obtenir un haché qui sera utilisé pour le calcul de la signature, notamment de l'élément s de la signature. Le dispositif signataire réalise un masquage (étape 610) des premières données (i.e. de la signature), faisant intervenir les données pseudo-aléatoires précitées I, = PRNG(t)' et = PRNG(t)1-1. Au cours d'une étape 620, le dispositif sécurisé reçoit le message m avec la signature masquée (s' r,). Au cours d'une étape 630, une fonction cryptographique h est appliquée au message m reçu à l'étape 620, par le dispositif sécurisé, de sorte que la valeur obtenue h(m) ne permet pas de remonter au message m. La fonction cryptographique h est par exemple une fonction de hachage. Au cours d'une étape 640, le dispositif sécurisé effectue un premier masquage de la valeur h(m) ainsi qu'un deuxième masquage de la valeur masquée h(m) obtenue, avec des valeurs pseudo aléatoires basées sur le secret partagé (utilisées à l'étape de masquage 610). En pratique, le premier masquage peut comprendre une addition modulaire et le deuxième masquage peut comprendre une multiplication modulaire. Au cours d'une étape 650, la valeur masquée h' obtenue à l'issue de l'étape 640 est transmise avec la signature masquée (s' r,) reçue par le dispositif sécurisé à l'étape 620 au dispositif de calcul. Celui-ci utilise les valeurs masquées reçues (`deuxièmes données') pour obtenir un résultat intermédiaire I,' au cours d'une étape de calcul 660. Dans ce mode de réalisation, les calculs réalisés par le dispositif de calcul visent à retrouver un des nombres pseudo aléatoires I, utilisés comme données de masquage lors des étapes 610 et 640. Par exemple, ces calculs peuvent comprendre une double multiplication scalaire à partir des deuxièmes données transmises par le dispositif sécurisé (similaire aux calculs de vérification standards selon l'algorithme ECDSA), puis une multiplication scalaire utilisant le résultat de l'opération précédente. Le résultat intermédiaire I,' est ensuite transmis au dispositif sécurisé (étape de réception 670) pour être utilisé pour la vérification de la validité de la signature numérique précitée. Pour ce faire, le dispositif sécurisé compare le résultat intermédiaire I,' avec un des nombres aléatoires utilisés pour le masquage I. Lorsque cette comparaison est positive, c'est-à-dire si le résultat intermédiaire I,' et le nombre aléatoire I, correspondent, la signature numérique est considérée comme valide par le dispositif sécurisé. En conséquence, le message afférant est certifié et peut être traité sans compromettre la sécurité du dispositif sécurisé. Au contraire, lorsque le résultat intermédiaire I,' et le nombre aléatoire I, ne correspondent pas, la signature numérique n'est pas validée et le message n'est pas certifié. Il représente potentiellement un danger pour la sécurité puisque sa source n'est pas authentifiée par le dispositif sécurisé. Un exemple non limitatif de pseudo code pour la mise en oeuvre de ces modes de réalisation est donné ci-dessous : Dispositif signataire Dispositif sécurisé Dispositif de calcul h-i = PRNG(tri Ii-i = PRNG(trl I = PRNG(01 li = PRNG(tf r= [k]P h = hash(m) hi = h + li_i mod(q) s = k-1(hi + rd) mod(q) si = h * s mod(q) ri = h *r mod(q) m, si, ri -> -> m, si, ri h = hash(m) hi = h + li_i mod(q) = hi * h mod(q) s' r,-> -> h', s' r, r = [sil hiiy + [sil rin I(= ri * ri mod(q) i et De plus, dans ici, la signature (s, r) est reçue déjà masquée par le dispositif sécurisé. Le dispositif n'a donc pas de masquage de la signature à effectuer lui-même, il lui suffit de transmettre les éléments de signature masqués directement au dispositif de calcul. En pratique, afin de garantir un niveau optimal de sécurisation, les nombres pseudo aléatoires I, et Li comptent avantageusement le même nombre de bits que le module q, typiquement 192 bits. En référence à la Figure 7, des étapes d'un procédé de vérification de type RSA sont décrite dans le contexte d'un secret partagé entre le dispositif sécurisé et le dispositif signataire. Le procédé peut être mis en oeuvre par exemple dans l'un des systèmes décrits précédemment, entre un dispositif signataire, un dispositif sécurisé et un dispositif de calcul. Il est supposé ici que le dispositif signataire et le dispositif sécurisé ne communiquent pas via un canal sécurisé. Le dispositif signataire et le dispositif sécurisé partagent une donnée secrète t, par exemple une clé. Ce secret t leur permet de masquer/démasquer les données échangées (ici, le message m). Le secret partagé t peut être par exemple utilisé en entrée d'un générateur de nombre pseudo-aléatoire (en anglais PRNG pour « Pseudo Random Number Generator ») afin d'obtenir une valeur de masquage, e.g. I, = PRNG(t)'. Conformément à des algorithmes de signature classique, comme par exemple l'algorithme RSA, une signature S est générée (étape 700) par le dispositif signataire à partir du message m. Selon RSA, la signature S est obtenue par une exponentiation modulaire de la valeur d'un condensat ou haché (hash) du message m. Le message m et la signature S constituent ici les 'premières données'. Ici, une partie des premières données constituée par le message m est masquée au cours d'une étape 710, en utilisant un nombre pseudo aléatoire I, obtenu à partir du secret partagé t précité. En pratique, afin de garantir un niveau optimal de sécurisation, le nombre pseudo aléatoire I, comporte avantageusement le même nombre d'octets que le module N utilisé pour les calculs de vérification. Au cours d'une étape 720, le dispositif sécurisé reçoit ensuite la signature S et le message masqué m' et il transmet la signature S (les 'deuxièmes données') au dispositif de calcul à l'étape 730. Le dispositif de calcul utilise la signature reçue pour obtenir (étape 740) un résultat intermédiaire h'. Au cours d'une étape 750, le dispositif sécurisé démasque le message masqué m, reçu à l'étape 720, en utilisant le nombre pseudo aléatoire I, obtenu à partir du secret partagé t précité. Ainsi, le secret partagé entre le dispositif signataire et le dispositif sécurisé a permis d'assurer la sécurité du message lors de sa transmission par une voie non sécurisée. Au cours d'une étape 760, une fonction cryptographique h (e.g. une fonction de hachage) est appliquée au message m démasqué à l'étape 750 par le dispositif sécurisé. Au cours d'une étape 770, le dispositif sécurisé reçoit le résultat intermédiaire de calcul h' qui sera utilisé pour la vérification de la validité de la signature numérique précitée. Il est à noter que dans ce mode de réalisation, les calculs réalisés par le dispositif de calcul comprennent une exponentiation modulaire visant à retrouver la valeur h(m). Cette étape de réception peut indifféremment avoir lieu avant, pendant ou après l'une des étapes 750 ou 760. Au cours d'une étape 780 (et après l'étape de réception 770), le dispositif sécurisé confronte le résultat intermédiaire h' à la valeur h(m) calculée à l'étape 760. Si le résultat intermédiaire h' et la valeur h(m) correspondent, la signature numérique est considérée comme valide par le dispositif sécurisé. En conséquence, le message associé est certifié et peut être traité par le dispositif sécurisé. Au contraire, lorsque le résultat intermédiaire h' et la valeur h(m) ne correspondent pas, la signature numérique n'est pas validée et le message n'est alors pas certifié. Un exemple non limitatif de pseudo code pour la mise en oeuvre de ces modes de réalisation est donné ci-dessous : Dispositif signataire Dispositif sécurisé Dispositif de calcul I = PRNG(t)I li = PRNG(t)I rni=melj h = hash(m) S = hd mod(N) -> m, S m, S -> m=mieli h = hash(m) S -> -> s h' = Se mod(N) h == h' h' et Contrairement à l'état de l'art, l'opération d'exponentiation modulaire mise en jeu dans le processus de vérification de la signature n'est pas effectuée dans le dispositif sécurisé mais dans le dispositif de calcul. La puissance de calcul du dispositif de calcul est avantageusement exploitée pour mettre en oeuvre cette opération présentant un coût calculatoire très important (près de 90% du coût des calculs du mécanisme de vérification). De manière générale, l'ordre de grandeur du rapport entre la puissance du dispositif sécurisé et la puissance du dispositif de calcul peut être, par exemple, d'environ 1/200. La présente invention a été décrite et illustrée dans la présente description détaillée en référence aux figures jointes. Toutefois la présente invention ne se limite pas aux formes de réalisation présentées. D'autres variantes, modes de réalisation et combinaisons de caractéristiques peuvent être déduits et mis en oeuvre par la personne du métier à la lecture de la présente description et des figures annexées. D'autres modes de réalisations sont bien entendu envisageables. Par exemple, l'invention couvre aussi une combinaison des modes de réalisation décrits. Par exemple, l'invention couvre aussi les modes dans lesquels le message (de la part du signataire) est reçu masqué par le dispositif sécurisé et les données envoyées au dispositif de calcul sont également masquées. Dans les revendications, le terme "comporter" n'exclut pas d'autres éléments ou d'autres étapes. L'article indéfini « un » n'exclut pas le pluriel. Un seul processeur ou plusieurs autres unités peuvent être utilisées pour mettre en oeuvre l'invention. Les différentes caractéristiques présentées et/ou revendiquées peuvent être avantageusement combinées. Leur présence dans la description ou dans des revendications dépendantes différentes, n'exclut pas en effet la possibilité de les combiner. Les signes de référence ne sauraient être compris comme limitant la portée de l'invention. REVENDICATIONS1. Procédé de vérification de la validité d'une signature numérique de message, comportant les étapes suivantes : - de détermination (300) de premières données de signature de message, - de transmission (320), à un dispositif de calcul, de deuxièmes données de calcul basées sur lesdites premières données de signature de message, - de réception (330), de la part dudit dispositif de calcul, d'un résultat intermédiaire de calcul sur les deuxièmes données, et - de vérification (340) de la validité de ladite signature à partir dudit résultat intermédiaire, caractérisé en ce que : - le procédé comporte en outre une étape de masquage (310), d'au moins une partie desdites premières données de signature de message, à partir d'au moins une donnée de masquage, et en ce que - ladite étape de vérification (340) fait intervenir ladite donnée de masquage. 2. Procédé de vérification selon la revendication 1, dans lequel ladite étape de vérification comprend : - une étape de démasquage (750) de ladite au moins une partie desdites premières données masquée au cours de ladite étape de masquage, - une étape d'application (760) d'une première fonction cryptographique au résultat de ladite étape de démasquage, et - une étape de comparaison (780) dudit résultat intermédiaire de calcul avec le résultat de l'application de ladite première fonction cryptographique. 3. Procédé de vérification selon la revendication 1, dans lequel ladite étape de vérification comprend : - ladite étape de masquage, laquelle comprend l'application (540) d'une deuxième fonction cryptographique à au moins une partie desdites premières données de signature de message, et laquelle comprend en outre le masquage (550) du résultat de l'application de ladite deuxième fonction cryptographique, à partir de ladite donnée de masquage, et une étape de comparaison (570) dudit résultat intermédiaire de calcul avec le résultat du masquage. 4. Procédé de vérification selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ledit résultat intermédiaire de calcul est obtenu au moins à partir d'une opération d'exponentiation modulaire sur lesdites deuxièmes données. 5. Procédé de vérification selon la revendication 1, dans lequel lesdites deuxièmes données de calcul transmises au dispositif de calcul au cours de l'étape de transmission (440) correspondent au résultat de ladite étape de masquage (430). 6. Procédé de vérification selon la revendication 1 ou la revendication 5, dans lequel ladite étape de vérification comprend une étape de comparaison (470, 680) dudit résultat intermédiaire de calcul avec ladite donnée de masquage. 7. Procédé de vérification selon la revendication 6, mis en oeuvre par un dispositif sécurisé dont la capacité de calcul est plus faible que la capacité de calcul dudit dispositif de calcul. 8. Procédé de vérification selon l'une quelconque des revendications 1 à 7, caractérisé en ce que ledit résultat intermédiaire de calcul est obtenu au moins à partir d'au moins une multiplication scalaire sur lesdites deuxièmes données. 9. Procédé de vérification selon l'une quelconque des revendications 1 à 8, dans lequel ladite étape de détermination comprend la réception (410) desdites premières données de signature de message. 10. Procédé de vérification selon l'une quelconque des revendications 1 à 9, dans lequel ladite au moins une partie desdites premières données de signature de message masquée au cours de l'étape de masquage sont reçues (620) par un dispositif sécurisé dont la capacité de calcul est plus faible que la capacité de calcul dudit dispositif de calcul, et dans lequel les étapes de transmission (650) de deuxièmes données, de réception (670) d'un résultat intermédiaire et de vérification (680) de la validité de la signature sont mises en oeuvre dans ledit dispositif sécurisé. 11. Dispositif (14a, 14b) pour la vérification de la validité d'une signature numérique de message, comportant : - un module de réception de premières données de signature de message, - un module de transmission, à un dispositif de calcul (12a, 12b), de deuxièmes données de calcul basées sur lesdites premières données de signature de message, - un module de réception, de la part dudit dispositif de calcul (12a, 12b), d'un résultat intermédiaire de calcul sur les deuxièmes données, et - un module de vérification de la validité de ladite signature à partir dudit résultat intermédiaire, caractérisé en ce que :- au moins une partie desdites premières données de signature de message sont masquées à partir d'au moins une donnée de masquage, et en ce que - ledit module de vérification utilise ladite donnée de masquage. 12. Dispositif selon la revendication 11, comprenant en outre un module de masquage de ladite au moins une partie desdites premières données de signature de message à partir de ladite au moins une donnée de masquage. 13. Système (10a, 10b, 14a, 14b) pour la vérification de la validité d'une signature numérique de message, comportant : - un module de détermination de premières données de signature de message, - un module de transmission, à un dispositif de calcul (12a, 12b), de deuxièmes données de calcul basées sur lesdites premières données de signature de message, - un module de réception, de la part dudit dispositif de calcul (12a, 12b), d'un résultat intermédiaire de calcul sur les deuxièmes données, et - un module de vérification de la validité de ladite signature à partir dudit résultat intermédiaire, caractérisé en ce que : - le dispositif comporte en outre un module de masquage, d'au moins une partie desdites premières données de signature de message, à partir d'au moins une donnée de masquage, et en ce que - ledit module de vérification utilise ladite donnée de masquage. 14. Système selon la revendication 13, comprenant un dispositif sécurisé (14a, 14b) et un dispositif signataire (10a, 10b), ledit dispositif signataire (10a, 10b) comprenant ledit module de détermination desdites premières données, et ledit dispositif sécurisé (14a, 14b) comprenant ledit module de transmission desdites deuxièmes données, ledit module de réception dudit résultat intermédiaire et ledit module de vérification dudit résultat intermédiaire. 15. Système selon la revendication 14, dans lequel ledit dispositif signataire (10a, 10b) et ledit dispositif sécurisé (14a, 14b) communiquent via un canal sécurisé de communication. 16. Système selon l'une quelconque des revendications 13 à 15, comprenant en outre ledit dispositif de calcul (12a, 12b). 17. Système selon la revendication 16, dans lequel ledit dispositif de calcul (12a, 12b) comprend ledit dispositif sécurisé (14a, 14b). 18. Programme d'ordinateur comportant des instructions pour la mise en oeuvre d'un procédé selon l'une quelconque des revendications 1 à 10 lorsqu'il est chargé et exécuté par un processeur d'un dispositif de vérification de la validité d'une signature numérique de message.5