Brevet FR3147922A1 — publié le 20241018

L’invention porte sur un dispositif informatique portable pour la création d’une pluralité d’identités numériques comprenant au moins une unité de calcul configurée, pour chaque identité numérique de ladite pluralité d’identités numériques, pour : dériver une clé publique de preuve de l’identité numérique; obtenir une preuve de l’identité numérique par l’application d’une fonction de hachage à la clé publique de preuve ; générer un certificat de l’identité numérique comprenant la preuve, et une clé publique applicative associée à l’identité numérique. Figure de l’abrégé : Figure 1 Dérivation de clés de preuve pour la gestion d’une infrastructure à clé publique La présente divulgation relève du domaine de la cryptographie. Plus spécifiquement, elle relève du domaine de la gestion d’une infrastructure à clé publique. De nombreux systèmes de cybersécurité sont basés sur des certificats numériques, utilisant ce que l'on appelle généralement des infrastructures à clés publiques ou PKI (de l’acronyme anglais « Public Key Infrastructure ») normalisés par la recommandation ITU X.509. Dans le cadre d’une architecture PKI, un utilisateur peut être authentifié par un certificat délivré par une autorité de certification, et comprenant une clé publique. L’utilisateur doit être l’unique personne en possession de la clé privée associée à la clé publique. En effet, tout tiers peut alors communiquer de manière sécurisée via la clé publique avec l’utilisateur disposant de la clé privée, tout en ayant la garantie de l’identité de l’utilisateur via le certificat signé par une autorité de certification. La capacité à conserver la clé privée associée est cruciale. À un moment donné, si la sécurité de la clé privée est remise en cause, la meilleure pratique consiste à révoquer le certificat et à reconstruire l'infrastructure à partir de zéro avec un certificat nouvellement généré, associé à une nouvelle paire de clé publique/clé privée. Le coût de tels événements est extrêmement élevé. Ceci rend l'utilisation d'une PKI sécurisée généralement coûteuse. Si les PKI sont généralement basés sur de grands fournisseurs d’identité centralisés, l’approche dite « SSI » (de l’anglais « Self-Sovereign Identity », ou Identité Auto-Souveraine encore appelée parfois « decentralised ID » (terme anglais pour « identité décentralisée » ou « DiD ») consiste à fournir aux individus le contrôle des informations qu’ils utilisent pour s’authentifier. Les coûts de maintiens d’une PKI fiable sont alors d’autant plus élevés qu’ils sont supportés par un individu. Il existe donc un besoin de permettre une gestion sécurisée moins coûteuse d’une infrastructure à clé publique sur l’ensemble de son cycle de vie, notamment en évitant la nécessité de re-générer l’ensemble de l’infrastructure en cas de compromission d’une clé privée. Résumé La présente divulgation vient améliorer la situation. Il est proposé un dispositif informatique portable pour la création d’une pluralité d’identités numériques comprenant au moins une unité de calcul configurée, pour chaque identité numérique de ladite pluralité d’identités numériques, pour : dériver une clé publique de preuve de l’identité numérique ; obtenir une preuve de l’identité numérique par l’application d’une fonction de hachage à la clé publique de preuve ; générer un certificat de l’identité numérique comprenant la preuve, et une clé publique applicative associée à l’identité numérique. On entend par « unité de calcul » un composant électronique apte à effectuer des calculs électroniques ou informatiques pour effectuer une fonction déterminée. Une unité de calcul peut désigner tout type de processeur ou composant électronique apte à effectuer des calculs numériques. Par exemple, une unité de calcul peut être un circuit intégré, un ASIC (de l’acronyme anglais « Application-Specific Integrated Circuit », littéralement en français « circuit intégré propre à une application », un microcontrôleur, un microprocesseur, un DSP (de l’acronyme anglais « Digital Signal Processor », littéralement en français « processeur de signal numérique »), un processeur, un GPU (de l’acronyme anglais « Graphics Processing Unit », littéralement en français « unité de calcul graphique »). Une unité de calcul selon l’invention n’est pas limitée à un type particulier d’architecture de calcul. Par exemple, un processeur peut mettre en œuvre une architecture de type Harvard ou Von Neumann. On entend par « mémoire » un dispositif électronique numérique servant à stocker des données. Différents types de mémoires peuvent être utilisés dans l’invention, telles qu’une mémoire morte, une mémoire vive, une mémoire volatile ou une mémoire flash. Un dispositif selon l’invention peut être équipé d’une ou plusieurs mémoires non volatiles pouvant être de différents types tels que des mémoires de masse, mémoire flash, mémoires mortes ou mémoires SSD. Un dispositif selon l’invention peut également comprendre une ou plusieurs mémoires vives telles que des mémoires RAM, DRAM, SRAM, DPRREAM, VRAM, eDRAM ou 1T-SRAM. On entend par "identité numérique" un lien technologique entre une entité réelle, par exemple une personne physique ou morale, et une représentation numérique. On entend par "dérivation d'une clé" la génération d'une clé enfant à partir d’un nombre, par exemple une clé parente ou un nombre aléatoire. Différents algorithmes de dérivation de clé sont utilisables dans le cadre de l'invention. Des algorithmes de génération de clés étendues tels que l'algorithme HMAC-SHA512 utilisé dans la spécification BIP32 de Bitcoin sont notamment applicables à l'invention. De tels algorithmes présentent l'avantage de pouvoir générer une clé publique enfant à partir d'une clé publique parente, sans avoir à générer la clé privée enfant, et sans nécessiter la clé privée parente. On entend par "clé publique de preuve de l'identité numérique" la clé publique d'une paire de clé associée à l'identité numérique. On entend par "preuve de l'identité numérique" une donnée et permettant à tout tiers de vérifier l’identité numérique. Une preuve peut parfois être appelée « commitment ». On entend par "clé publique applicative" la clé publique d'une paire de clés associée à une application pouvant être utilisée de manière sécurisée par l'identité numérique. La clé publique de preuve peut être associée à différentes applications, par exemple des applications de paiement en ligne ou de messagerie sécurisée. Ainsi, le certificat d’identité et la clé applicative sont liés la preuve, et le certificat permet à un tiers de s’assurer que l’identité est valide, et que la clé publique est bien associé à cette identité, ce qui permet des transaction sécurisées. De plus, en cas de doute quant à l’intégrité de la clé privée applicative liée à la clé publique applicative, un unique certificat doit être généré, comprenant une clé privée d’une nouvelle paire de clés applicatives, sans besoin de reconstruire l’ensemble d’une infrastructure à clé publique. La méthode selon l’invention permet donc de gérer des identités numériques de manière sécurisée sur le long terme à un coût raisonnable. Selon un autre aspect, il est proposé une méthode mise en œuvre par au moins une unité de calcul de création d’une pluralité d’identités numériques comprenant : la dérivation d’une clé publique de preuve de l’identité numérique ; l’obtention d’une preuve de l’identité numérique par l’application d’une fonction de hachage à la clé publique de preuve ; la génération d’un certificat de l’identité numérique comprenant la preuve, et une clé publique applicative associée à l’identité numérique. Selon un autre aspect, il est proposé une méthode mise en œuvre par au moins une unité de calcul de vérification d’une identité numérique d’indice subséquent comprenant : une réception d’un certificat d’une identité numérique d’indice immédiatement antérieur à l’indice subséquent, ledit certificat de l’identité numérique d’indice immédiatement antérieur comprenant : une preuve de l’identité numérique d’indice immédiatement antérieur ; une clé publique applicative associée à l’identité numérique d’indice immédiatement antérieur ; une réception d’un certificat d’échange signé associé à l’identité numérique d’indice subséquent, ledit certificat d’échange comprenant: un condensat du certificat de l’identité numérique d’indice immédiatement antérieur ; une clé de preuve privée de l’identité numérique d’indice immédiatement antérieur ; une preuve de l’identité numérique d’indice subséquent ; une clé publique applicative associée à l’identité numérique d’indice subséquent; une vérification de la validité du certificat d’échange, ladite vérification de la validité du certificat d’échange comprenant : une vérification que le condensat du certificat de l’identité numérique d’indice immédiatement antérieur est identique à un condensat obtenu par l’application d’une fonction de hachage au certificat de l’identité numérique d’indice immédiatement antérieur; une vérification que la preuve de l’identité numérique d’indice immédiatement antérieur est identique à l’application d’une fonction de hachage à la clé de preuve publique de l’identité numérique d’indice immédiatement antérieur ; une vérification que la signature du certificat d’échange est une signature valide du certificat initial avec la clé privée de preuve d’indice immédiatement antérieur. Selon un autre aspect, il est proposé un programme informatique comportant des instructions pour la mise en œuvre de tout ou partie d’un procédé tel que défini dans les présentes lorsque ce programme est exécuté par un processeur. Selon un autre aspect, il est proposé un support d’enregistrement non transitoire, lisible par un ordinateur, sur lequel est enregistré un tel programme. Les caractéristiques exposées dans les paragraphes suivants peuvent, optionnellement, être mises en œuvre, indépendamment les unes des autres ou en combinaison les unes avec les autres : Avantageusement, l’au moins une unité de calcul est configurée pour dériver la clé publique applicative à partir de la clé publique de preuve. Ceci permet de générer une clé publique applicative liée à la clé publique de preuve, tout en ayant la possibilité de générer la clé privée applicative correspondante à partir de la clé privée de preuve. Avantageusement, la clé publique de preuve est dérivée à partir d’une clé parente et d’un indice de l’identité numérique Ceci permet de dériver des clés publiques de preuve uniques pour chaque indice. La dérivation des clés de preuve et génération des certificats associés peut se faire sans avoir à communiquer la clé parente, ce qui permet de générer autant de nouvelles preuves et certificats associés que nécessaires. Ceci permet donc de s’assurer que l’émetteur utilisant la clé applicative est bien le titulaire de la clé parent. Avantageusement, la clé parente est la clé publique d’une paire de clés parentes (par), ladite au moins une unité de calcul étant configurée pour, préalablement à ladite dérivation de la clé de preuve, dériver de la paire de clés parentes à partir d’une graine aléatoire engravée dans une mémoire morte du dispositif. On entend par "graine aléatoire" (en anglais random seed) un nombre utilisé pour l'initialisation d'un générateur de nombre pseudo-aléatoires, par exemple un générateur de clé. Afin de garantir le caractère véritablement aléatoire de la graine, la graine peut être générée à partir de l'état d'un système physique (par exemple en fonction d'une valeur d'horloge lue au moment de la génération, ou via un générateur de nombres aléatoires matériel). Ceci permet de ré-générer au besoin la clé parente, afin de sécuriser le dispositif de génération de clés sur le long terme. La génération s’effectuant à partir de la graine aléatoire engravée dans une mémoire du dispositif, les clés ne peuvent être corrompues sans obtenir physiquement le dispositif. Avantageusement, ladite au moins une unité de calcul est configurée, à l’issue de l’obtention de la preuve et de la dérivation de la paire de clés applicatives, pour supprimer ladite clé publique de preuve. Par "suppression de ladite clé publique de preuve", on entend la suppression de toute copie de la clé de preuve de toutes les mémoires où une telle copie a pu être copiée. La suppression de la clé de preuve permet d’éviter que la clé de preuve soit stockée, et donc potentiellement compromise, tout en réservant la possibilité de régénérer la clé de preuve à partir de la clé parente et de l’indice de l’identité numérique. Ceci renforce donc encore la sécurité de la génération des clés, tout en préservant la fonctionnalité du système. Avantageusement, l’identité numérique est une identité numérique initiale associée à un indice initial. Ceci permet de publier un certificat initial associé à une identité numérique initiale. Avantageusement, l’identité numérique est une identité numérique subséquente; le certificat est un certificat d’échange signé avec la clé privée de preuve associée à la clé publique de preuve de l’identité numérique d’indice immédiatement antérieur à l’indice subséquent, ledit certificat d’échange comprenant : un condensat obtenu par l’application d’une fonction de hachage à un certificat de l’identité numérique de l’indice immédiatement antérieur; la clé privée de preuve associée à la clé publique de preuve de l’identité numérique de l’indice immédiatement antérieur. Ceci permet de publier un certificat d’échange associé à un changement d’identité numérique Le certificat d’échange est lié au certificat d’identité d’indice immédiatement antérieur, et peut être lié de manière déterministe à celui-ci, puisque : la présence du condensat du certificat immédiatement antérieur permet à un destinataire de s’assurer qu’il s’agit bien du certificat suivant dans la chaîne de certificat successifs ; la publication de la clé privée de preuve d’indice immédiatement antérieur permet à un destinataire de retrouver la clé publique de preuve d’indice immédiatement antérieur, et vérifier que : la preuve du certificat immédiatement antérieur est bien un condensat de la clé publique d’indice immédiatement antérieur ; le certificat d’échange est bien signé avec la clé privée d’indice immédiatement antérieur Dit autrement, un certificat d’échange ne peut-être validement émis que par une personne ayant à sa disposition la clé privée de preuve d’indice immédiatement antérieur. Un tel certificat ne peut donc pas être émis par un tier, puisque, avant son émission, ni la clé publique de preuve, ni a fortiori la clé privée de preuve, n’avaient été publiées. Par ailleurs, le certificat d’échange ayant vocation à remplacer le certificat précédent, la publication à ce stade de la clé privée de preuve d’indice antérieur n’est pas préjudiciable, puisqu’elle n’a plus vocation à être utilisée. Avantageusement, les clés publiques et les clés privées sont des clés étendues, et l’au moins une unité de calcul est configurée pour dériver les clés par une dérivation de clés étendue utilisant une fonction de hachage de type HMAC. On entend par "clé étendue" un couple entre une clé et un code de chaîne, dans lequel la possession du code de chaîne est nécessaire pour dériver des clés enfant. On entend par "fonction de hachage de type HMAC (de l'anglais "Hashed-Based Message Authentication Code", en français "Message de Code d'Authentification Basé sur un Condensat") un type de code d'authentification de message vérifiant simultanément l'intégrité des données et l'authenticité d'un message. Ce type de fonction est par exemple décrit par Bellare, M., Canetti, R., & Krawczyk, H. (1996, August). Keying hash functions for message authentication. In Annual international cryptology conference (pp. 1-15). Springer, Berlin, Heidelberg. Et Bellare, M., Canetti, R., & Krawczyk, H. (1996). Message authentication using hash functions: The HMAC construction. RSA Laboratories’ CryptoBytes, 2(1), 12-15. Un exemple d'une telle fonction est l'algorithme de dérivation de clé HMAC-SHA512 utilisé dans la spécification BIP32 du Bitcoin. L’utilisation d’une dérivation de clé étendue via une fonction de hachage de type HMAC permet de dériver séparément des clés privées et des clés publiques d’une même paire. Par exemple, une clé publique enfant peut être obtenue à partir de la clé publique parent uniquement sans avoir à générer la clé privée enfant, alors que la clé privée correspondante peut être générée à partir de la clé privée parente. Ceci permet d’améliorer encore la sécurité de la génération des clés, car il n’est même pas nécessaire de générer la clé privée de preuve pour dériver la clé publique de preuve. Avantageusement, l’au moins une unité de calcul est configurée pour obtenir au moins une des clés publiques à partir d’au moins une des clés privées et d’une courbe elliptique. On entend par "courbe elliptique" (en anglais "Elliptic Curve Cryptography" ou "ECC", en français "Cryptographie par Courbe Elliptique") un ensxemble de technioques cryptographiques utilisant les propriétés des courbes elliptiques, notamment pour déduire d'une clé privée une clé publique. Ces algorithmes comprennent par exemple l'algorithm ECDSA (de l'anglais "Elliptic Curve Digital Signature Algorithm", en français 'Algorithme de Signature Numérique par Courbe Elliptique") décrit par Johnson, D., Menezes, A., & Vanstone, S. (2001). The elliptic curve digital signature algorithm (ECDSA). International journal of information security, 1(1), 36-63. L’utilisation d’une courbe elliptique permet d’obtenir une clé publique à partir d’une clé privée, mais rend l’opération inverse est en pratique impossible. Ceci permet donc de pouvoir régénérer les clés privées à partir des clés publiques, sans pouvoir retrouver les clés privées à partir des clés publiques D’autres caractéristiques, détails et avantages apparaîtront à la lecture de la description détaillée ci-après, et à l’analyse des dessins annexés, sur lesquels : Fig. 1a montre un exemple d’échange de certificats dans un système de télécommunication au sein duquel l’invention peut être implémentée. Fig. 1b montre un exemple d’échange de données dans un système de télécommunication au sein duquel l’invention peut être implémentée. Fig. 2 montre un exemple de dispositif informatique portable selon un mode de réalisation. Fig. 3 montre un exemple de méthode dans un ensemble de modes de mise en œuvre de l’invention. Fig. 4 montre un premier exemple de génération d’identités numériques dans un ensemble de modes de réalisation de l’invention. Fig. 5 montre un deuxième exemple de génération d’identités numériques dans un ensemble de modes de réalisation de l’invention. Fig. 6 montre une pluralité de certificats selon un ensemble de modes de réalisation. Fig. 7 montre un exemple de vérification d’une identité numérique par un certificat d’échange selon un mode de réalisation. Il est maintenant fait référence à la . La montre un exemple de système de télécommunication au sein duquel trois utilisateurs Ut1, Ut2 et Ut3 communiquent via 3 applications App1, App2 et App3. Les applications App1, App2 et App3 peuvent être tout type d’applications nécessitant des échanges de données sécurisés entre utilisateurs authentifiés. Par exemple, il peut s’agir d’applications pour effectuer des transactions en cryptomonnaies, de paiement sécurisé, de messagerie sécurisée, etc.. L’utilisateur Ut1 est équipé d’un smartphone Tel1, sur lequel les trois applications App1, App2 et App3 sont installés, ainsi qu’un gestionnaire d’infrastructure à clé publique PKI1. L’utilisateur Ut2 est équipé d’un smartphone Tel2 sur lequel les trois applications App1, App2 et App3 sont installés. L’utilisateur Ut2 utilise un gestionnaire d’infrastructure PKI2 dans un dispositif externe dédié PKI2 pouvant se connecter au smartphone Tel2. Ainsi, la gestion de l’infrastructure PKI par l’utilisateur Ut2 est gérée par le dispositif externe dédié PKI2, et non par le smartphone Tel2. Une telle configuration renforce la sécurité de l’identité numérique de l’utilisateur Ut2, car la gestion de ses identités numériques est effectuée par un matériel dédié. De plus, la gestion des identités numériques peut alors mettre en œuvre une graine aléatoire PKey2 engravée dans le dispositif externe PKI2, et donc inviolable tant que l’utilisateur Ut2 est en possession du dispositif PKI2. L’utilisateur Ut3 est équipé d’un smartphone Tel3, sur lequel les applications App1, et App3 sont installés, ainsi qu’un gestionnaire d’infrastructure à clé publique PKI3. L’utilisateur Ut3 est également équipé d’un ordinateur fixe Ord3 en connexion avec le smartphone Tel3, sur lequel l’application App2 est installé. Les gestionnaires d’infrastructures PKI1, PKI2, et PKI3 sont en communication les uns avec les autres. Ceci permet aux utilisateurs Ut1, Ut2 et Ut3 : d’émettre des certificats permettant d’authentifier leur identité numérique ; de vérifier les certificats émis par les autres utilisateurs. Un système tel que le système Sys permet donc une gestion décentralisée des identités numériques, dans laquelle chaque utilisateur publie les certificats relatifs à son identité numérique, et vérifie la validité des certificats émis par les tiers. De plus, les certificats peuvent comprendre des clés publiques applicatives liées aux différentes applications App1, App2 et App3. Il est maintenant fait référence à la . La montre un exemple d’échange de données dans le système Sys déjà représenté en . La montre plus particulièrement un exemple d’échange de données dans le système Sys, dans lequel : l’application App3 de l’utilisateur Ut1 communique avec l’application App3 de l’utilisateur Ut2 sur le téléphone Tel2 ; l’application App1 de l’utilisateur Ut1 communique avec l’application App1 de l’utilisateur Ut3 sur le téléphone Tel3 ; l’application App1 de l’utilisateur Ut2 sur le téléphone Tel2 communique avec l’application App1 de l’utilisateur Ut3 sur le téléphone Tel3 ; l’application App2 de l’utilisateur Ut2 sur le téléphone Tel2 communique avec l’application App2 de l’utilisateur Ut3 sur l’ordinateur Ord3. Comme indiqué ci-dessus, les certificats émis peuvent comprendre des clés applicatives publiques. Par exemple, le gestionnaire d’infrastructure PKI2 peut émettre un certificat pour l’utilisateur Ut2 et l’application App1, comprenant une clé publique pour l’application App1, et une preuve de l’identité de l’utilisateur Ut2, et transmettre ce certificat à Ut3. Ut3 peut ainsi : vérifier l’identité de Ut2 ; utiliser la clé publique de l’application App1 pour communiquer de manière sécurisée avec Ut2, étant entendu que Ut2 possède la clé privée applicative associée à la clé publique. Comme il sera expliqué plus en détails ci-après, une infrastructure de clé publique selon l’invention permet ainsi à la fois de vérifier l’identité d’un utilisateur, et de valider que la clé applicative utilisée par une application est bien liée à son identité. L’échange et la vérification des certificats montré sur la permet aux applications des différents utilisateurs de communiquer de manière sécurisée, comme montré sur la . La montre un exemple de dispositif informatique portable selon un mode de réalisation. Le dispositif Disp est un dispositif pour la création d’une pluralité d’identités numériques. Il peut par exemple s’agir du gestionnaire d’infrastructure PKI2. Dans l’exemple de la , le dispositif est une clé USB, qui peut être utilisée pour créer des identités numériques lorsqu’elle est connectée à un dispositif utilisateur telle qu’une tablette, un ordinateur ou un smartphone. A cet effet, le dispositif Disp comprend une unité de calcul Calc configurée pour exécuter tout ou partie des étapes d’une méthode selon l’invention. Dans un ensemble de modes de réalisation de l’invention, le dispositif Disp peut également comprendre une ou plusieurs mémoires Mem stockant au moins une clé privée PKey utilisée pour la génération de clés et de certificats. Le dispositif Disp peut notamment comprendre au moins une mémoire morte dans laquelle est engravée une graine aléatoire servant à la génération de clés. Ceci permet de rendre les clés stockées sur le dispositif inviolables tant que les dispositif est en possession de l’utilisateur, notamment lorsque qu’une graine aléatoire engravée dans une mémoire morte sert de base à la génération des clés. Par exemple, si le dispositif Disp est une clé USB, l’utilisateur peut stocker la clé USB dans un coffre fort sécurisé, et ne la sortir du coffre-fort que lorsque de nouvelles clés et de nouveaux certificats doivent être régénérés. Bien que le dispositif représenté en soit une clé USB, l’invention n’est nullement limitée à cet exemple. D’autres dispositifs portables pourraient être utilisés, comme par exemple une carte à puce, ou carte informatique. Bien que la montrer un exemple de dispositif spécifiquement dédié à la création d’une pluralité d’identités numériques, l’invention n’est pas limitée à cet exemple. Par exemple, selon l’invention, des identités numériques peuvent également être créées par un gestionnaire d’identités numériques installé sur un dispositif non-spécifique, par exemple un smartphone. Il est maintenant fait référence à la . La montre un exemple de méthode dans un ensemble de modes de mise en œuvre de l’invention. La méthode P3 est une méthode de création d’une pluralité d’identités numériques mise en œuvre par au moins une unité de calcul, par exemple l’unité de calcul Calc. La méthode P3 comprend au moins trois étapes S32, S33 et S36 mises en œuvre pour la création de chaque identité numérique. Les étapes S32, S33 et S36 sont décrites ci-après dans le cadre de la création d’une identité numérique. L’étape S32 est une étape de dérivation d’une clé publique de preuve de l’identité numérique. Cette dérivation peut se faire à partir d’une valeur obtenue de différentes manières. Par exemple, la dérivation peut se faire : à partir d’un nombre aléatoire généré par un générateur de nombres aléatoires ou « RNG » (Random Number Generator) ; à partir d’une clé parente et d’un indice de l’identité numérique. L’étape S33 est une étape d’obtention d’une preuve de l’identité numérique par l’application d’une fonction de hachage à la clé publique de preuve. Différents types de fonctions de hachage peuvent être utilisées. Par exemple, une fonction de hachage de type SHA-256 peut être utilisée pour obtenir la preuve. Ainsi, la preuve est le condensat de l’application de la fonction de hachage à la clé publique de preuve. L’étape S36 est une étape de génération d’un certificat de l’identité numérique comprenant la preuve, et une clé publique applicative associée à l’identité numérique. La clé publique applicative est une clé publique d’une paire de clé utilisée par une application, et liée à l’identité numérique. Par exemple, le titulaire de l’identité numérique peut également posséder la clé privée applicative associée à la clé publique applicative, ce qui lui permet de communiquer de manière sécurisée avec des tiers pour une application donnée, tout en permettant aux tiers de faire le lien entre les clés utilisées et l’identité numérique de l’utilisateur. Ainsi, le certificat d’identité et la clé applicative sont liés à la preuve, et le certificat permet à un tiers de s’assurer que l’identité est valide, et que la clé publique est bien associé à cette identité, ce qui permet des transaction sécurisées. De plus, en cas de doute quant à l’intégrité de la clé privée applicative liée à la clé publique applicative, un unique nouveau certificat doit être généré, comprenant une clé privée d’une nouvelle paire de clés applicatives, sans besoin de reconstruire l’ensemble d’une infrastructure à clé publique. La méthode P3 permet donc de gérer des identités numériques de manière sécurisée sur le long terme à un coût raisonnable. Comme mis en évidence ci-avant, toutes les étapes représentées en ne sont pas essentielles à l’invention. Ainsi, par exemple, les étapes S31, S34, S35 et S37 peuvent n’être implémentées que dans certains modes de mise en œuvre de l’invention. Il est maintenant fait référence à la . La montre un exemple de génération d’identités numériques dans lequel les clés publiques de preuve et les clés applicatives sont dérivées à partir d’un générateur de nombres aléatoire. La montre plus précisément la génération de trois identités numériques ID40, ID41 et ID4N. Dans cet exemple la génération de chaque identité numérique ID40, ID41 et ID4N comprend : la dérivation, à partir d’un générateur de nombres aléatoires RNG, d’une clé publique de preuve de l’identité numérique, respectivement prvK40, prvK41, prvK4N ; l’obtention d’une preuve de l’identité numérique, respectivement prvK40, prvK41, prvK4N, par l’application d’une clé de hachage à la clé publique de preuve, respectivement prv40, prv41, prv4N ; la génération d’un certificat comprenant la preuve, respectivement prv40, prv41, prv4N, et une clé applicative, respectivement appk40, appk41, appK4N. Ceci permet donc à chaque étape d’obtenir des clés de preuve d’identité, preuve d’identité et clé applicative uniques. De retour à la , la méthode P3 peut de manière optionnelle comprendre plusieurs étapes ou modes de réalisation additionnels. Dans certains modes de réalisation de l’invention, certaines des clés publiques ou privées (par exemple, les clés de preuve et clés applicatives) sont des clés étendues, et les clés peuvent être dérivées les unes des autres grâce à une dérivation de clé étendue. La dérivation de clé étendue permet de dériver séparément, à partir d’une paire de clé publique / clé privée parente, une paire de clé publique / clé privée enfant : la clé publique enfant peut être dérivée à partir de la clé publique parente (ou de la clé privée parente), mais la clé privée enfant correspondante doit être dérivée à partir de la clé privée parente. Ainsi, la clé publique enfant peut être dérivée à partir de la clé publique parente sans avoir à aucun moment besoin de générer la clé privée enfant, mais il reste possible si besoin de dériver la clé privée enfant à partir de la clé privée parent. La dérivation de clés étendue peut par exemple utiliser une fonction de hachage de type HMAC. En complément, une clé privée et une clé publique d’une même paire peuvent être liées entre elles par une courbe elliptique. Elles peuvent par exemple être liées par l’algorithme ECDSA (Elliptic Curve Digital Signature Algorithm). D’autres algorithmes peuvent être mis en œuvre pour lier les clés publiques et clés privées. Par exemple, elles peuvent être liées par l’algorithme Schnorr. Ceci permet de dériver la clé publique d’une paire à partir de la clé publique et de la courbe elliptique, mais il est en pratique impossible de dériver la clé privée à partir de la clé publique. Ceci permet donc de regénérer au besoin les clés publiques à partir des clés privés, sans permettre aux détenteurs d’une clés publique de retrouver la clé privée correspondante. La méthode P3 peut ainsi comprendre une étape P34 de dérivation de la clé publique applicative à partir de la clé publique de preuve. Ceci permet de générer une clé publique applicative liée à la clé publique de preuve, tout en ayant la possibilité de générer la clé privée applicative correspondante à partir de la clé privée de preuve, notamment si les clés de preuve et clés applicatives sont des clés étendues. La génération de la clé privée n’est alors pas nécessaire au moment de la génération du certificat, ce qui permet de limiter fortement le risque de vol d’une clé privée. La clé publique de preuve peut elle-même être dérivée à partir d’une clé parente et d’un indice de l’identité numérique. Ainsi, une clé de preuve unique peut être générée pour chaque indice, ce qui permet de générer autant de nouvelles preuves et certificats associés que nécessaires. La génération et publication de certificats peut ainsi se faire sans avoir à communiquer la clé parente, mais permet de s’assurer que l’émetteur utilisant la clé applicative est bien le titulaire de la clé parent. Une première identité peut ainsi avoir été générée avec un indice initial, puis, pour chaque nouvelle identité et nouveau certificat à générer, l’indice peut être incrémenté à s’étape S37, avant de revenir à l’étape S32 pour la génération des clés et certificat associés à l’identité. Dans d’autres modes de réalisation, la clé publique applicative ou de preuve peuvent être générées à partir d’autres sources d’entropie, comme par exemple le générateur de nombre aléatoires RNG dans l’exemple de la . La clé parente peut elle-même être la clé publique d’une paire de clé parentes. Dans ce cas, la méthode P3 peut comprendre une étape préalable S31 de dérivation de la paire de clés parentes à partir d’une clé aléatoire engravée dans une mémoire morte d’un dispositif tel que le dispositif Disp représenté en . Ainsi, la clé parente peut être régénérée au besoin à partir de la graine aléatoire, mais ne peut être corrompue sans obtenir physiquement le dispositif Disp. Ceci permet de sécuriser l’architecture à clé publique sur le long terme, car l’ensemble des clés ne peuvent être ré-générées que par la personne en possession physique du dispositif Disp. Une autre étape facultative est l’étape S35 consistant à supprimer, à l’issue de l’étape S33 ou S34, la clé publique de preuve. En effet, lorsque la clé publique de preuve est générée à partir d’une clé parente, elle peut être régénérée à tout moment, par exemple à partir de la clé parente et de l’indice de l’identité numérique. Elle peut donc être supprimée après avoir été utilisée pour obtenir la preuve de l’identité numérique, et/ou après avoir été utilisée pour dériver la clé applicative. Ainsi, il n’y a pas besoin de stocker la clé de preuve, ce qui limite les risques de compromission de celle-ci. Il est maintenant fait référence à la . La montre un deuxième exemple de génération d’identités numériques dans un ensemble de modes de réalisation de l’invention. La montre la génération de toris identités numériques ID50, ID51 et ID52. Dans l’exemple de la : une graine aléatoire grn est générée à partir d’un générateur de nombres aléatoires ; une clé publique parente est générée à partir de la graine aléatoire ; pour chacune des identités ID50, ID51 et ID5N respectivement : la clé publique de preuve prvK50, prvK51, prvK5N est dérivée à partir de la clé publique parente par, et d’un indice de chaque identité numérique (respectivement 0, 1 et N pour les identités ID50, ID51 et ID5N ; la preuve prv50, prv51, prv5N est obtenue par le hachage de la clé publique de preuve prvK50, prvK51, prvK5N ; la clé publique applicative appK50, appK51, appK5N est obtenue par dérivation de la clé publique de preuve prvK50, prvK51, prvK5N ; un certificat de l’identité numérique est généré et publié, comprenant à chaque fois la clé publique applicative appK50, appK51, appK5N, et la preuve prv50, prv51, prv5N. La montre les relations de dépendances entre les différentes clés par des flèches. On peut noter ici que : grâce au principe de dérivation de clé étendue, il n’est pas nécessaire pour la génération et la publication de certificat de générer de clé privée, seule les clés publiques peuvent être générées. Ceci permet donc de ne pas générer ni de stocker de clé privée au moment de la publication du certificat ; l’ensemble des clés publiques et privées peuvent être régénérées à partir de la clé parente et de l’indice de l’identité numérique. Il est maintenant fait référence à la . La montre une pluralité de certificats selon un ensemble de modes de réalisation. Selon différents modes de réalisation de l’invention, différentes identités numériques peuvent être considérées : une identité numérique initiale est associée à un certificat initial ; une identité numérique subséquente, pouvant être associée à un nouveau certificat initial, ou un certificat d’échange. Par exemple, dans l’exemple de la : une identité numérique initiale ID40 est associée à un certificat initial ; des identités numériques subséquentes ID41 … ID4N peuvent être chacune associée à un certificat initial, ou à un certificat d’échange actant le remplacement d’une identité numérique par une nouvelle identité. L’utilisation d’un certificat d’échange permet de remplacer l’identité numérique par une nouvelle identité numérique, par exemple si une clé privée applicative est compromise. La représente : un certificat initial C6 d’une identité initiale C60 ; et deux certificats d’échange (ou « swapping certificates » en anglais) C61 et C62 de deux identités numériques subséquentes ID61 et ID62. La publication de chaque certificat d’échange a pour effet de révoquer le certificat précédent, et de le remplacer par le certificat d’échange. Par exemple, lorsque le titulaire des identités ID60, ID61 et ID62 publie le certificat d’échange C61, l’identité numérique ID60 ne doit plus être utilisée et doit être remplacée par l’identité numérique ID61 ; lorsque le titulaire des identités ID60, ID61 et ID62 publie le certificat d’échange C62, l’identité numérique ID61 ne doit plus être utilisée et doit être remplacée par l’identité numérique ID62, etc. Le certificat initial C60 contient une preuve prv60 de l’identité, et une clé applicative appK60. Le certificat d’échange C61 contient une preuve prv61 de l’identité, et une clé applicative appK61, pouvant être par exemple obtenus selon les modes de réalisation présentés en figures 4 et 5. Le certificat d’échange C61 contient de plus : un condensat cnd6 obtenu par l’application d’une fonction de hachage au certificat C60 de l’identité numérique ID60 ; la clé privée de preuve prvK60 associée à la clé publique de preuve de l’identité ID60 ; une signature du certificat avec la clé privée prvK60. Le titulaire de l’identité C61 peut donc générer un certificat d’échange tel que le certificat C61 de la manière suivante : en générant la preuve prv61 et la clé publique applicative appK61 ; en appliquant une fonction de hachage au certificat C60 pour obtenir le condensat cnd60 ; en insérant la clé privée de preuve prvK60 dans le certificat. Dans certains modes de réalisation de l’invention, il est possible qu’à ce stade la clé privée de preuve prvK60 ait été effacée, ou n’ait pas été générée. Dans ce cas, le titulaire des identités numériques peut générer prvK60, par exemple par dérivation de la clé privée parente par ; en signant le certificat avec la clé privée prvK60. Un tel certificat d’échange permet de sécuriser l’échange de d’identités numériques de plusieurs manières. Tout d’abord, la présence du condensat du certificat immédiatement antérieur permet d’établir un chaînage des certificats, et de s’assurer que le certificat C61 vient bien remplacer le certificat C60. Par ailleurs, la publication de la clé privée de preuve prvK60, et la signature sig61 du certificat par la clé privée de preuve prvK60 permettent de s’assurer que seule la personne valablement en possession de la clé privée de preuve prvK60 (c’est-à-dire le titulaire de l’identité ID60) peut générer et publier le certificat C61. La preuve prv60 peut également être retrouvée grâce à la clé privée de preuve prvK60, en dérivant la clé publique de preuve correspondante, puis en appliquant une fonction de hachage à la clé publique de preuve. Ainsi, un tiers peut s’assurer que la clé privée de preuve prvK60 correspondent bien à la même identité. Ainsi, la publication de la clé privée de preuve prvK60 se fait uniquement au moment où le titulaire en a besoin, c’est-à-dire pour permettre la publication d’un certificat d’échange prouvant de manière certaine le lien entre les identités numériques. La publication du certificat d’échange C61 ayant également pour effet que l’identité C60, et donc la clé d’application appK60 ne pourront plus être utilisées, la publication de la clé privée de preuve prvK60 n’est pas préjudiciable. L’utilisation de condensat permet d’améliorer la traçabilité lors de l’échange. La publication de la clef privée se fait uniquement au moment où un utilisateur en a besoin, notamment dans le cas où des certificats différents sont nécessaires pour différentes applications. C’est le point important de différenciation avec la norme X509 où la publication du CA (Certificat d’Autorité) est nécessaire, c’est-à-dire que dans la norme X.509 le certificat d’autorité doit être connu pour vérifier la validité des certificats signés, alors que, dans le cadre de l’invention la publication ne se fait qu’au moment du besoin, par exemple au moment de l’échange. Ceci rend le système de l’invention plus simple d’utilisation, car il n’y a pas besoin de synchroniser de certificats racines. A l’issue de la publication du certificat d’échange C61, le titulaire de l’identité C61 pourra communiquer avec des tiers grâce à la clé publique d’application appK61, et la clé privée correspondante. Si un nouvel échange d’identité est nécessaire, le titulaire des identités ID60 et ID61 peut générer un nouveau certificat d’échange C62 comprenant, sur le même principe que le certificat C61 : le condensat cnd61 du certificat C61 ; la preuve prv62 de la nouvelle identité ID62 ; la clé privée de preuve prvK61 associée à l’identité ID61 ; la clé publique applicative appK62 de la nouvelle identité ID62 ; une signature sig62 du certificat, par la clé privée de preuve prvK61. Il est ainsi possible de générer autant de certificats d’échange que nécessaire. Les certificats d’échanges permettent ainsi de remplacer les identités numériques dès que nécessaire (par exemple, par période et/ou lorsqu’une clé liée à une identité est compromise). Les certificats d’échange permettent donc une gestion sécurisée et peu coûteuse des identités numériques. Il est maintenant fait référence à la . La montre un exemple de vérification d’une identité numérique par un certificat d’échange selon un mode de réalisation. La méthode P7 est une méthode de vérification d’une identité numérique d’indice subséquent, par exemple l’identité numérique ID61 ou ID62. La méthode P7 peut être mise en œuvre par un tiers souhaitant vérifier la validité d’un certificat d’échange. Par exemple, si le certificat à vérifier est émis par le gestionnaire PKI2, la méthode P7 peut être mise en œuvre par le gestionnaire PKI1 ou PKI3. Cette méthode comprend les étapes suivantes : une étape S70 de réception du certificat de l’identité d’indice immédiatement antérieur. Par exemple, il peut s’agir de la réception du certificat C60 ou C61 ; une étape S71 de réception du certificat de l’identité numérique d’indice subséquent, par exemple le certificat C61 ou C62 ; une étape S72 de vérification de la validité du certificat d’échange. L’étape S72 comprend elle-même 3 sous-étapes : une vérification que le condensat du certificat de l’identité numérique d’indice immédiatement antérieur est identique à un condensat obtenu par l’application d’une fonction de hachage au certificat de l’identité numérique d’indice immédiatement antérieur. Par exemple, si le certificat d’échange à vérifier est le certificat C62, cette étape consiste à vérifier que le condensat cnd61 inclus dans le certificat est bien identique à l’application de la fonction de hachage (par exemple SHA256, ou tout autre fonction de hachage) au certificat C61 ; une vérification que la preuve de l’identité numérique d’indice immédiatement antérieur est identique à l’application d’une fonction de hachage à la clé de preuve publique de l’identité numérique d’indice immédiatement antérieur. Par exemple, si le certificat d’échange à vérifier est le certificat C62, cette étape consiste à vérifier que la preuve prv61 inclus dans le certificat C61 est bien égale à l’application d’une fonction de hachage à la clé publique obtenue par dérivation de la clé privée prvK61 comprise dans le certificat C62 ; une vérification que la signature du certificat d’échange est une signature valide du certificat initial avec la clé privée de preuve d’indice immédiatement antérieur. Par exemple, si le certificat d’échange à vérifier est le certificat C62, cette étape consiste à vérifier que la signature sig62 est bien une signature du certificat C62 par la clé prvK61. Si plusieurs certificats d’échange ont déjà été émis, la vérification peut s’effectuer de manière itérative sur plusieurs certificats. Par exemple, si le certificat à vérifier est le certificat C62 et que le certificat C61 n’a pas encore été vérifié, la méthode de vérification peut comprendre la vérification du certificat C61, puis celle du certificat C62. La présente divulgation ne se limite pas aux exemples de méthode, programme d’ordinateur et dispositif décrits ci-avant, seulement à titre d’exemple, mais elle englobe toutes les variantes que pourra envisager l’homme de l’art dans le cadre de la protection recherchée. Dispositif informatique portable (Disp ; PKI2 ; Tel3) pour la création d’une pluralité d’identités numériques (ID40 ; ID41 ; ID42 ; ID50 ; ID51 ; ID52 ; ID60 ; ID61 ; ID62) comprenant au moins une unité de calcul (Calc) configurée, pour chaque identité numérique de ladite pluralité d’identités numériques, pour : dériver (S32) une clé publique de preuve de l’identité numérique (prvK40 ; prvK41, prvK4N, prvK50 ; prvK51, prvK5N); obtenir (S33) une preuve de l’identité numérique (prv40 ; prv41, prv4N, prv50 ; prv51 ; prv5N ; prv60 ; prv61 ; prv62) par l’application d’une fonction de hachage à la clé publique de preuve (prvK40 ; prvK41, prvK4N, prvK50 ; prvK51, prvK5N) ; générer (S36) un certificat (C60, C61, C62) de l’identité numérique comprenant la preuve, et une clé publique applicative associée à l’identité numérique (appK40 ; appK41, appK4N, appK50 ; appK51, appK5N, appK60 ; appK61, appK62). Dispositif selon la revendication 1, dans lequel l’au moins une unité de calcul est configurée pour dériver (S34) la clé publique applicative à partir de la clé publique de preuve. Dispositif selon l’une des revendications 1 ou 2, dans lequel la clé publique de preuve est dérivée à partir d’une clé parente (par) et d’un indice (Ind) de l’identité numérique. Dispositif selon la revendication 3, dans laquelle la clé parente est la clé publique d’une paire de clés parentes (par), ladite au moins une unité de calcul étant configurée pour, préalablement à ladite dérivation de la clé de preuve, dériver (S31) de la paire de clés parentes à partir d’une graine aléatoire (grn) engravée dans une mémoire morte du dispositif. Dispositif selon l’une quelconque des revendications précédentes, dans laquelle ladite au moins une unité de calcul est configurée, à l’issue de l’obtention de la preuve et de la dérivation de la paire de clés applicatives, pour supprimer (S35) ladite clé publique de preuve. Dispositif selon l’une quelconque des revendications précédentes, dans lequel l’identité numérique est une identité numérique initiale (ID40, ID50, ID60) associée à un indice initial. Dispositif selon l’une quelconque des revendications 1 à 5, dans lequel : l’identité numérique est une identité numérique subséquente (ID41, ID4N, ID51, ID5N, ID61, ID62) ; le certificat est un certificat d’échange signé avec la clé privée de preuve associée à la clé publique de preuve de l’identité numérique d’indice immédiatement antérieur à l’indice subséquent, ledit certificat d’échange comprenant : un condensat (cnd60, cnd61) obtenu par l’application d’une fonction de hachage à un certificat de l’identité numérique de l’indice immédiatement antérieur; la clé privée de preuve associée à la clé publique de preuve de l’identité numérique de l’indice immédiatement antérieur. Dispositif selon l’une quelconque des revendications précédentes, dans lequel les clés publiques et les clés privées sont des clés étendues, et l’au moins une unité de calcul est configurée pour dériver les clés par une dérivation de clés étendue utilisant une fonction de hachage de type HMAC. Dispositif selon l’une quelconque des revendications précédentes, dans lequel l’au moins une unité de calcul est configurée pour obtenir au moins une des clés publiques à partir d’au moins une des clés privées et d’une courbe elliptique. Méthode (P3) mise en œuvre par au moins une unité de calcul de création d’une pluralité d’identités numériques (ID40 ; ID41 ; ID42 ; ID50 ; ID51 ; ID52 ; ID60 ; ID61 ; ID62) comprenant : la dérivation (S32) d’une clé publique de preuve de l’identité numérique (prvK40 ; prvK41, prvK4N, prvK50 ; prvK51, prvK5N); l’obtention (S33) d’une preuve de l’identité numérique (prv40 ; prv41, prv4N, prv50 ; prv51 ; prv5N ; prv60 ; prv61 ; prv62) par l’application d’une fonction de hachage à la clé publique de preuve (prvK40 ; prvK41, prvK4N, prvK50 ; prvK51, prvK5N) ; la génération (S36) d’un certificat (C60, C61, C62) de l’identité numérique comprenant la preuve, et une clé publique applicative associée à l’identité numérique (appK40 ; appK41, appK4N, appK50 ; appK51, appK5N, appK60 ; appK61, appK62). Méthode (P7) mise en œuvre par au moins une unité de calcul de vérification d’une identité numérique d’indice subséquent (ID61, ID62) comprenant : une réception (S70) d’un certificat (C60, C61) d’une identité numérique d’indice immédiatement antérieur à l’indice subséquent (ID60, ID61), ledit certificat de l’identité numérique d’indice immédiatement antérieur comprenant : une preuve de l’identité numérique d’indice immédiatement antérieur (prv60, prv61) ; une clé publique applicative associée à l’identité numérique d’indice immédiatement antérieur (appK60, appK61) ; une réception (S71) d’un certificat d’échange (C61, C62) signé associé à l’identité numérique d’indice subséquent, ledit certificat d’échange comprenant: un condensat (cnd60, cnd61) du certificat de l’identité numérique d’indice immédiatement antérieur ; une clé de preuve privée (prvK60, prvK61) de l’identité numérique d’indice immédiatement antérieur ; une preuve de l’identité numérique d’indice subséquent (prv61, prv62) ; une clé publique applicative associée à l’identité numérique d’indice subséquent (appK61, appK62) ; une vérification (S72) de la validité du certificat d’échange, ladite vérification de la validité du certificat d’échange comprenant : une vérification que le condensat du certificat de l’identité numérique d’indice immédiatement antérieur est identique à un condensat obtenu par l’application d’une fonction de hachage au certificat de l’identité numérique d’indice immédiatement antérieur; une vérification que la preuve de l’identité numérique d’indice immédiatement antérieur est identique à l’application d’une fonction de hachage à la clé de preuve publique de l’identité numérique d’indice immédiatement antérieur ; une vérification que la signature du certificat d’échange est une signature valide du certificat initial avec la clé privée de preuve d’indice immédiatement antérieur. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications 9 et 10 lorsque ce programme est exécuté par un processeur.