Brevet FR3164588A1 — publié le 20260116

Procédé de signature d’un message mi, par un dispositif utilisateur, à partir d’un protocole cryptographique de preuve à divulgation nulle de connaissance défini par un élément g appartenant à un groupe G1 d’ordre p, avec p désignant un nombre entier premier, et des éléments u, v, r, s, t appartenant à un groupe G2, une fonction de hachage H et une période de temps courante w, comportant : une étape de génération d’une paire de clés privée et publique, la clé privée comportant un élément αi sélectionné dans l’anneau Z/pZ, la clé publique comportant un premier élément et un deuxième élément étant une preuve de possession à divulgation nulle de connaissance générée à partir du protocole cryptographique, une étape de génération d’une signature σi du message mi à partir de la clé privée et d’un aléa ϐ, la signature comportant un premier élément σ1i et un deuxième élément σ2i. Fig. 1. dispositif et procédé de génération de signatures agrégées vérifiable localement pour la génération d’attestations dans une plateforme d’architecture VNF-FG L’invention se rapporte au domaine général de la cryptographie et concerne plus particulièrement les procédés et dispositifs d’authentification numérique par signature électronique. Notamment, le présent exposé concerne la fourniture d’attestations collectives dans des plateformes informatiques virtualisées. Il est connu d'utiliser des mécanismes d’attestation permettant à une cible de s’authentifier auprès d’un vérificateur en démontrant qu’il satisfait à certaines propriétés. Classiquement, les mécanismes d’attestation prennent la forme d’un protocole dit « défi-réponse » au cours duquel le vérificateur envoie un défi à une cible accompagné d’un aléa, appelé nonce, la cible génère des preuves en réponse à ce défi et les envoie au vérificateur, généralement la preuve se fait à partir de la racine de confiance de la cible. La preuve consiste généralement à démontrer, par la fourniture d’attestation, que la cible est dans une configuration particulière, notamment dans une configuration non corrompue. Un tel mécanisme est également connu pour attester qu’un groupe de cibles est dans une configuration particulière, digne de confiance et non corrompue. Classiquement, les messages desdites cibles sont agrégés formant ainsi un unique message prouvant l’état d’un ensemble de cibles. Dans le cas particulier des plateformes informatiques virtualisées comportant entre autres une pluralité de machines virtuelles et un hyperviseur, non seulement les machines virtuelles mais également l’infrastructure de ces machines virtuelles doivent être attestées. Pour ce faire, il est connu des méthodes fournissant une attestation de groupe pour l’ensemble des machines virtuelles et leur infrastructure. Classiquement, ces méthodes se fondent sur l’attribution d’une cartographie reliant les machines virtuelles et leurs hyperviseurs sous la forme d’arbre reliant des nœuds enfants à des nœuds parents. Dès réception d’une requête d’attestation, ou « défi », les nœuds enfants, génère une attestation et la transmette à leur nœud parent. Certaines méthodes comportent la génération de rapport d’attestation sous la forme d’un booléen, par les nœuds parents, en plus de leur propre attestation, indiquant si les attestations de nœuds enfants sont valides (booléen : 1) ou si au moins une attestation de nœuds enfants est non valide (booléen : 0). Ce rapport permet au vérificateur d’obtenir rapidement une attestation globale de l’ensemble. Cela permet avantageusement de répartir les ressources en calcul en parallélisant les vérifications d’attestations. Cependant, dans le cas d’une attestation non valide, il n’est pas possible d’identifier la ou les cibles ayant fourni une attestation non valide, autrement dit d’identifier la ou les cibles qui ne sont pas dans une configuration valide, i.e. digne de confiance. Par ailleurs, cela nécessite entre autres que les nœuds parents puissent vérifier l’attestation et sachent donc ce qu’est une attestation valide pour le nœud enfant, i.e. ce qu’est une configuration valide pour ladite machine virtuelle et son hyperviseur. Cette connaissance peut être contestable, notamment dans le cadre d’une plateforme informatique virtualisée dont les ressources sont détenues par une pluralité d’entités propriétaires, qui ne souhaitent pas partager entre elles les infrastructures internes de leurs machines virtuelles. D’autres méthodes alternatives comportent l’agrégation des attestations individuelles générées par les cibles de sorte à obtenir une attestation agrégée. Cette attestation agrégée est vérifiée par le vérificateur au sommet du graphe. Cependant, le temps de vérification de telles méthodes est particulièrement long, ce dernier étant linéaire au nombre d’attestations, et donc de cibles, contenues dans l’attestation agrégée. Même si des procédés d’optimisation existent et permettent de réduire dans certains cas ces temps de vérification, ces améliorations offrent malheureusement des gains en temps limités. De façon générale, il est avantageux de pouvoir vérifier une signature agrégée en une position particulière, autrement dit de pouvoir vérifier l’attestation d’une cible en particulier. On parle alors de « vérification locale », par opposition à une « vérification globale » visant à vérifier si l’attestation agrégée est valide dans son ensemble. Les méthodes les moins couteuses reposent sur la génération d’attestations dont les messages ont été signés avec une unique clé. D’autres méthodes, exploitant l’algorithme ZK-SNARK (« Zero-Knowledge Succinct Non-interactive ARgument of Knowledge ») permettent la vérification locale d’attestations agrégées formées à partir de messages signés par une pluralité de clés, cependant ces méthodes sont extrêmement couteuses. Par ailleurs, comme soulevé précédemment, il existe un besoin pour assurer la confidentialité des configurations des cibles tout en leur permettant d’attester qu’elles sont dans une configuration valide auprès du vérificateur. Des méthodes classiques, telles que le chiffrement, peuvent être exploitées afin de protéger les informations échangées. Cependant, cela sous-entend que la cible peut faire confiance au vérificateur. Des approches plus récentes, telles que l’algorithme ZK-SNARK, permettent la génération des preuves dites à divulgation nulle de connaissance. L’idée de ces méthodes est que la cible n’envoie pas sa configuration exacte comme preuve mais envoie une preuve qu’elle est dans une configuration valide parmi un ensemble de configurations valides possibles sans révéler la configuration dans laquelle elle est. Il existe donc un réel besoin pour fournir des attestations qui soit dépourvues, au moins en partie, des inconvénients inhérents aux méthodes connues précitées. En particulier, il existe un besoin pour des attestations permettant de vérifier rapidement l’état de validité d’une pluralité de cibles dans une plateforme informatique virtualisée, dans leur globalité et individuellement. Il existe également un besoin pour améliorer la confidentialité dans les échanges d’attestations, notamment dans un contexte d’une plateforme informatique virtualisée dont les ressources sont détenues par une pluralité d’entités propriétaires. De façon générale, il existe un besoin pour fournir des attestations sécurisées générées rapidement, et pouvant être vérifiées rapidement tout en limitant la bande passante nécessaire. L’invention vise à répondre à tout ou partie de ces besoins. L’invention vise un procédé de signature d’un message m i , par un dispositif utilisateur, à partir d’un protocole cryptographique de preuve à divulgation nulle de connaissance défini par un élément g appartenant à un groupe G 1 cyclique d’ordre p, avec p désignant un nombre entier premier, et des éléments u, v, r, s, t appartenant à un groupe G 2 cyclique d’ordre p, une fonction de hachage H et une période de temps courante w, le procédé comportant : - une étape de génération d’une paire de clés privée et publique, la clé privée comportant un élément αi sélectionné dans l’anneau Z/pZ, la clé publique comportant un premier élément g α i et un deuxième élément π i étant une preuve de possession à divulgation nulle de connaissance générée à partir du protocole cryptographique, - une étape de génération d’une signature σ i du message m i à partir de la clé privée et d’un aléa ϐ, la signature comportant - un premier élément σ 1i = (vu H(m) ) α .(r |lg(w)| s w t) ϐ , et - un deuxième élément σ 2i = g ϐ . Le dispositif utilisateur peut être avantageusement compris dans une plateforme informatique virtualisée, comportant notamment une racine de confiance (RoT, « Root of Trust » en anglais). De manière conventionnelle, une racine de confiance est configurée pour exécuter une ou plusieurs fonctions spécifiques de sécurisation de la plateforme informatique virtualisée. La plateforme informatique virtualisée peut être utilisée pour assurer les fonctionnalités d’un réseau mobile ou mettre en œuvre une plateforme d’architecture VNF-FG (en anglais « Virtual Network Functions-Forwarding Graph»).L’invention vise également un procédé de signature d’un ensemble de messages m 0 , ..., m n , mis en œuvre dans une plateforme informatique virtualisée comportant une pluralité de dispositifs utilisateurs, à partir d’un protocole cryptographique de preuve à divulgation nulle de connaissance défini par un élément g appartenant à un groupe G 1 cyclique d’ordre p, avec p désignant un nombre entier premier, et des éléments u, v, r, s, t appartenant à un groupe G 2 cyclique d’ordre p, une fonction de hachage H et une période de temps courante w, le procédé comportant : - pour chaque message m i de l’ensemble de messages, i appartenant à l’intervalle [0, n], avec n un entier naturel supérieur ou égal à 1, la signature du message m i par un dispositif utilisateur de la pluralité de dispositifs utilisateurs, au moyen d’un procédé de génération d’une signature tel que décrit précédemment de sorte à générer une signature pour ledit message m i, dite signature individuelle ; - une étape d’agrégation de tout ou partie des signatures individuelles préalablement générées au cours de ladite période de temps courante w de sorte à générer une signature agrégée comportant un premier élément et un deuxième élément. L’étape d’agrégation peut comporter l’agrégation de signatures individuelles entre elles et/ou de signatures agrégées préalablement générées. L’étape d’agrégation peut comporter une interpolation des premiers éléments des signatures à agréger, et une interpolation des deuxièmes éléments des signatures à agréger. L’étape d’agrégation peut être mise en œuvre en calculant le premier élément ϴ 1 et le deuxième élément ϴ 2 au moyen des formules suivantes : Corrélativement, l’invention concerne un dispositif utilisateur apte à signer un message m i à partir d’un protocole cryptographique de preuve à divulgation nulle de connaissance défini par un élément g appartenant à un groupe G 1 cyclique d’ordre p, avec p désignant un nombre entier premier, et des éléments u, v, r, s, t appartenant à un groupe G 2 cyclique d’ordre p, une fonction de hachage H et une période de temps courante w, le dispositif utilisateur comportant : - un module de génération configuré pour générer une paire de clés privée et publique, la clé privée comportant un élément αi sélectionné dans l’anneau Z/pZ, la clé publique comportant un premier élément g α i et un deuxième élément π i étant une preuve de possession à divulgation nulle de connaissance générée à partir du protocole cryptographique, - un module de génération apte à générer une signature σ i du message m i à partir de la clé privée et d’un aléa ϐ, ladite signature comportant un premier élément σ 1i = (vu H(m) ) α .(r |lg(w)| s w t) ϐ , et un deuxième élément σ 2i = g ϐ . L’invention concerne également un groupe de dispositifs utilisateurs tels que décrits précédemment, dont tout ou partie des dispositifs utilisateurs comportent en outre : - un module d’agrégation apte à agréger tout ou partie des signatures générées par lesdits dispositifs utilisateurs au cours de la période de temps courante w de sorte à générer une signature agrégée comportant un premier élément et un deuxième élément. Par « signature agrégée », on entend une signature comportant plusieurs signatures individuelles de différents messages provenant de différents dispositifs utilisateurs agrégées ensemble de telle sorte que la signature résultante a une taille constante, qui est de préférence la même taille qu'une signature individuelle, et peut être vérifiée à partir de la connaissance des différents messages et des clés publiques associées. La signature agrégée obtenue au moyen de l’invention permet en outre la génération de signatures agrégées dites synchronisées. Par « signature agrégée synchronisée » on entend une signature agrégée composée de signatures individuelles générées pour une même période de temps courante. Cela permet avantageusement d’éviter les attaques dites de relecture, ou « replay attacks » en anglais. Ainsi, et d’une façon générale, l’invention propose un procédé de génération de signatures pouvant être générées à partir de paires de clés publique-privée différentes permettant non seulement de préserver la sécurité des échanges au sein d’un groupe de dispositifs utilisateurs mais également de réaliser une vérification locale d’une signature dans la signature agrégée. En outre, le schéma de signature permet une agrégation dite « multi-hop » permettant d’agréger les signatures individuelles au fur et à mesure et non nécessairement en une seule fois. Autrement dit, l’agrégation peut porter sur des signatures individuelles exclusivement, des signatures agrégées exclusivement ou à la fois des signatures individuelles et des signatures agrégées. Cela peut permettre avantageusement de réaliser l’étape d’agrégation au sein d’un graphe. La plateforme informatique virtualisée peut avoir une architecture du type VNF-FG, acronyme pour l’expression anglaise « Virtual Network Functions- Forwarding Graph », les dispositifs utilisateurs pouvant être des machines virtuelles, hébergeant chacune une fonction de réseau virtuelle (VNF pour l’expression anglais « Virtual Network Function »). Un tel graphe comporte un point d’entrée et un point de sortie. Une telle architecture est représentée en FIG. 1 . Le procédé peut comporter une étape de détermination d’un arbre, communément appelé « spanning tree » en anglais, sur ladite plateforme informatique virtualisée, reliant les dispositifs utilisateurs entre eux, par exemple par la mise en œuvre d’un algorithme « Spanning Tree Protocol ». Le procédé peut en outre comporter une étape de réception, par le ou lesdits dispositifs utilisateurs, d’une requête d’attestation de la part d’un vérificateur, par exemple transmise via le point d’entrée. La signature d’un message par un dispositif utilisateur faisant suite à la réception de cette requête d’attestation par ledit dispositif utilisateur de sorte à fournir une preuve de configuration valide dudit dispositif utilisateur. Après la génération de la signature à la suite de la réception d’une requête d’attestation, un dispositif utilisateur peut transmettre ladite signature à un autre dispositif utilisateur. L’invention porte également sur un procédé de vérification, par un dispositif de vérification, d’une signature agrégée comportant un premier élément ϴ 1 et un deuxième élément ϴ 2 et générée pour un ensemble de messages m 0 , ..., m n en utilisant un procédé de génération d’une signature selon l’invention, à partir d’un protocole cryptographique de preuve à divulgation nulle de connaissance défini par un élément g appartenant à un groupe G 1 cyclique d’ordre p, avec p désignant un nombre entier premier, et des éléments u, v, r, s, t appartenant à un groupe G 2 cyclique d’ordre p, une fonction de hachage H et une période de temps courante w, le procédé comportant : - une étape de vérification de l’égalité : [Math. 2] , où e désigne un couplage bilinéaire défini sur les groupes G 1 et G 2 et à valeurs dans un groupe cyclique G T , - Si ladite égalité est vérifiée une étape de validation de ladite signature agrégée. De préférence, le procédé de vérification selon l’invention comporte une étape préalable de génération d’un agrégat clés-messages à partir des messages m 0 , ..., m n , des clés publiques g α 0 , ..., g α n issues des paires de clés générées pour la signature desdits messages, et de la fonction de hachage H. L’étape préalable de génération de l’agrégat clés-messages peut avantageusement être effectuée en amont et une seule fois, permettant d’accélérer, par contraste, l’étape de vérification. L’agrégat clés-messages peut comporter un premier élément apkm1 et un deuxième élément apkm2. Le premier élément peut être égal au produit des premiers éléments des clés publiques g α 0 , ..., g α n . Le deuxième élément peut être égal au produit des g α i H (m i ) pour i allant de 0 à n.. L’étape de vérification de l’égalité peut consister en la vérification de l’égalité : Une telle étape peut permettre une vérification par lot à temps constant. Cela est notamment rendu possible du fait de l’absence d’utilisation de nonce dans la génération des signatures individuelles, sans pour autant que cette absence affecte la sécurité des échanges. En effet, l’utilisation d’une période de temps courante pour l’agrégation permet d’assurer une fraîcheur des signatures. La vérification par lot à temps constant permet un contrôle de la durée de vérification, indépendamment du nombre de signatures individuelles formant ladite signature agrégée. Une telle vérification suppose la connaissance préalable, par le dispositif de vérification, des messages attendus du lot ainsi que des clés publiques associées auxdits messages. L’invention porte également sur un procédé de vérification d’une signature individuelle d’un message m i comprise dans une signature agrégée comportant un premier élément ϴ 1 et un deuxième élément ϴ 2 et générée pour un ensemble de messages m 0 , ..., m n , i appartenant à l’intervalle [0,n] en utilisant un procédé de génération d’une signature selon l’invention, à partir d’un protocole cryptographique de preuve à divulgation nulle de connaissance défini par un élément g appartenant à un groupe G 1 cyclique d’ordre p, avec p désignant un nombre entier premier, et des éléments u, v, r, s, t appartenant à un groupe G 2 cyclique d’ordre p, une fonction de hachage H et une période de temps courante w, le procédé comportant : - une étape de vérification de l’égalité : [Math. 4] , où e désigne un couplage bilinéaire défini sur les groupes G 1 et G 2 et à valeurs dans un groupe cyclique G T , - Si ladite égalité est vérifiée une étape de validation de ladite signature individuelle. De préférence, ledit procédé de vérification d’une signature individuelle comporte une étape de pré-traitement au cours de laquelle au moins une première information auxiliaire aux1, par exemple aux1= , une deuxième information auxiliaire aux2, par exemple aux2= et une troisième information auxiliaire aux3, par exemple aux3 = , avec π ZK une preuve que les preuves de possessions des clés publiques sont valides, sont déterminées à partir des clés publiques g α 0 , ..., g α n issues des paires de clés générées pour la signature desdits messages m 0 , ..., m n et desdits messages de sorte à précalculer des termes de l’égalité de l’étape de vérification. Cette étape de pré-traitement peut avantageusement être effectuée en amont et une seule fois, permettant d’accélérer, par contraste, l’étape de vérification de l’égalité. Corrélativement, l’invention concerne un dispositif de vérification, d’une signature agrégée comportant un premier élément ϴ 1 et un deuxième élément ϴ 2 et générée pour un ensemble de messages m 0 , ..., m n en utilisant un procédé de génération d’une signature selon l’invention, à partir d’un protocole cryptographique de preuve à divulgation nulle de connaissance défini par un élément g appartenant à un groupe G 1 cyclique d’ordre p, avec p désignant un nombre entier premier, et des éléments u, v, r, s, t appartenant à un groupe G 2 cyclique d’ordre p, une fonction de hachage H et une période de temps courante w, le dispositif de vérification comportant : - un module de vérification apte à vérifier l’égalité : [Math. 5] , où e désigne un couplage bilinéaire défini sur les groupes G 1 et G 2 et à valeurs dans un groupe cyclique G T , et - un module de validation de la signature agrégée activé si ladite égalité est vérifiée. L’invention porte également sur un dispositif d’ouverture comportant un module de génération apte à générer, à partir des messages m 0 , ..., m n , des clés publiques g α 0 , ..., g α n issues des paires de clés générées pour la signature desdits messages, et de la fonction de hachage H, un agrégat clés-messages, de sorte à permettre au module de vérification d’effectuer une vérification par lot. Dans des modes de réalisation particuliers de l’invention, le dispositif d’ouverture est inclus dans le dispositif de vérification. L’invention porte également sur dispositif de vérification apte à vérifier une signature individuelle d’un message m i comprise dans une signature agrégée comportant un premier élément ϴ 1 et un deuxième élément ϴ 2 et générée pour un ensemble de messages m 0 , ..., m n , i appartenant à l’intervalle [0,n] en utilisant un procédé de génération d’une signature selon l’invention, à partir d’un protocole cryptographique de preuve à divulgation nulle de connaissance défini par un élément g appartenant à un groupe G 1 cyclique d’ordre p, avec p désignant un nombre entier premier, et des éléments u, v, r, s, t appartenant à un groupe G 2 cyclique d’ordre p, une fonction de hachage H et une période de temps courante w, le procédé comportant : - un module de vérification de l’égalité : [Math. 6] , où e désigne un couplage bilinéaire défini sur les groupes G 1 et G 2 et à valeurs dans un groupe cyclique G T , et - un module de validation de la signature individuelle activé si ladite égalité est vérifiée. De préférence, ledit dispositif de vérification d’une signature individuelle peut comporter un module de pré-traitement apte à déterminer au moins une première information auxiliaire aux1, une deuxième information auxiliaire aux2 et une troisième information auxiliaire aux3 sont déterminées à partir des clés publiques g α 0 , ..., g α n issues des paires de clés générées pour la signature desdits messages m 0 , ..., m n et desdits messages. Dans des modes de réalisation particuliers de l’invention, le module de pré-traitement est intégré dans un dispositif d’ouverture selon l’invention, distinct du dispositif de vérification. Les informations auxiliaires peuvent avantageusement permettre de calculer plus rapidement l’égalité. Par ailleurs, elles peuvent être calculées en amont, le dispositif de vérification connaissant les messages attendus et les clés publiques des dispositifs utilisateurs dont il veut vérifier la signature. Enfin, l’invention concerne un système de communication comportant : - un groupe de dispositifs utilisateurs selon l’invention, et - un ou plusieurs dispositifs de vérification selon l’invention. En particulier, le système de communication comporte des dispositifs utilisateurs détenus par une pluralité d’entités propriétaires. De préférence, le système de communication comporte alors un dispositif de vérification pour chaque entité propriétaire apte à vérifier des signatures individuelles et/ou agrégées relatives exclusivement aux dispositifs utilisateurs détenus par ladite entité propriétaire, et un dispositif de vérification apte à vérifier des signatures générées par l’intégralité des dispositifs utilisateurs. Dans certains modes de réalisation, le protocole cryptographique est fondé sur l’algorithme ZK-SNARK. Bien que le calcul de la preuve de possession ZK-SNARK puisse être très coûteux, l’étape de pré-traitement déterminant des informations auxiliaires à partir de données publiques combinée au fait que le dispositif de vérification connaît les messages signés attendus permet de calculer à l'avance les informations auxiliaires une seule fois et de les réutiliser à chaque fois. Ainsi, quand bien même l’algorithme ZK-SNARK est exploité, la mise en œuvre du procédé de vérification d’une signature individuelle est efficace et pratique. De façon générale, l’invention permet ainsi la génération d’un schéma de signature agrégée synchronisée multi-signataires vérifiable par lot à temps constant pouvant être vérifiée localement et globalement. En outre, l’étape de génération préalable des agrégats clés-messages permet en particulier la mise en œuvre d’une vérification par lot à temps constant, « constant time batch verification » en anglais, par un vérificateur global. L’invention permet ainsi de contrôler des attestations, notamment dans une plateforme informatique virtualisée de type VNF-FG, qui sont générées et vérifiées, à la fois localement et globalement, efficacement tout en utilisant une bande passante plus faible que les méthodes connues. Dans des modes de réalisations particuliers, tout ou partie des étapes d’un procédé selon l’invention, de préférence toutes les étapes, sont mises en œuvre par des instructions de programme d’ordinateur. Ainsi, l’invention vise aussi un programme d’ordinateur comportant des instructions de code, qui lorsqu’elles sont exécutées au moyen d’un ordinateur permettent la mise en œuvre d’un procédé selon l’invention ainsi qu’un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour l’exécution des étapes d’un procédé selon l’invention. Les caractéristiques et avantages précités, ainsi que d'autres, apparaîtront à la lecture de la description détaillée qui suit. Cette description détaillée fait référence aux dessins annexés. Les dessins annexés sont schématiques et visent avant tout à illustrer les principes de l’exposé. Sur ces dessins, d’une figure à l’autre, des éléments (ou parties d’élément) identiques sont repérés par les mêmes signes de référence. FIG. 1 La FIG. 1 est une plateforme informatique virtualisée selon l’invention. FIG. 2 La FIG. 2 illustre les étapes d’un exemple de mise en œuvre d’un procédé de signature individuelle par un dispositif utilisateur selon l’invention, FIG. 3 La FIG. 3 représente un exemple d’architecture fonctionnelle d’un dispositif utilisateur selon l’invention, FIG. 4 La FIG. 4 illustre les étapes d’un exemple de mise en œuvre d’un procédé de signature agrégée mise en œuvre par un groupe de dispositifs utilisateur selon l’invention, FIG. 5 La FIG. 5 représente un exemple d’architecture fonctionnelle d’un dispositif utilisateur selon l’invention, FIG. 6 La FIG. 6 illustre les étapes d’un exemple de mise en œuvre d’un procédé de vérification d’une signature par un dispositif de vérification selon l’invention, FIG. 7 La FIG. 7 représente un exemple d’architecture fonctionnelle d’un dispositif de vérification selon l’invention, FIG. 8 La FIG. 8 illustre les étapes d’un exemple de mise en œuvre d’un autre procédé de vérification d’une signature par un dispositif de vérification selon l’invention, FIG. 9 La FIG. 9 représente un exemple d’architecture fonctionnelle d’un dispositif de vérification selon l’invention, FIG. 10 La FIG. 10 illustre un exemple d’architecture matérielle d’un dispositif utilisateur et/ou d’un dispositif de vérification et/ou d’une plateforme informatique virtualisée selon l’invention. Afin de rendre plus concret l’exposé, un exemple de plateforme informatique virtualisée 1 comportant une pluralité de dispositifs utilisateurs U et une pluralité de dispositifs de vérification V, V1, V2, V3 est représentée à la FIG. 1 et est décrite en détail ci-après, en référence aux dessins annexés. Il est rappelé que l'invention ne se limite pas à cet exemple. Dans l’exemple illustré, la plateforme informatique virtualisée 1 a une architecture du type VNF-FG, comportant entre autres un point d’entrée E, un point de sortie S et un dispositif gestionnaire 2. Les dispositifs utilisateurs U peuvent être des fonctions de réseau virtuelles, par exemple hébergées dans des machines virtuelles. Cet exemple, bien que préféré, n’est pas limitatif. Les dispositifs utilisateurs peuvent être détenus par des entités propriétaires différentes. Par exemple les dispositifs utilisateurs du groupe GU1 de dispositifs utilisateurs peuvent être détenus par une première entité propriétaire, les dispositifs utilisateurs du groupe GU2 de dispositifs utilisateurs peuvent être détenus par une deuxième entité propriétaire, et les dispositifs utilisateurs du groupe GU3 de dispositifs utilisateurs peuvent être détenus par une troisième entité propriétaire. Pour chaque entité propriétaire, la plateforme informatique virtualisée peut comporter un dispositif de vérification V1, V2, V3, dit local, apte à vérifier une signature agrégée ou individuelle d’un ou des dispositifs utilisateurs détenus par ladite entité propriétaire. La plateforme informatique virtualisée 1 comporte de préférence au moins un dispositif de vérification V, dit global, apte à vérifier une signature agrégée de l’ensemble des dispositifs utilisateurs de la plateforme informatique virtualisée. Chaque dispositif utilisateur U est en mesure de signer un message m grâce à l’invention. De façon générale, l’invention permet de fournir des attestations destinées à prouver que les dispositifs utilisateurs sont dans une configuration correspondant à un état valide auprès d’un dispositif de vérification. Pour cela, une requête d’attestation est envoyée, par un dispositif de vérification, auprès des dispositifs utilisateurs de la plateforme informatique virtualisée. La requête peut être transmise aux dispositifs utilisateurs via le point d’entrée E puis est propagée jusqu’au point de sortie S, via des connexions reliant les dispositifs utilisateurs U entre eux. Notamment, la requête est propagée le long d’un arbre, communément appelé « spanning tree » en anglais. Le procédé peut comporter une étape de détermination d’un tel arbre sur ladite plateforme informatique virtualisée, par exemple par la mise en œuvre d’un algorithme « Spanning Tree Protocol ». La FIG. 1 représente plateforme informatique virtualisée d’architecture du type VNF-FG sur laquelle un exemple de mise en œuvre de « spanning tree » a été calculé. Les liaisons en trait plein et en pointillé représentent des connexions entre les éléments de la plateforme informatique virtualisée. Les liaisons en pointillé ne sont cependant pas utilisées par l’arbre calculé par le « spanning tree » contrairement aux liaisons en trait plein. Ainsi, dans l’exemple de la FIG. 1 , la requête est propagée le long des liaisons en trait plein. De même, les messages signés par les dispositifs utilisateurs sont avantageusement remontés et progressivement agrégés jusqu’au point d’entrée E le long des liaisons en trait plein. Dès réception de la requête par un dispositif utilisateur U, ce dernier génère une attestation en réponse à cette requête destinée à prouver qu’il est dans une configuration correspondant à un état valide. La génération de l’attestation consiste en la signature d’un message m. Le message m étant porteur d’une preuve que ledit dispositif utilisateur est dans une des configurations parmi un ensemble de configurations valides indiquées dans ledit message m. Pour permettre une telle signature, un protocole cryptographique est défini. Le protocole cryptographique peut être déterminé par le dispositif gestionnaire 2. De préférence, le dispositif gestionnaire contrôle l’infrastructure de la plateforme informatique virtualisée. Le protocole cryptographique est un protocole de preuve à divulgation nulle de connaissance. Notamment le protocole cryptographique est un algorithme du type ZK-SNARK. Le protocole cryptographique est entre autres défini par un élément g appartenant à un groupe G 1 cyclique d’ordre p, avec p désignant un nombre entier premier, et des éléments u, v, r, s, t appartenant à un groupe G 2 cyclique d’ordre p, une fonction de hachage H et une période de temps courante w. De préférence, une horloge commune est partagée par les dispositifs utilisateurs et le ou les dispositifs de vérification de sorte que la période de temps courante est commune. En particulier, l’horloge peut être positionnée dans la racine de confiance (Root of Trust, RoT) de chacun des dispositifs utilisateurs. Alternativement, l’horloge peut être contenue dans le dispositif gestionnaire 2. Afin de fournir l’attestation en réponse à ladite requête, chaque dispositif utilisateur U met en œuvre un procédé 200 de signature d’un message m selon l’invention, tel qu’illustré à la FIG. 2 . Le procédé 200 de signature d’un message m est effectué à partir du protocole cryptographique de preuve à divulgation nulle de connaissance défini précédemment. Ledit procédé 200 comporte une étape E210 de génération d’une paire de clés privée et publique, la clé privée comportant un élément α sélectionné dans l’anneau Z/pZ, la clé publique comportant un premier élément g α et un deuxième élément π étant une preuve de possession à divulgation nulle de connaissance générée à partir du protocole cryptographique, et une étape E220 de génération d’une signature σ du message m à partir de la clé privée et d’un aléa ϐ, la signature comportant un premier élément σ 1 =(vu H (m) ) α .(r |lg (w)| s w t) ϐ , et un deuxième élément σ 2 = g ϐ . La preuve de possession est une preuve que le dispositif utilisateur est en possession de la clé privée α associée à la clé publique (g α , π). Une telle preuve de possession peut notamment permettre d’éviter les attaques de type « rogue key attack » lors d’une étape d’ouverture et/ou de vérification locale. Chaque dispositif utilisateur U comporte des modules configurés pour mettre en œuvre un procédé 200 de génération d’une signature comportant au moins un module M210 de génération configuré pour mettre en œuvre une étape E210 de génération d’une paire de clés privée et publique, un module M220 de génération configuré pour mettre en œuvre une étape E220 de génération d’une signature σ du message m. A la FIG. 4 est représenté un procédé 300 de signature d’un ensemble de messages m 0 , ..., m n , mis en œuvre dans une plateforme informatique virtualisée comportant une pluralité de dispositifs utilisateurs U 0 , ..., U n , à partir du protocole cryptographique de preuve à divulgation nulle de connaissance. Le procédé 300 comporte : pour chaque message m i de l’ensemble de messages, i appartenant à l’intervalle [0, n], la signature du message m i par le dispositif utilisateur correspondant U i de la pluralité de dispositifs utilisateurs, au moyen de la mise en œuvre du procédé de génération 200 d’une signature tel que décrit précédemment de sorte à générer une signature σ i pour ledit message m i, dite signature individuelle ; puis une étape d’agrégation E320 de tout ou partie des signatures individuelles préalablement générées au cours de ladite période de temps courante w de sorte à générer une signature agrégée comportant un premier élément et un deuxième élément. De préférence, les dispositifs utilisateurs dits parents U P , comportent en outre un module M330 d’agrégation de signatures générées au moyen d’un procédé 200 de génération d’une signature selon l’invention, tel qu’illustré à la FIG. 5 . Les dispositifs utilisateurs parents sont des dispositifs utilisateurs non directement relié au point de sortie S. L’agrégation peut être effectuée à partir de signatures individuelles générées par la mise en œuvre d’un procédé 200 et/ou à partir de signatures agrégées générées par la mise en œuvre d’un procédé 300. Les signatures individuelles sont progressivement propagées des dispositifs utilisateurs jusqu’au point d’entrée E. Cette signature agrégée formées de signatures individuelles générée au moyen d’un procédé 300 selon l’invention est destinée à être vérifiée par un dispositif de vérification V. Nous allons maintenant décrire en référence à la FIG. 6 un procédé 400 de vérification, d’une signature agrégée comportant un premier élément ϴ 1 et un deuxième élément ϴ 2 et générée pour un ensemble de messages m 0 , ..., m n en utilisant un procédé de génération d’une signature selon l’invention, à partir d’un protocole cryptographique de preuve à divulgation nulle de connaissance le procédé comportant une étape E420 de vérification de l’égalité : [Math. 7] , où e désigne un couplage bilinéaire défini sur les groupes G 1 et G 2 et à valeurs dans un groupe cyclique G T , et - si ladite égalité est vérifiée une étape E430 de validation de ladite signature agrégée. Le procédé 400 peut en outre comporter une étape préalable E410 de génération d’un agrégat clés-messages à partir des messages m 0 , ..., m n , des clés publiques g α 0 , ..., g α n issues des paires de clés générées pour la signature individuelles desdits messages, et de la fonction de hachage H. L’agrégat clés-messages peut comporter un premier élément apkm1 égal au produit des premiers éléments des clés publiques g α 0 , ..., g α n , et un deuxième élément apkm2 égal au produit des g α i H (m i ) pour i allant de 0 à n. Une telle étape E410 permet une vérification par lot à temps constant. Le dispositif de vérification V comporte des modules configurés pour mettre en œuvre un procédé 400 de vérification d’une signature agrégée comportant au moins un module M420 de vérification configuré pour mettre en œuvre une étape 420 de vérification de l’égalité ci-dessus, et un module M430 de validation configuré pour mettre en œuvre une étape E430 de validation d’une signature. Un tel dispositif est illustré à la FIG. 7 . De préférence, le dispositif de vérification V comporte en outre un module M410 de génération d’un agrégat clés-messages configuré pour mettre en œuvre une étape 410 de génération d’un agrégat clés-messages à partir des messages m 0 , ..., m n , des clés publiques g α 0 , ..., g α n issues des paires de clés générées pour la signature desdits messages, et de la fonction de hachage H. Alternativement, le module M410 de génération d’un agrégat clés-messages peut être compris dans un dispositif d’ouverture (non représenté), distinct du dispositif de vérification V. Outre la vérification globale décrite ci-dessus, l’invention porte également sur une vérification locale. Autrement dit, l’invention permet la vérification des signatures individuelles d’un sous-groupe des dispositifs de la plateforme informatique virtualisée. En particulier, l’invention rend possible la vérification des signatures individuelles signées par des dispositifs utilisateurs d’un groupe de dispositifs utilisateurs détenus par une entité propriétaire particulière. Par exemple, le dispositif de vérification V1 peut être configuré pour mettre en œuvre un procédé de vérification d’une signature individuelle générée par l’un des dispositifs du sous-groupe de dispositifs GU1. En référence à la FIG. 8 , un procédé de vérification 500 d’une signature individuelle d’un message m i comprise dans une signature agrégée comportant un premier élément ϴ 1 et un deuxième élément ϴ 2 et générée pour un ensemble de messages m 0 , ..., m n , i appartenant à l’intervalle [0,n] en utilisant un procédé de génération d’une signature selon l’invention, à partir du protocole cryptographique de preuve à divulgation nulle de connaissance. Le procédé 500 comporte une étape E520 de vérification de l’égalité : [Math. 8] , où e désigne un couplage bilinéaire défini sur les groupes G 1 et G 2 et à valeurs dans un groupe cyclique G T , et - si ladite égalité est vérifiée une étape E530 de validation de ladite signature individuelle σ i . Ledit procédé 500 de vérification d’une signature individuelle σ i comporte de préférence une étape E510 de pré-traitement au cours de laquelle au moins une première information auxiliaire aux i1 , une deuxième information auxiliaire aux i2 et une troisième information auxiliaire aux i3 sont déterminées à partir des clés publiques g α 0 , ..., g α n issues des paires de clés générées pour la signature desdits messages m 0 , ..., m n et desdits messages. La première information auxiliaire peut être égale à , avec i l’indice du message à vérifier localement. La deuxième information auxiliaire peut être égale à [Math. 10] , avec i l’indice du message à vérifier localement. La troisième information peut être égale à [Math. 11] , avec i l’indice du message à vérifier localement et π ZK une preuve que les preuves de possessions des clés publiques sont valides. Le dispositif de vérification V1, V2, V3 comporte des modules configurés pour mettre en œuvre un procédé 500 de vérification d’une signature individuelle comportant au moins un module M520 de vérification configuré pour mettre en œuvre une étape 520 de vérification de l’égalité ci-dessus, et un module M530 de validation configuré pour mettre en œuvre une étape E530 de validation d’une signature individuelle. De préférence, le dispositif de vérification V1, V2, V3 comporte en outre un module M510 de pré-traitement pour mettre en œuvre une étape 510 de détermination d’informations auxiliaires au cours de laquelle au moins une première information auxiliaire aux i1 , une deuxième information auxiliaire aux i2 et une troisième information auxiliaire aux i3 sont déterminées à partir des clés publiques g α 0 , ..., g α n issues des paires de clés générées pour la signature desdits messages m 0 , ..., m n et desdits messages. Alternativement, le module M510 de pré-traitement peut être compris dans un dispositif d’ouverture (non représenté), distinct du dispositif de vérification V1, V2, V3. Dans un mode particulier de réalisation, les différentes étapes des procédés selon l’invention sont déterminées par des instructions de programmes d’ordinateurs. En conséquence, l’invention vise aussi un programme d’ordinateur sur un support d’informations, ce programme étant susceptible d’être mis en œuvre dans un dispositif utilisateur, et/ou un dispositif de vérification selon l’invention ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé selon l’invention tel que décrit ci-dessus. Ainsi, dans des modes de réalisation particuliers, la plateforme informatique virtualisée 1 a l’architecture matérielle d’un ordinateur, telle que représentée à la FIG. 10 . Il convient de noter que certains éléments de cette architecture peuvent être confondus avec des dispositifs existants. Plus précisément, la plateforme informatique virtualisée de signature 1 peut comporter un processeur PC, une mémoire morte ROM, une mémoire vive RAM, une racine de confiance RoT et des moyens de communication. Il convient de noter que la racine de confiance peut être constituée d’éléments logiciels mais elle est préférentiellement implémentée sous la forme d’un module matériel. La racine de confiance fournit les services de sécurisation de la plateforme. En particulier, elle est utilisée pour stocker et protéger les clés de la plateforme, ces clés ne pouvant être utilisées par les autres ressources sans cette racine de confiance. Cette racine de confiance est par exemple constituée par un module de confiance conforme aux normes standard ISO/IEC. La mémoire morte de la plateforme informatique virtualisée 1 constitue un support d’enregistrement lisible par le processeur et sur lequel est enregistré un programme d’ordinateur conforme à l’invention, comportant des instructions pour l’exécution des étapes d’un procédé selon l’invention détaillé plus haut. Ce programme d’ordinateur définit de façon équivalente des modules fonctionnels (logiciels) de la plateforme informatique virtualisée 1. Ce programme peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. De façon équivalente, dans des modes de réalisation particuliers, les dispositifs utilisateurs U et/ou les dispositifs de vérification ont l’architecture matérielle d’un ordinateur, telle que représentée à la FIG. 10 . Il convient de noter que certains éléments de cette/ces architectures peuvent être confondus avec des dispositifs existants. L’invention vise aussi un support d'informations ou d’enregistrement lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations ou d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, le support d'informations ou d’enregistrement 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 un réseau de type Internet. Alternativement, le support d'informations ou d’enregistrement 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. Bien que la présente invention ait été décrite en se référant à des exemples de réalisation spécifiques, il est évident que des modifications et des changements peuvent être effectués sur ces exemples sans sortir de la portée générale de l'invention telle que définie par les revendications. En particulier, des caractéristiques individuelles des différents modes de réalisation illustrés/mentionnés peuvent être combinées dans des modes de réalisation additionnels. Par conséquent, la description et les dessins doivent être considérés dans un sens illustratif plutôt que restrictif. Il est également évident que toutes les caractéristiques décrites en référence à un procédé sont transposables, seules ou en combinaison, à un dispositif, et inversement, toutes les caractéristiques décrites en référence à un dispositif sont transposables, seules ou en combinaison, à un procédé. Procédé de signature d’un message m i , par un dispositif utilisateur, à partir d’un protocole cryptographique de preuve à divulgation nulle de connaissance défini par un élément g appartenant à un groupe G 1 cyclique d’ordre p, avec p désignant un nombre entier premier, et des éléments u, v, r, s, t appartenant à un groupe G 2 cyclique d’ordre p, une fonction de hachage H et une période de temps courante w, le procédé comportant : - une étape de génération d’une paire de clés privée et publique, la clé privée comportant un élément αi sélectionné dans l’anneau Z/pZ, la clé publique comportant un premier élément g α i et un deuxième élément π i étant une preuve de possession à divulgation nulle de connaissance générée à partir du protocole cryptographique, - une étape de génération d’une signature σ i du message m i à partir de la clé privée et d’un aléa ϐ, la signature comportant - un premier élément σ 1i = (vu H(m) ) α .(r |lg(w)| s w t) ϐ , et - un deuxième élément σ 2i = g ϐ .. Procédé de signature d’un ensemble de messages m0, ..., mn, mis en œuvre dans une plateforme informatique virtualisée comportant une pluralité de dispositifs utilisateurs, à partir d’un protocole cryptographique de preuve à divulgation nulle de connaissance défini par un élément g appartenant à un groupe G1 cyclique d’ordre p, avec p désignant un nombre entier premier, et des éléments u, v, r, s, t appartenant à un groupe G2 cyclique d’ordre p, une fonction de hachage H et une période de temps courante w, le procédé comportant : - pour chaque message mi de l’ensemble de messages, i appartenant à l’intervalle [0, n], la signature du message mi par un dispositif utilisateur de la pluralité de dispositifs utilisateurs, au moyen d’un procédé de génération d’une signature selon la revendication 1 de sorte à générer une signature pour ledit message mi, dite signature individuelle ; - une étape d’agrégation de tout ou partie des signatures individuelles préalablement générées au cours de ladite période de temps courante w de sorte à générer une signature agrégée comportant un premier élément et un deuxième élément. Procédé de signature selon la revendication 2, dans lequel l’étape d’agrégation comporte l’agrégation de signatures individuelles entre elles et/ou de signatures agrégées préalablement générées. Procédé de signature selon l’une quelconque des revendications 2 ou 3, dans lequel la plateforme informatique virtualisée a une architecture du type VNF-FG (Virtual Network Functions-Forwarding Graph). Procédé de vérification, par un dispositif de vérification, d’une signature agrégée comportant un premier élément ϴ 1 et un deuxième élément ϴ 2 et générée pour un ensemble de messages m 0 , ..., m n en utilisant un procédé de génération d’une signature selon l’une quelconque des revendications 2 à 4, à partir d’un protocole cryptographique de preuve à divulgation nulle de connaissance défini par un élément g appartenant à un groupe G 1 cyclique d’ordre p, avec p désignant un nombre entier premier, et des éléments u, v, r, s, t appartenant à un groupe G 2 cyclique d’ordre p, une fonction de hachage H et une période de temps courante w, le procédé comportant : - une étape de vérification de l’égalité : , où e désigne un couplage bilinéaire défini sur les groupes G 1 et G 2 et à valeurs dans un groupe cyclique G T , - Si ladite égalité est vérifiée une étape de validation de ladite signature agrégée. Procédé de vérification selon la revendication 5, comportant une étape préalable de génération d’un agrégat clés-messages à partir des messages m 0 , ..., m n , des clés publiques g α 0 , ..., g α n issues des paires de clés générées pour la signature desdits messages, et de la fonction de hachage H. Procédé de vérification d’une signature individuelle d’un message m i comprise dans une signature agrégée comportant un premier élément ϴ 1 et un deuxième élément ϴ 2 et générée pour un ensemble de messages m 0 , ..., m n , i appartenant à l’intervalle [0,n] en utilisant un procédé de génération d’une signature selon l’une quelconque des revendications 2 à 4, à partir d’un protocole cryptographique de preuve à divulgation nulle de connaissance défini par un élément g appartenant à un groupe G 1 cyclique d’ordre p, avec p désignant un nombre entier premier, et des éléments u, v, r, s, t appartenant à un groupe G 2 cyclique d’ordre p, une fonction de hachage H et une période de temps courante w, le procédé comportant : - une étape de vérification de l’égalité : , où e désigne un couplage bilinéaire défini sur les groupes G 1 et G 2 et à valeurs dans un groupe cyclique G T , - Si ladite égalité est vérifiée une étape de validation de ladite signature individuelle. Procédé selon la revendication 7 comportant une étape de pré-traitement au cours de laquelle au moins une première information auxiliaire aux1, une deuxième information auxiliaire aux2 et une troisième information auxiliaire aux3 sont déterminées à partir des clés publiques g α 0 , ..., g α n issues des paires de clés générées pour la signature desdits messages m 0 , ..., m n et desdits messages de sorte à précalculer des termes de l’égalité de l’étape de vérification. Dispositif utilisateur apte à signer un message m i à partir d’un protocole cryptographique de preuve à divulgation nulle de connaissance défini par un élément g appartenant à un groupe G 1 cyclique d’ordre p, avec p désignant un nombre entier premier, et des éléments u, v, r, s, t appartenant à un groupe G 2 cyclique d’ordre p, une fonction de hachage H et une période de temps courante w, le dispositif utilisateur comportant : - un module de génération configuré pour générer une paire de clés privée et publique, la clé privée comportant un élément αi sélectionné dans l’anneau Z/pZ, la clé publique comportant un premier élément g α i et un deuxième élément π i étant une preuve de possession à divulgation nulle de connaissance générée à partir du protocole cryptographique, - un module de génération apte à générer une signature σ i du message m i à partir de la clé privée et d’un aléa ϐ, ladite signature comportant un premier élément σ 1i = (vu H(m) ) α .(r |lg(w)| s w t) ϐ , et un deuxième élément σ 2i = g ϐ Dispositif de vérification, d’une signature agrégée comportant un premier élément ϴ 1 et un deuxième élément ϴ 2 et générée pour un ensemble de messages m 0 , ..., m n en utilisant un procédé de génération d’une signature selon l’une des revendications 2 à 4, à partir d’un protocole cryptographique de preuve à divulgation nulle de connaissance défini par un élément g appartenant à un groupe G 1 cyclique d’ordre p, avec p désignant un nombre entier premier, et des éléments u, v, r, s, t appartenant à un groupe G 2 cyclique d’ordre p, une fonction de hachage H et une période de temps courante w, le dispositif de vérification comportant : - un module de vérification apte à vérifier l’égalité : , où e désigne un couplage bilinéaire défini sur les groupes G 1 et G 2 et à valeurs dans un groupe cyclique G T , et - un module de validation de la signature agrégée activé si ladite égalité est vérifiée. Dispositif de vérification apte à vérifier une signature individuelle d’un message m i comprise dans une signature agrégée comportant un premier élément ϴ 1 et un deuxième élément ϴ 2 et générée pour un ensemble de messages m 0 , ..., m n , i appartenant à l’intervalle [0,n] en utilisant un procédé de génération d’une signature selon l’une quelconque des revendications 2 à 4, à partir d’un protocole cryptographique de preuve à divulgation nulle de connaissance défini par un élément g appartenant à un groupe G 1 cyclique d’ordre p, avec p désignant un nombre entier premier, et des éléments u, v, r, s, t appartenant à un groupe G 2 cyclique d’ordre p, une fonction de hachage H et une période de temps courante w, le procédé comportant : - un module de vérification de l’égalité : , où e désigne un couplage bilinéaire défini sur les groupes G 1 et G 2 et à valeurs dans un groupe cyclique G T , et - un module de validation de la signature individuelle activé si ladite égalité est vérifiée. Système de communication comportant : - un groupe de dispositifs utilisateurs selon la revendication 9 dont tout ou partie des dispositifs utilisateurs comportent en outre un module d’agrégation apte à agréger tout ou partie des signatures générées par lesdits dispositifs utilisateurs au cours de la période de temps courante w de sorte à générer une signature agrégée comportant un premier élément et un deuxième élément, et - un ou plusieurs dispositifs de vérification selon l’une quelconque des revendications 10 ou 11. Programme d’ordinateur comportant des instructions de code, qui lorsqu’elles sont exécutées au moyen d’un ordinateur permettent la mise en œuvre d’un procédé selon l’une quelconque des revendication 1 à 8. Support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour l’exécution des étapes d’un procédé selon l’une quelconque des revendication 1 à 8.