Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD FOR MANAGING A PUBLIC KEY DATABASE, METHOD FOR AUTHENTICATING PUBLIC KEYS, AND SERVER DEVICE AND CLIENT DEVICE IMPLEMENTING THESE METHODS
Document Type and Number:
WIPO Patent Application WO/2021/074527
Kind Code:
A1
Abstract:
This method (PGBD) for managing a public key database is implemented by a server device. The method comprises: - a step (E20) of obtaining an index key (CIX-CL1), said index key being obtained by at least implementing a cryptographic hash function that is applied at least to at least one public key; and - a step (E40) of recording said at least one public key in a record in said database that is indexed by said index key (CIX-CL1) if said index key is unique. The index key (CIX-CL1) may be distributed to a third party in order to allow same to obtain and authenticate the public key.

Inventors:
BASUYAUX JEAN-PHILIPPE (FR)
Application Number:
PCT/FR2020/051820
Publication Date:
April 22, 2021
Filing Date:
October 14, 2020
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
MY IDN (FR)
International Classes:
H04L9/08; H04L9/32
Foreign References:
US6466942B12002-10-15
US20190179806A12019-06-13
CN108898390A2018-11-27
GB2541975A2017-03-08
US20180109508A12018-04-19
US20190017806A12019-01-17
Attorney, Agent or Firm:
DELUMEAU, François et al. (FR)
Download PDF:
Claims:
REVENDICATIONS

[Revendication 1] Procédé (PGBD) de gestion d'une base de données (BD) de clés publiques, ce procédé étant mis en œuvre par un dispositif serveur (SRV), comportant :

- une étape (E10) d'obtention d'un trousseau de clés, ledit trousseau (TR2-CL1) comportant au moins une clé publique (KP-CL1) destinée à être authentifiée par un procédé d'authentification selon la revendication 4, chacune des dites clés publiques étant associée à une clé privée (KS-CL1);

- une étape (E20) d'obtention d'une clé d'indexation (CIX-CL1), ladite clé d'indexation étant obtenue en mettant au moins en œuvre une fonction de hachage cryptographique appliquée au moins à ladite au moins une clé publique (KP-CL1) ; une étape (E30) de vérification de l'unicité de ladite clé d'indexation (CIX-CL1) dans ladite base de données (BD); et

- soit une étape (E40) d'enregistrement dudit trousseau (TR2-CL1) dans un enregistrement (ENRG-CL1) de ladite base de données indexé par ladite clé d'indexation (CIX-CL1) en cas de succès de ladite étape (E30) de vérification d'unicité ;

- soit une étape (E50) de rejet dudit trousseau (TR2-CL1) en cas d'échec de ladite étape (E30) de vérification d'unicité.

[Revendication 2] Procédé de gestion selon la revendication 1 dans lequel ladite clé d'indexation (CIX-CL1) est reçue (E20) d'un dispositif client (CL1).

[Revendication 3] Procédé de gestion selon la revendication 1 dans lequel ladite clé d'indexation (CIX-CL1) est calculée (E20) par ledit dispositif serveur (SRV).

[Revendication 4] Procédé (PA) d'authentification d'au moins une clé publique (KP- CL1) comportant :

- une étape d'obtention (F10) d'un vérificateur (VF-CL1), ce vérificateur (VF-CL1) constituant une clé d'indexation (CIX-CL1) d'un enregistrement (ENRG-CL1) comportant un trousseau (TR2-CL1) de clés comportant ladite au moins une clé publique (KP-CL1) dans une base de données (BD) ;

- une étape (F20) d'obtention dudit trousseau (TR2-CL1) à partir de ladite clé d'indexation (CIX-CL1) ;

- une étape (F30) d'obtention d'une valeur cryptographique (HA), ladite valeur cryptographique (HA) étant obtenue en mettant au moins en œuvre une fonction de hachage cryptographique appliquée au moins à ladite au moins une clé publique (KP- CL1) ;

- une étape (F40) de comparaison de ladite valeur cryptographique (HA) et dudit vérificateur (VF-CL1);

- une étape (F50) d'authentification de ladite au moins une clé publique (KP-CL1) en fonction du résultat de ladite étape (F40) de comparaison.

[Revendication 5] Procédé sécurisé de transmission d'une donnée (DU, K) par un dispositif client émetteur (TX) à un dispositif client récepteur (RX), ledit procédé comportant :

- une étape (G20, G30) d'authentification d'une clé publique de chiffrement (KPa-RX) dudit dispositif client récepteur (RX) en mettant en œuvre un procédé d'authentification conforme à la revendication 4 ;

-une étape (G140, G260) de chiffrement de ladite donnée (K, DU) avec ladite clé publique de chiffrement (KPa-RX) ; et

- une étape (G150, G270, G390, G420) de mise à disposition de ladite donnée chiffrée (DU-ENC, K-ENC) audit dispositif client récepteur (RX).

[Revendication 6] Procédé sécurisé de transmission de donnée selon la revendication 5 dans lequel la donnée (K) est une clé secrète utilisée pour chiffrer (G250) une donnée utile (DU) à l'aide d'un algorithme de cryptographie symétrique, ledit procédé comportant :

- une étape (G240) d'obtention de ladite clé secrète (K) ; une étape (G250) de chiffrement de ladite donnée utile (DU) avec ladite clé secrète

(K) ;

- ladite donnée utile chiffrée (DU-ENC) étant mise à disposition dudit dispositif client récepteur (RX) (G270, G390) avec ladite clé secrète chiffrée (K-ENC), ladite clé secrète chiffrée (K-ENC) ayant été chiffrée avec ladite clé publique de chiffrement (KPa-RX).

[Revendication 7] Procédé sécurisé de transmission de donnée selon la revendication 6, ledit procédé comportant :

- une étape (G380) de signature de ladite donnée utile (DU) avec une clé secrète de signature (KSb-TX) dudit dispositif client émetteur (TX) ;

- la signature (HDU-SIG) de ladite donnée utile étant mise à disposition dudit dispositif client récepteur (RX) (G390) avec ladite clé secrète chiffrée (K-ENC) et avec ladite donnée utile chiffrée (DU-ENC).

[Revendication 8] Procédé sécurisé de transmission de donnée selon la revendication 5, dans lequel la donnée (DU) est une donnée utile, ledit procédé comportant :

- une étape (G380) de signature de ladite donnée utile (DU) avec une clé privée de signature (KSb-TX) dudit dispositif client émetteur (TX) ; la signature (HDU-SIG) de ladite donnée utile étant mise à disposition dudit dispositif client récepteur (RX) (G420) avec ladite donnée utile chiffrée (DU-ENC).

[Revendication 9] Procédé sécurisé de réception, par un dispositif client récepteur (RX) et en provenance d'un dispositif client émetteur (TX), d'une donnée utile (DU), le procédé comportant :

- une étape (H420, H320) de réception de ladite donnée utile chiffrée (DU-ENC) et d'une signature (HDU-SIG) de ladite donnée utile (DU), ladite signature (HDU-SIG) ayant été obtenue (G380) avec une clé privée de signature (KSb-TX) dudit dispositif client émetteur (TX) ;

- une étape d'authentification (H310) d'une clé publique (KPb-TX) de vérification de signature dudit dispositif client émetteur (TX) en mettant en œuvre un procédé d'authentification conforme à la revendication 4 ;

- une étape (H 160, H260, H270) d'obtention de ladite donnée utile (DU) à partir de ladite donnée utile chiffrée (DU-ENC) en utilisant la clé privée de déchiffrement (KSa- RX) dudit dispositif récepteur (RX) ;

- une étape (H380) de déchiffrement de ladite signature (HDU-SIG) avec ladite clé publique de vérification de signature (KPb-TX) dudit dispositif émetteur (TX) ;

- une étape (H390) de validation de ladite donnée utile (DU) à partir du résultat (HDU) de ladite étape (H380) de déchiffrement et d'un haché de ladite donnée utile (DU), celle-ci étant obtenue (H 160, H260, H270) à partir de ladite donnée utile chiffrée (DU-ENC).

[Revendication 10] Procédé sécurisé de réception d'une donnée utile (DU) selon la revendication 9, ledit procédé comportant en outre :

- une étape (H320) de réception d'une clé secrète chiffrée (K-ENC) avec une clé publique (KPa-RX) de chiffrement dudit dispositif client récepteur (RX) ;

- une étape (H260) d'obtention de ladite clé secrète (K) à partir de ladite clé secrète chiffrée (K-ENC) et de ladite clé privée de déchiffrement (KSa-RX) dudit dispositif client récepteur (RX) ; ladite donnée utile (DU) étant obtenue (H270) à partir de ladite donnée utile chiffrée (DU-ENC) et de ladite clé secrète (K).

[Revendication 11] Dispositif serveur (SRV) comportant :

- une unité (COM) d'obtention d'un trousseau de clés, ledit trousseau (TR2-CL1) comportant au moins une clé publique (KP-CL1) destinée à être authentifiée par un procédé d'authentification selon la revendication 4, chacune des dites clés publiques étant associée à une clé privée (KS-CL1);

- une unité (COM, CRY) d'obtention d'une clé d'indexation (CIX-CL1), ladite clé d'indexation étant obtenue en mettant au moins en œuvre une fonction de hachage cryptographique appliquée au moins à ladite au moins une clé publique (KP-CL1) ; une unité (CTR) de vérification de l'unicité de ladite clé d'indexation (CIX-CL1) dans une base de données (BD) de clés publiques ; et

- une unité (STR) d'enregistrement configurée pour enregistrer ledit trousseau (TR2- CL1) dans un enregistrement (ENRG-CL1) de ladite base de données indexé par ladite clé d'indexation (CIX-CL1) si ladite clé d'indexation (CIX-CL1) est unique ; une unité (CTR) configurée pour rejeter ledit trousseau (TR2-CL1) si ladite clé d'indexation (CIX-CL1) n'est pas unique.

[Revendication 12] Dispositif d'authentification (DPA) d'au moins une clé publique (KP-CL1), ce dispositif pouvant être mis en œuvre par un dispositif client (CL2) et comportant :

- une unité (IHM) d'obtention (F10) d'un vérificateur (VF-CL1), ce vérificateur (VF- CL1) constituant une clé d'indexation (CIX-CL1) d'un enregistrement (ENRG-CL1) comportant un trousseau (TR2-CL1) de clés comportant ladite au moins une clé publique (KP-CL1) dans une base de données (BD) ;

- une unité (COM) d'obtention dudit trousseau (TR2-CL1) à partir de ladite clé d'indexation (CIX-CL1) ;

- une unité (CRY) d'obtention d'une valeur cryptographique (HA), ladite valeur cryptographique (HA) étant obtenue en mettant au moins en œuvre une fonction de hachage cryptographique appliquée au moins à ladite au moins une clé publique (KP- CL1) ;

- une unité (CTR) de comparaison de ladite valeur cryptographique (HA) et dudit vérificateur (VF-CL1);

- une unité d'authentification (CTR) configurée pour authentifier ladite au moins une clé publique (KP-CL1) en fonction du résultat de ladite comparaison.

[Revendication 13] Dispositif client émetteur (TX) comportant un dispositif d'authentification selon la revendication 12, ledit dispositif étant configuré pour mettre en œuvre un procédé selon l'une quelconque des revendications 5 à 8 pour transmettre une donnée (DU, K) de façon sécurisée à un dispositif client récepteur (RX).

[Revendication 14] Dispositif client récepteur (RX), ledit dispositif étant configuré pour mettre en œuvre un procédé selon l'une quelconque des revendications 9 à 10 pour recevoir une donnée (DU, K) de façon sécurisée en provenance d'un dispositif client émetteur (RX).

[Revendication 15] Dispositif client récepteur (RX) selon la revendication 14 caractérisé en ce qu'il comporte en outre un dispositif d'authentification selon la revendication 12.

[Revendication 16] Programme d'ordinateur comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes d'un procédé (PGBD) de gestion d'une base de données (BD) de clés publiques selon l'une quelconque des revendications 1 à 3.

[Revendication 17] Programme d'ordinateur (PGPA) comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes d'un procédé selon la revendication 4.

[Revendication 18] Programme d'ordinateur (PGCL) comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes d'un procédé selon l'une quelconque des revendications 5 à 10.

[Revendication 19] Support de données lisible par ordinateur, sur lequel est enregistré un programme d'ordinateur selon l'une des revendications 16 à 18.

Description:
Description

Titre de l'invention : Procédé de gestion d'une base de données de clés publiques, procédé d'authentification de clés publiques, et dispositifs serveur et client mettant en œuvre ces procédés

Technique antérieure

L'invention se situe dans le domaine technologique de la cryptographie à clé publique ou cryptographie asymétrique.

On rappelle que l'utilisation de la cryptographie asymétrique pour transmettre et recevoir des données de façon sécurisée requiert pour les utilisateurs un moyen d'obtenir et d'authentifier les clés publiques de leurs correspondants.

L'invention cible plus particulièrement le problème de l'authentification des clés publiques.

L'authentification des clés publiques est en effet un problème incontournable lorsque l'on choisit la cryptographie asymétrique (ou hybride) pour transmettre des données en assurant leur confidentialité et leur authenticité. Celui qui transmet utilise la clé publique de chiffrement du destinataire pour chiffrer la donnée à transmettre. Celui qui reçoit utilise la clé publique de vérification de signature de l'émetteur pour vérifier la signature de la donnée.

Dans l'état actuel de la technique, le problème d'authentification des clés publiques est généralement solutionné en mettant en œuvre un certificat électronique. Un certificat est une donnée publique, contenant d'une part des informations d'identification d'une personne et d'autre part une clé publique. Sa validité peut être vérifiée, par quiconque l'ayant reçu par quelque canal que ce soit, auprès d'une autorité de certification.

Cette solution nécessite l'achat puis la gestion d'un certificat et de la clé privée associée. Elle est utilisée pour permettre à des utilisateurs d'authentifier un serveur web. On parle alors de certificat SSL, permettant d'établir un canal de communication sécurisé HTTPS, pour la navigation sur Internet.

Pour que cette solution soit pleinement satisfaisante, les utilisateurs devraient vérifier effectivement à qui est attribué le certificat à chaque fois qu'ils se connectent à un serveur en HTTPS, ce qu'ils ne font que très rarement. L'usage du protocole HTTPS sans vérifier le certificat signifie seulement qu'un attaquant aura beaucoup de mal à espionner le canal ou à modifier les transmissions dans le canal. Cela n'empêche aucunement d'établir directement le canal avec l'attaquant lui-même (selon le mécanisme frauduleux de « phishing »), car pour cela il suffit que l'attaquant ait lui aussi un certificat quelconque. Il existe en effet des autorités de complaisance qui délivrent des certificats authentiques à des sociétés dont le nom est usurpé.

Par ailleurs, la solution des certificats SSL n'est techniquement pas adaptée pour permettre à des utilisateurs finaux de s'authentifier entre eux, afin d'échanger des données entre eux. Cela nécessiterait que chaque utilisateur fasse l'acquisition d'un certificat et que le logiciel ou le service qu'ils utilisent pour correspondre intègre la possibilité qu'ils s'authentifient entre eux par ce moyen.

Plus généralement, les technologies PKI (Public Key Infrastructure) permettent de gérer et distribuer des certificats électroniques utilisables pour déployer des certificats SSL ou pour signer des documents, par exemple des e-mails, afin de garantir la confidentialité, l'authentification, l'intégrité et la non-répudiation lors de transactions électroniques. Différents modèles de PKI existent, mais tous reposent sur les certificats numériques et sur le principe d'une chaîne de confiance. Chaque clé publique est signée par un tiers dont la clé publique est elle-même signée par un autre tiers.

Authentifier la clé publique d'un correspondant requiert de faire confiance à chacun des tiers de la chaîne de confiance, non pas uniquement à l'autorité au sommet de la chaîne. Au coût d'acquisition de telles solutions s'ajoute donc un problème de confiance inhérent à leur architecture. On notera que dans l'état actuel de la technique, il est admis ( https://fr.wikipedia.org/wiki/Non-r%C3%A9pudiationj que la non-répudiation ne peut être atteinte qu'en utilisant la technologie du certificat numérique.

En particulier, le document US 2019/17806 Al divulgue une base de données décentralisée pour le stockage de clés publiques. Pour vérifier qu'une clé publique appartient effectivement à un utilisateur avant de l'enregistrer dans la base de données, ce document enseigne d'envoyer un message secret à l'utilisateur pour que celui-ci signe ce message avec sa clé privée. Des dispositifs de validation sont utilisés pour valider la clé publique si celle-ci permet de déchiffrer le message signé avec la clé privée de l'utilisateur.

Cette solution n'est pas satisfaisante car elle ne résisterait pas à l'injection, par un pirate, dans la base de données, d'une clé piratée réputée avoir été authentifiée.

Ces solutions ne sont donc pas satisfaisantes.

L'invention vise par conséquent une nouvelle méthode d'authentification de clé publique qui ne présente pas les inconvénients des méthodes connues.

Exposé de l'invention

Plus précisément, et selon un premier aspect, l'invention concerne un procédé de gestion d'une base de données de clés publiques. Ce procédé peut être mis en œuvre par un dispositif serveur. Il comporte :

- une étape d'obtention d'un trousseau de clés, ce trousseau comportant au moins une clé publique destinée à être authentifiée par un procédé d'authentification conforme à l'invention, chacune de ces clés publiques étant associée à une clé privée;

- une étape d'obtention d'une clé d'indexation, cette clé d'indexation étant obtenue en mettant au moins en œuvre une fonction de hachage cryptographique appliquée au moins à ladite au moins une clé publique ;

- une étape de vérification de l'unicité de la clé d'indexation dans la base de données; et

- soit une étape d'enregistrement du trousseau dans un enregistrement de la base de données indexé par ladite clé d'indexation en cas de succès de l'étape de vérification d'unicité ;

- soit une étape de rejet du trousseau en cas d'échec de l'étape de vérification d'unicité.

Corrélativement, l'invention concerne un dispositif serveur comportant :

- une unité d'obtention d'un trousseau de clés, ce trousseau comportant au moins une clé publique destinée à être authentifiée par un procédé d'authentification selon l'invention, chacune des dites clés publiques étant associée à une clé privée ; - une unité d'obtention d'une clé d'indexation, cette clé d'indexation étant obtenue en mettant au moins en œuvre une fonction de hachage cryptographique appliquée au moins à ladite au moins une clé publique ;

- une unité de vérification de l'unicité de la clé d'indexation dans une base de données de clés publiques ; et

- une unité d'enregistrement configurée pour enregistrer le trousseau dans un enregistrement de la base de données indexé par la clé d'indexation si la clé d'indexation est unique ;

- une unité configurée pour rejeter ledit trousseau si la clé d'indexation n'est pas unique.

Selon un deuxième aspect, l'invention vise aussi un procédé d'authentification d'au moins une clé publique. Ce procédé comporte :

- une étape d'obtention d'un vérificateur, ce vérificateur constituant une clé d'indexation d'un enregistrement comportant un trousseau de clés comportant ladite au moins une clé publique dans une base de données ;

- une étape d'obtention du trousseau à partir de la clé d'indexation ;

- une étape d'obtention d'une valeur cryptographique, cette valeur cryptographique étant obtenue en mettant au moins en œuvre une fonction de hachage cryptographique appliquée au moins à ladite au moins une clé publique ;

- une étape de comparaison de la valeur cryptographique et du vérificateur;

- une étape d'authentification de ladite au moins une clé publique en fonction du résultat de cette étape de comparaison.

Corrélativement, l'invention vise un dispositif d'authentification d'au moins une clé publique. Ce dispositif peut être mis en œuvre par un dispositif client. Il comporte :

- une unité d'obtention d'un vérificateur, ce vérificateur constituant une clé d'indexation d'un enregistrement comportant un trousseau de clés comportant ladite au moins une clé publique dans une base de données ;

- une unité d'obtention de ce trousseau à partir de la clé d'indexation ;

- une unité d'obtention d'une valeur cryptographique, cette valeur cryptographique étant obtenue en mettant au moins en œuvre une fonction de hachage cryptographique appliquée au moins à ladite au moins une clé publique ;

- une unité de comparaison de la valeur cryptographique et du vérificateur ;

- une unité d'authentification configurée pour authentifier ladite au moins une clé publique en fonction du résultat de la comparaison.

Dans un mode préféré de réalisation, le dispositif client calcule lui-même la clé d'indexation et le dispositif serveur reçoit la clé d'indexation du dispositif client.

En variante, la clé d'indexation est calculée par le dispositif serveur.

De façon très avantageuse, l'invention ne nécessite pas d'utiliser un certificat numérique comportant la clé publique.

Par conséquent, le procédé d'authentification selon l'invention ne nécessite pas l'intervention d'un tiers de confiance. Le procédé d'authentification selon l'invention peut être mis en œuvre par un dispositif client seul, à l'aide du seul vérificateur. Le problème de confiance est ainsi éliminé

En effet, le fait d'associer les clés publiques au vérificateur (faisant ainsi également fonction de clé d'indexation) dans la base de données gérée par l'invention permet de distribuer les clés publiques. Les utilisateurs de la solution ont seulement besoin connaître les vérificateurs de leurs correspondants pour obtenir les clés publiques de ceux-ci auprès d'un serveur et pouvoir aussitôt, et de façon autonome, authentifier ces clés publiques.

Contrairement à la solution du document US 2019/17806 Al présentée précédemment, conformément à l'invention l'authentification de la clé publique est réalisée par le dispositif de l'utilisateur qui souhaite authentifier la clé publique d'un autre utilisateur. Le mécanisme proposé par l'invention est résistant à l'injection de données par un pirate qui distribuerait sa propre publique à la place de celle d'un utilisateur légitime.

Il peut donc être considéré que l'invention vise à offrir un nouveau modèle de PKI (Public Key Infrastructure). L'utilisation d'une fonction de hachage cryptographique pour l'obtention du vérificateur empêche un attaquant de forger une autre clé publique qui réussirait l'étape d'authentification.

De façon très avantageuse, le vérificateur ainsi obtenu par hachage sert également de clé d'indexation. De façon très avantageuse, le fait de s'assurer de l'unicité de la clé d'indexation permet d'obtenir la clé publique à partir de la clé d'indexation en une seule opération.

Les clés publiques enregistrées dans la base de données peuvent être de différentes natures. Il peut en particulier s'agir :

- de clés publiques de chiffrement de données ; - de clés publiques de vérification de signature.

L'invention peut être utilisée par deux dispositifs clients pour s'échanger des données de façon sécurisée.

Ainsi, l'invention concerne un procédé sécurisé de transmission d'une donnée par un dispositif client émetteur à un dispositif client récepteur. Ce procédé comporte : - une étape d'authentification d'une clé publique de chiffrement du dispositif client récepteur en mettant en œuvre un procédé d'authentification conforme à l'invention ;

- une étape de chiffrement de la donnée avec cette clé publique de chiffrement ; et - une étape de mise à disposition de la donnée chiffrée au dispositif client récepteur.

Dans un mode particulier de réalisation, ce procédé peut être utilisé pour transmettre de façon sécurisé une clé secrète au dispositif récepteur, cette clé secrète étant destinée à être utilisée pour chiffrer à l'aide d'un algorithme de cryptographie symétrique une donnée utile que le dispositif client émetteur souhaite communiquer au dispositif client récepteur. Ce procédé comporte :

- une étape d'obtention de ladite clé secrète, par exemple de façon aléatoire ;

- une étape de chiffrement de la donnée utile avec la clé secrète ; - la donnée utile chiffrée étant mise à disposition dudit dispositif client récepteur avec la clé secrète chiffrée, cette clé secrète chiffrée ayant été chiffrée avec la clé publique de chiffrement.

Dans un mode particulier de réalisation, ce procédé de cryptographie hybride comporte en outre :

- une étape de signature de la donnée utile avec une clé privée de signature dudit dispositif client émetteur ;

- la signature de la donnée utile étant mise à disposition dudit dispositif client récepteur avec la clé secrète chiffrée et avec la donnée utile chiffrée.

Ce mode de réalisation permet au dispositif client récepteur d'authentifier le dispositif client émetteur.

L'invention peut aussi être utilisée dans le contexte d'un procédé de cryptographie asymétrique.

En effet, dans un mode particulier de réalisation du procédé sécurisé de transmission selon l'invention, la donnée transmise de façon sécurisée au dispositif client émetteur est une donnée utile. Ce procédé comporte :

- une étape de signature de la donnée utile avec une clé privée de signature du dispositif client émetteur ;

- la signature de la donnée utile étant mise à disposition dudit dispositif client récepteur avec la donnée utile chiffrée.

L'invention vise aussi un procédé sécurisé de réception, par un dispositif client récepteur et en provenance d'un dispositif client transmetteur, d'une donnée utile, ce procédé comportant :

- une étape de réception de la donnée utile chiffrée et d'une signature de la donnée utile, la signature ayant été obtenue avec une clé privée de signature du dispositif client émetteur ;

- une étape d'authentification d'une clé publique de vérification de signature du dispositif client émetteur en mettant en œuvre un procédé d'authentification conforme à l'invention ;

- une étape d'obtention de ladite donnée utile à partir de la donnée utile chiffrée en utilisant une clé privée de déchiffrement du dispositif récepteur ;

- une étape de déchiffrement de la signature avec la clé publique de vérification de signature du dispositif émetteur ;

- une étape de validation de la donnée utile à partir du résultat de l'étape de déchiffrement de la signature et à partir de la donnée utile obtenue à partir de la donnée utile chiffrée.

Dans un mode particulier de réalisation dans lequel l'invention est mise en œuvre dans un contexte de cryptographie hybride, ce procédé sécurisé de réception comporte en outre :

- une étape de réception d'une clé secrète chiffrée avec une clé publique de chiffrement du dispositif client récepteur ;

- une étape d'obtention de la clé secrète à partir de la clé secrète chiffrée et de la clé privée de déchiffrement du dispositif client récepteur ;

- la donnée utile étant obtenue à partir de la donnée utile chiffrée et de la clé secrète. Dans un autre mode de réalisation dans lequel l'invention est mise en œuvre dans un contexte de cryptographie asymétrique, la donnée utile est obtenue en déchiffrant la donnée utile chiffrée avec la clé privée de déchiffrement du dispositif récepteur.

Dans un mode particulier de réalisation, les différentes étapes des procédés selon l'invention (procédé de gestion de base de données, procédé d'authentification de clé publique, procédé sécurisé de transmission de données, procédé sécurisé de réception de données) 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 comportant des instructions adaptées à la mise en œuvre d'au moins un procédé tel que mentionné ci-dessus.

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.

L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.

Le support d'informations peut être n'importe quelle entité ou système 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 un disque dur.

D'autre part, le support d'informations 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 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.

Brève description des dessins

D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :

[Fig. 1] la figure 1 représente un dispositif serveur et des dispositifs clients conformes à des modes particuliers de réalisation de l'invention dans leur environnement ;

[Fig. 2] la figure 2 représente un exemple de trousseau de clés publiques pouvant être utilisé dans l'invention ;

[Fig. 3] la figure 3 représente sous forme d'organigramme les principales étapes d'un procédé de gestion d'une base de données de clés publiques conforme à un mode de réalisation de l'invention ;

[Fig. 4] la figure 4 représente un exemple d'enregistrement de base de données pouvant être utilisé dans l'invention ;

[Fig. 5] la figure 5 représente sous forme d'organigramme les principales étapes d'un procédé d'authentification de clé publique conforme à un mode de réalisation de l'invention ; [Fig. 6] la figure 6 représente un exemple de mise en œuvre de l'invention par des dispositifs clients pour s'échanger des données de façon sécurisée ;

[Fig. 7] la figure 7 représente un exemple de mise en œuvre de l'invention par des dispositifs clients pour s'échanger des données de façon sécurisée ;

[Fig. 8] la figure 8 représente un exemple de mise en œuvre de l'invention par des dispositifs clients pour s'échanger des données de façon sécurisée ;

[Fig. 9] la figure 9 représente un exemple de mise en œuvre de l'invention par des dispositifs clients pour s'échanger des données de façon sécurisée ;

[Fig. 10] la figure 10 représente schématiquement un dispositif serveur conforme à un mode de réalisation de l'invention ;

[Fig. 11] la figure 11 représente schématiquement un dispositif d'authentification conforme à un mode de réalisation de l'invention ;

[Fig. 12] la figure 12 représente schématiquement un dispositif client conforme à un mode de réalisation de l'invention, représente

Description des modes de réalisation

La figure 1 représente un réseau R auquel sont connectés un dispositif serveur SRV conforme à l'invention et quatre dispositifs clients conformes à l'invention, à savoir :

- le dispositif client CL1 d'un utilisateur U1 ;

- le dispositif client CL2 d'un utilisateur U2 ;

- le dispositif client TX d'un utilisateur UT ;

- le dispositif client RX d'un utilisateur UR.

Le dispositif serveur SRV est associé à une base de données BD. Il comporte l'architecture matérielle d'un ordinateur. Il comporte notamment un module 13 de communication sur le réseau R, un processeur 10 et une mémoire 11 dans laquelle est stocké un programme d'ordinateur PG conforme à l'invention. Ce programme PG comporte des instructions qui lorsqu'elles sont exécutées par le processeur 10 mettent en œuvre un procédé PGBD de gestion d'une base de données conforme à l'invention et dont les principales étapes seront décrites en référence à la figure 3.

Dans l'exemple de réalisation décrit ici, les dispositifs clients CL1, CL2, TX et RX ont l'architecture matérielle d'un ordinateur. Seul le dispositif CL1 est représenté en détails sur la figure 1.

Chacun de ces dispositifs client comporte notamment un module de communication 23 sur le réseau R, un processeur 20 et une mémoire 21 dans laquelle est stocké un programme d'ordinateur PCL conforme à l'invention.

Dans l'exemple décrit ici, Le programme PCL comporte des instructions qui lorsqu'elles sont exécutées par le processeur 20 peuvent mettent en œuvre :

- un procédé PA d'authentification conforme à l'invention et dont les principales étapes seront décrites en référence à la figure 5 ; - un procédé PTX pour envoyer une donnée conformément à l'invention tel que décrit en référence à l'une des figures 6, 7, 8 ou 9 ; et

- un procédé PRX pour recevoir une donnée conformément à l'invention tel que décrit en référence à l'une des figures 6, 7, 8 ou 9.

Dans l'exemple décrit ici, le dispositif client CL1 comporte une mémoire 22 dans lequel il mémorise une paire de clé comportant une clé publique KP-CL1 associée à une clé privée KS-CL1. On suppose que l'utilisateur U1 souhaite que sa clé publique KP-CL1 puisse être authentifiée par un tiers en utilisant un procédé d'authentification conforme à l'invention.

Dans l'exemple de réalisation décrit ici, le dispositif client CL1 mémorise aussi dans sa mémoire 22 un trousseau de clés TR2-CL1 représenté à la figure 2.

Dans le mode de réalisation décrit ici, ce trousseau TR2-CL1 comporte toutes les clés publiques de l'utilisateur U1 qui sont destinées à pouvoir être authentifiées par un tiers.

Dans l'exemple décrit ici, ce trousseau TR2-CL1 comporte aussi des données DUM non concernées par l'invention.

Dans l'exemple de la figure 1 :

- le dispositif client CL2 de l'utilisateur U2 ne mémorise pas de clé ;

- le dispositif client TX de l'utilisateur UT mémorise une paire de clé {KPa-TX, KSa-TX} comportant une clé publique KPa-TX de chiffrement et la clé privée KSa-TX de déchiffrement associée, une paire de clé {KPb-TX, KSb-TX} comportant une clé privée de signature KSb-TX et la clé publique KPb-TX de vérification de signature associée et un trousseau de clés TR2- TX comportant les clés publiques KPa-TX et KPb-TX ; et

- le dispositif client RX de l'utilisateur RX mémorise une paire de clé {KPa-RX, KSa-RX} comportant une clé publique KPa-RX de chiffrement et la clé privée KSa-RX de déchiffrement associée, une paire de clé {KPb-RX, KSb-RX} comportant une clé privée de signature KSb-RX et la clé publique KPb-RX de vérification de signature associée et un trousseau de clés TR2- RX comportant les clés publiques KPa-RX et KPb-RX.

Dans le mode de réalisation décrit ici, les clés publiques sont associées aux clés privées comme de façon connue dans les systèmes cryptographiques asymétriques. Dans l'exemple de réalisation décrit ici, elles sont conformes à un algorithme de type RSA (Rivest Shamir Adleman).

Les clés privées sont destinées à rester secrètes ; elles ne sont pas communiquées au dispositif serveur SRV.

Dans le mode de réalisation décrit ici, les paires de clés sont mémorisées par les dispositifs clients eux-mêmes mais d'autres solutions peuvent envisagées.

La figure 3 représente sous forme d'organigramme les principales étapes d'un procédé PGBD de gestion d'une base de données de clés publiques conforme à un mode particulier de réalisation de l'invention.

Dans le mode de réalisation décrit ici, ce procédé est mis en œuvre par le dispositif serveur SRV de la figure 1 pour gérer la base de données BD.

On décrit plus précisément la mise en œuvre du procédé par le dispositif serveur SRV lorsqu'il reçoit, au cours d'une étape E10, à l'initiative de l'utilisateur Ul, le trousseau de clés TR2-CL1 du dispositif client CL1 de la figure 1.

Au cours d'une étape E20, le dispositif serveur SRV obtient une clé d'indexation CIX-CL1. Dans le mode de réalisation décrit ici, le dispositif serveur SRV reçoit cette clé d'indexation CIX-CL1 du dispositif client CL1. En variante, le dispositif serveur SRV peut calculer cette clé d'indexation lui-même au cours de l'étape E20.

Conformément à l'invention, la clé d'indexation CIX-CL1 est calculée (par exemple par le dispositif serveur SRV ou par le dispositif client CL1) en appliquant une fonction de hachage cryptographique au moins à l'ensemble des clés publiques (ici KP-CL1) destinées à être authentifiées par un procédé d'authentification conforme à l'invention, et éventuellement d'autres fonctions.

Dans un mode de réalisation de l'invention, la clé d'indexation CIX-CL1 est obtenue par le dispositif client CL1 par une fonction F :

- en appliquant la fonction de hachage SHA-256 à une donnée binaire obtenue par concaténation des clés publiques du trousseau TR2-CL1 ; et

- en tronquant le résultat de cette fonction de hachage à 80 bits.

Cette taille de 80 bits est définie en fonction d'un niveau de sécurité souhaité pour le vérificateur. D'autres tailles de clés d'indexation peuvent être utilisées.

Lorsque le niveau de sécurité est de 80 bits et lorsqu'on utilise l'algorithme RSA, on peut utiliser des clés publique/privée comportant un modulus de 1024 bits et un exposant privé de 1024 bits.

Au cours d'une étape E30, le procédé de gestion selon l'invention vérifie l'unicité de la clé d'indexation CIX-CL1 dans la base de données BD, autrement dit il vérifie que la clé d'indexation CIX-CL1 ne constitue pas déjà la clé d'indexation d'un enregistrement de la base de données BD.

Si la clé d'indexation CIX-CL1 est unique le résultat de l'étape E30 est positif et le procédé comporte une étape E40 d'enregistrement du trousseau TR2-CL1 dans un enregistrement ENRG-CL1 de la base de données BD, cet enregistrement représenté à la figure 4 étant indexé par la clé d'indexation CIX-CL1. Autrement dit, dans l'invention, chaque enregistrement de la base de données BD est indexé uniquement par une clé obtenue en appliquant une fonction de hachage aux valeurs de cet enregistrement.

Dans le mode de réalisation décrit ici, le nom (ou identifiant) U1 de l'utilisateur du dispositif client CL1 est enregistré dans l'enregistrement ENRG-CL1.

Conformément à l'invention, la clé d'indexation CIX-CL1 sert de vérificateur VF-CL1 pour permettre l'authentification des clés publiques du trousseau TR2-CL1.

Dans la suite de la description, lorsque cette même valeur est utilisée comme clé d'indexation dans la base de données BD, on l'appellera « clé d'indexation CIX-CL1 » et lorsqu'elle est utilisée comme vérificateur on l'appellera « vérificateur VF-CL1 ».

Le vérificateur VF-CL1 est destiné à être communiqué par l'utilisateur U1 à des tiers. Il peut par exemple être imprimé sur les cartes de visite de l'utilisateur Ul.

De retour à l'étape E30, si la clé d'indexation CIX-CL1 obtenue à l'étape E20 sert déjà de clé d'indexation dans la base de données BD (échec du test d'unicité), le résultat de l'étape E30 est négatif et le procédé comporte une étape E50 de rejet du trousseau TR2-CL1.

La figure 5 représente sous forme d'organigramme les principales étapes d'un procédé PA d'authentification d'une ou plusieurs clés publiques conforme à un mode particulier de réalisation de l'invention.

Dans le mode de réalisation décrit ici, ce procédé est mis en œuvre par le dispositif client CL2 de la figure 1. On décrit plus précisément la mise en œuvre du procédé d'authentification par le dispositif client CL2 pour authentifier la clé publique KP-CL1 du dispositif client CL1.

On suppose que le dispositif client CL2 reçoit, au cours d'une étape F10, le vérificateur VF- CL1 de l'utilisateur Ul.

Conformément à l'invention, ce vérificateur VF-CL1 constitue une clé d'indexation CIX-CL1 d'un enregistrement ENRG-CL1 dans la base de données BD, cet enregistrement comportant un trousseau TR2-CL1 comportant la clé publique KP-CL1.

Au cours d'une étape F20, le dispositif client CL2 obtient le trousseau TR2-CL1 à partir de la clé d'indexation CIX-CL1 en interrogeant le dispositif serveur SRV.

Dans un mode particulier de réalisation, le dispositif client CL2 reçoit en outre le nom Ul de l'utilisateur associé à la clé d'indexation CIX-CL1 dans la base de données BD. L'utilisateur U2 peut ainsi s'assurer qu'il a bien saisi le bon vérificateur.

Au cours d'une étape F30, le dispositif client CL2 calcule une valeur cryptographique HA en appliquant une fonction cryptographique F identique à celle utilisée à l'étape E20 du procédé de gestion de base de données décrit en référence à la figure 3 aux clés publiques du trousseau TR2-CL1, à savoir ici à KP-CL1.

Au cours d'une étape F40, le dispositif client CL2 compare la valeur cryptographique HA obtenue à l'étape F30 et le vérificateur VF-CL1 obtenu à l'étape F10.

La clé publique KP-CL1 est authentifiée au cours d'une étape F50 si et seulement si le vérificateur VF-CL1 et la valeur cryptographique HA sont égaux. Sinon la clé publique KP-CL1 est considérée comme non valide au cours d'une étape F60.

Nous décrivons en référence à la figure 6 un premier exemple d'utilisation de l'invention dans lequel l'utilisateur UT du dispositif client TX de la figure 1 souhaite envoyer une donnée utile DU à l'utilisateur UR du dispositif client RX de la figure 1.

Dans ce mode de réalisation le dispositif client TX met en œuvre un procédé PTX et le dispositif client RX met en œuvre un procédé PRX.

On suppose dans cet exemple que le dispositif TX a déjà demandé au dispositif serveur SRV, au cours d'une étape G10, l'enregistrement d'un trousseau TR2-TX dans la base de données BD, ce trousseau TR2-TX comportant une clé publique de chiffrement KPa-TX et une clé publique de vérification de signature KPb-TX. On suppose que ce trousseau TR2-TX est enregistré dans un enregistrement ENRG-TX de la base de données BD, cet enregistrement étant indexé par une clé d'indexation CIX-TX. Dans le mode de réalisation décrit, cet enregistrement ENRG-TX comporte en outre le nom de l'utilisateur UT du dispositif TX.

La clé d'indexation CIX-TX constitue un vérificateur VF-TX que l'utilisateur UT peut communiquer aux tiers.

Plus précisément, dans l'exemple décrit ici, le dispositif serveur SRV a, en réponse à la demande du dispositif TX, mis en œuvre le procédé de gestion de base de données PGBD décrit précédemment en référence à la figure 3 et enregistré le trousseau TR2-TX dans l'enregistrement ENRG-TX indexé par la clé d'indexation CIX-TX, après avoir vérifié l'unicité de cette clé.

On suppose aussi que le dispositif RX a déjà demandé au dispositif serveur SRV, au cours d'une étape H 10, l'enregistrement d'un trousseau TR2-RX dans la base de données BD, ce trousseau TR2-RX comportant une clé publique de chiffrement KPa-RX et une clé publique de vérification de signature KPb-RX.

De la même façon, on suppose que le dispositif serveur SRV a, en réponse à cette demande, mis en œuvre le procédé de gestion de base de données PGBD décrit précédemment en il référence à la figure 3 et enregistré le trousseau TR2-RX dans un enregistrement ENRG-RX de la base de données BD, cet enregistrement étant indexé par une clé d'indexation CIX-RX, après avoir vérifié l'unicité de cette clé. Dans le mode de réalisation décrit, cet enregistrement ENRG-RX comporte aussi le nom de l'utilisateur UR du dispositif RX. La clé d'indexation CIX-RX constitue un vérificateur VF-RX que l'utilisateur UR peut communiquer aux tiers.

On suppose que l'utilisateur UT a obtenu le vérificateur VF-RX de l'utilisateur UR au cours d'une étape G20.

Au cours d'une étape G30, le dispositif client TX authentifie la clé publique de chiffrement KPa-RX du dispositif client RX en mettant en œuvre le procédé PA d'authentification de clé publique décrit précédemment en référence à la figure 5. En résumé, cette étape G30 consiste à obtenir le trousseau TR2-RX à partir du vérificateur VF-RX, à calculer une valeur cryptographique HA à partir des clés publiques comprises dans ce trousseau et à vérifier que cette valeur cryptographique HA est égale au vérificateur VF-RX. Au cours d'une étape G140, le dispositif client TX chiffre la donnée utile DU avec la clé publique de chiffrement KPa-RX du dispositif client RX. La donnée utile chiffrée, résultat de ce chiffrement, est notée DU-ENC.

Au cours d'une étape G150, le dispositif client TX envoie la donnée utile chiffrée DU-ENC au dispositif client RX. Dans cet exemple, le dispositif client RX reçoit la donnée utile chiffrée DU-ENC au cours d'une étape H 150 et la déchiffre avec sa clé privée de déchiffrement KSa-RX au cours d'une étape H 160 pour obtenir la donnée utile en clair DU.

Nous décrivons en référence à la figure 7 un deuxième exemple d'utilisation de l'invention dans lequel l'utilisateur UT du dispositif client TX de la figure 1 souhaite envoyer une donnée utile DU à l'utilisateur UR du dispositif client RX de la figure 1.

Cet exemple utilise un mécanisme de cryptographie hybride.

Les étapes G10 à G30 et H 10 de ce deuxième exemple sont identiques aux étapes correspondantes du premier exemple de la figure 6. Dans cet exemple de réalisation, le dispositif client TX génère une clé aléatoire secrète K au cours d'une étape G240 postérieure à l'étape G30 et chiffre, au cours d'une étape G250 la donnée utile DU avec la clé aléatoire K selon un algorithme de cryptographie symétrique. La donnée utile chiffrée, résultat de ce chiffrement, est notée DU-ENC.

Au cours d'une étape G260, le dispositif client TX chiffre la clé aléatoire secrète K avec la clé publique de chiffrement KPa-RX du dispositif client RX. La clé aléatoire secrète chiffrée, résultat de ce chiffrement, est notée K-ENC.

Au cours d'une étape G270, le dispositif client TX envoie la donnée utile chiffrée DU-ENC et la clé aléatoire secrète chiffrée K-ENC au dispositif client RX.

Dans cet exemple, le dispositif client RX reçoit la donnée utile chiffrée DU-ENC et la clé secrète chiffrée K-ENC au cours d'une étape H250.

Au cours d'une étape H260, le dispositif client RX déchiffre la clé secrète chiffrée K-ENC avec sa clé privée de déchiffrement KSa-RX pour obtenir la clé secrète en clair K.

Au cours d'une étape H270, le dispositif client RX déchiffre la donnée utile chiffrée DU-ENC avec la clé secrète K en appliquant l'algorithme de cryptographie symétrique précité pour obtenir la donnée utile en clair DU. Nous décrivons en référence à la figure 8 un troisième exemple d'utilisation de l'invention dans lequel l'utilisateur UT du dispositif client TX de la figure 1 souhaite envoyer une donnée utile DU à l'utilisateur UR du dispositif client RX de la figure 1.

Cet exemple ajoute un mécanisme de signature.

Les étapes G10 à G260, H 10, H260 et H270 de ce troisième exemple sont identiques aux étapes correspondantes du deuxième exemple de la figure 7.

On suppose que l'utilisateur UR a obtenu le vérificateur VF-TX de l'utilisateur UT au cours d'une étape H300.

Au cours d'une étape H310, le dispositif client RX authentifie la clé publique de vérification de signature KPb-TX du dispositif client TX en mettant en œuvre le procédé PA d'authentification de clé publique décrit précédemment en référence à la figure 5. En résumé, cette étape H310 consiste à obtenir le trousseau TR2-TX à partir du vérificateur VF- TX, calculer une valeur cryptographique HA à partir des clés publiques comprises dans ce trousseau et vérifier que cette valeur cryptographique HA est égale au vérificateur VF-TX.

Dans cet exemple, au cours d'une étape G370 consécutive à l'étape G260, le dispositif client TX calcule un haché HDU de la donnée utile DU et chiffre (étape G380) ce haché HDU avec sa clé privée de signature KSb-TX. Le haché chiffré de la donnée utile DU constitue une signature de la donnée utile DU, il est noté HDU-SIG.

Au cours d'une étape G390, le dispositif client TX envoie la donnée utile chiffrée DU-ENC, la clé aléatoire secrète chiffrée K-ENC et le haché chiffré HDU-SIG de la donnée utile DU au dispositif client RX.

Dans cet exemple, le dispositif client RX reçoit la donnée utile chiffrée DU-ENC, la clé secrète chiffrée K-ENC et le haché chiffré HDU-SIG de la donnée utile au cours d'une étape H320.

Cette étape H320 est suivie par les étapes H260 et H270 déjà décrites qui permettent au dispositif client RX d'obtenir la donnée utile DU.

Dans cet exemple, le dispositif client RX déchiffre, au cours d'une étape H380, le haché chiffré HDU-SIG de la donnée utile à l'aide de la clé publique de vérification de signature KPb-TX du dispositif client TX pour obtenir le haché HDU de la donnée utile DU en clair.

Au cours d'une étape H390, le dispositif client RX calcule le haché de la donnée utile DU obtenue à l'étape H270 et vérifie que ce haché est identique au haché HDU obtenu à l'étape H 380.

Si c'est le cas, l'étape H390 est suivie par une étape H392 au cours de laquelle le dispositif client RX accepte la donnée utile DU. Dans le cas contraire il la rejette au cours d'une étape H394.

Nous décrivons en référence à la figure 9 un quatrième exemple d'utilisation de l'invention dans lequel l'utilisateur UT du dispositif client TX de la figure 1 souhaite envoyer une donnée utile DU à l'utilisateur UR du dispositif client RX de la figure 1.

Cet exemple reprend celui de la figure 6 en ajoutant, comme dans celui de figure 9 un mécanisme de signature.

Les étapes G10 à G140 et H10 sont identiques aux étapes correspondantes du premier exemple de la figure 6.

Les étapes G380, H300 et H310 sont identiques aux étapes correspondantes du troisième exemple de la figure 8. Dans ce procédé, le dispositif client TX envoie (étape G420) la donnée utile chiffrée DU-ENC et le haché chiffré HDU-SIG de la donnée utile au dispositif client RX. Celui-ci reçoit ces données au cours d'une étape H420.

Le dispositif client RX déchiffre la donnée utile chiffrée DU-ENC avec sa clé privée de déchiffrement KSa-RX au cours d'une étape H 160 pour obtenir la donnée utile en clair DU, comme décrit précédemment en référence à la figure 6.

Puis, comme décrit en référence à la figure 8 :

- le dispositif client RX déchiffre le haché chiffré HDU-SIG de la donnée utile pour obtenir le haché HDU de la donnée utile DU en clair (étape H380) ;

- calcule le haché de la donnée utile DU obtenue à l'étape H 160 et vérifie (étape H390) que ce haché est identique au haché HDU obtenu à l'étape H380.

Si c'est le cas, l'étape H390 est suivie par une étape H392 au cours de laquelle le dispositif client RX accepte la donnée utile DU. Dans le cas contraire il la rejette au cours d'une étape H394.

Dans les modes de réalisation de l'invention décrits précédemment, le dispositif client émetteur TX envoie directement les données au dispositif client récepteur RX. Il s'agit notamment :

- de la donnée utile chiffrée DU-ENC envoyée à l'étape G150, G270, G390 ou G420 ;

- de la clé secrète chiffrée K-ENC envoyée à l'étape G270 ou G390 ;

- de la signature de la donnée utile HDU-SIG envoyée à l'étape G390 ou G420.

En variante, le dispositif client émetteur TX envoie ces données au dispositif serveur SRV. Celui-ci notifie le dispositif client récepteur RX pour qu'il puisse les obtenir à partir du serveur SRV.

La figure 10 représente une vue fonctionnelle du dispositif serveur de la figure 1. Il comporte

- une unité COM d'obtention d'un trousseau de clés. Dans l'exemple de la figure 1 cette unité est constituée par le module de communication 13 ;

- une unité COM d'obtention d'une clé d'indexation. Cette unité peut être constituée par le module de communication 13 lorsque le serveur reçoit la clé d'indexation via le réseau R ou par un module cryptographique non représenté lorsque le serveur SRV calcule lui-même cette clé CIX-CL1 en mettant en œuvre notamment la fonction de hachage cryptographique appliquée au moins aux clés publiques dudit trousseau destinées à être authentifiées ;

- une unité de contrôle CTR configurée pour vérifier l'unicité d'une clé d'indexation dans une base de données BD de clés publiques ; cette unité de contrôle peut être constituée par un gestionnaire de base de données ;

- une unité STR d'enregistrement configurée pour enregistrer un trousseau dans un enregistrement de la base de données BD, cet enregistrement étant indexé par la clé d'indexation. Cette unité d'enregistrement peut être constituée par un gestionnaire de base de données ; cette unité STR peut être confondue avec l'unité de contrôle CTR ;

- une unité configurée pour rejeter un trousseau si la clé d'indexation obtenue pour ce trousseau n'est pas unique. Dans le mode de réalisation décrit ici, cette unité est l'unité de contrôle CTR précitée. La figure 11 représente une vue fonctionnelle d'un dispositif d'authentification DPA conforme à l'invention. Il comporte :

- une unité IHM d'obtention d'un vérificateur. Cette unité peut être constituée par une interface homme-machine permettant à un utilisateur de saisir un vérificateur ;

- une unité COM d'obtention d'un trousseau de clés à partir d'une clé d'indexation. Cette unité d'obtention peut être constituée par des moyens de communication, ceux-ci étant configurés pour interroger la base de données et pour recevoir le trousseau de clés indexé dans la base de données par la clé d'indexation.

- une unité cryptographique CRY configurée pour obtenir une valeur cryptographique HA en mettant au moins en œuvre une fonction de hachage cryptographique appliquée au moins à au moins une clé publique ;

- une unité de contrôle CTR configurée pour comparer une valeur cryptographique obtenue par l'unité cryptographique CRY et un vérificateur ; et

- une unité d'authentification configurée pour authentifier la clé publique précitée en fonction du résultat de la comparaison. Cette unité d'authentification peut être constituée par l'unité de contrôle CTR.

La figure 12 représente un dispositif client CL conforme à un mode de réalisation de l'invention. Il comporte un processeur 30 et une mémoire 31 dans laquelle est mémorisée un programme d'ordinateur PGCL Ce programme PGCL est un programme apte à mettre en œuvre, lorsqu'il est exécuté par le processeur 30, un procédé sécurisé de transmission de données et un procédé sécurisé de réception de données, ces procédés étant conformes à l'invention.

Ce programme PGCL fait appel à un programme PGPA mémorisé dans la mémoire 31 pour chaque étape d'authentification de clé publique.

Ce programme PGA est un programme apte à mettre en œuvre un procédé d'authentification conforme à l'invention.

L'ensemble constitué par le processeur 30, la mémoire 31 et le programme d'ordinateur 31 constitue un dispositif d'authentification au sens de l'invention.