La présente invention concerne un système de deuxième authentification dynamique d'une signature électronique, comprenant un module matériel sécurisé, ainsi qu'un procédé d'authentification dynamique d'une signature mettant en œuvre un tel système.

Le développement des moyens de communication électroniques permet aux entreprises et aux administrations de proposer un grand nombre d'applications en ligne donnant à des utilisateurs la possibilité d'accéder de manière rapide et avec un débit important à des systèmes d'information, et de réaliser des échanges de données. Ces communications peuvent être nationales ou internationales.

Toutefois les échanges électroniques nécessitent dans certains cas une signature électronique garantissant une identification et une authentification de l'utilisateur avec un niveau de sécurité suffisamment élevé pour assurer une confiance des parties, en évitant des risques d'incidents ou de malveillance. Ces échanges peuvent concerner des données confidentielles personnelles, d'entreprises ou d'administrations. Les transactions financières doivent en particulier assurer ce niveau de sécurité.

Les applications sécurisées comportent un premier facteur d'authentification de l'utilisateur permettant d'utiliser une clé privée de signature, qui peut être immatérielle comme un mot de passe, ou matérielle comme une clé USB ou une carte à puce. L'utilisateur peut être une personne physique ou une machine.

Le conseil de l'union européenne a adopté en 2014 un nouveau règlement concernant l'identification électronique et les services de confiance, appelé « e-IDAS » (abréviation des termes anglais « Electronic identification and trust services »), qui impose un deuxième facteur d'authentification pour obtenir une certification des échanges électroniques.

Lors de la réalisation d'une signature il faut vérifier que l'utilisateur appliquant cette signature est bien celui qui s'authentifie, pour permettre l'utilisation de cette clé privée de signature. Ce contrôle permet d'assurer les parties qu'un tiers ne peut pas usurper l'identité de l'utilisateur. Il permet de plus de délivrer une signature qui n'est pas répudiable, ce qui apporte une sécurité juridique pour les parties.

Un système connu de double authentification utilise pour la deuxième authentification un mot de passe à usage unique, appelé « OTP » (abréviation des termes anglais « one time password »), délivré par un support matériel appelé aussi jeton (en langue anglaise « token »).

Lors de la demande par l'application de la deuxième authentification, l'utilisateur détenant le support matériel réalise sa connexion avec l'application par la saisie du code temporaire fourni par ce support. Ce code temporaire est établi de manière synchrone par une technologie cryptographique.

Le support matériel peut être en particulier une carte à puce, ou un boîtier (appelé « token » en langue anglaise), que l'on relie à un ordinateur par un port USB. Ce système constitue une technologie dite connectée, qu'il est nécessaire de relier à un appareil ce qui comporte des inconvénients car elle n'est pas facilement portable.

De plus ce système entraîne des coûts élevés venant de l'installation des logiciels sur les ordinateurs, la réalisation des supports matériels, leurs distributions ainsi que la maintenance.

Un autre système connu de double authentification utilise un support matériel pour la première authentification, et un code pour la deuxième. C'est le cas en particulier des distributeurs de monnaie aux guichets automatiques de retrait bancaire, demandant après l'insertion d'une carte à puce la saisie d'un code secret. Ce système entraîne aussi des coûts importants.

Un autre système connu de double authentification utilise pour la deuxième authentification une grille dynamique générée par l'application suivant un codage particulier renouvelé à chaque demande, qui est envoyée à l'utilisateur. L'utilisateur rentre alors son mot de passe sur la grille, ce qui réalise un cryptage de ce mot de passe.

Ce système utilisé notamment par des banques pour sécuriser les ordres passés par Internet, pose en particulier un problème de saisie par le signataire du mot de passe sur la grille dynamique, qui n'est pas très simple. De plus elle comporte des coûts de création et de distribution des grilles dynamiques.

Un autre système connu de double authentification utilise pour la deuxième authentification des données biométriques du signataire. Ce système déjà utilisé par exemple sur des téléphones intelligents pour les déverrouiller, comporte un capteur qui lit les empreintes digitales d'un doigt posé dessus, afin de les reconnaître.

Ce système nécessite un matériel de lecture biométrique mis à disposition de chaque utilisateur, ce qui entraîne des coûts importants.

On peut aussi réaliser une double authentification en utilisant deux mots de passe définis successifs pour réaliser les deux authentifications. Toutefois le deuxième mot de passe restant figé peut être capté, par exemple avec une attaque ou un vol de données. La fiabilité de l'authentification n'est pas très forte.

Un autre système connu de double authentification utilise pour la deuxième authentification un mot de passe à usage unique OTP du type asynchrone, généré après chaque première authentification, qui est envoyé sur le téléphone de l'utilisateur sous forme de message de service « SMS » (abréviation des termes anglais « short message service »). Ce système est utilisé en particulier pour sécuriser des ordres bancaires.

En variante le mot de passe à usage unique OTP peut être envoyé sous d'autres formes, et à tout autre sorte de matériel périphérique connecté permettant de le recevoir, comme un ordiphone, une tablette ou un ordinateur.

Cependant pour assurer un niveau de sécurité maximum il est nécessaire que la génération, le stockage et la vérification du mot de passe à usage unique OTP permettant l'utilisation de la clé de signature de l'utilisateur, soient résistants aux différents types d'attaques connus, comprenant en particulier l'espionnage du réseau (en langue anglaise « sniffer »), l'interception d'une communication entre deux parties « MITM » (abréviation des termes anglais « man in the middle »), l'exploitation d'une faille applicative (en langue anglaise « buffer overflow »), l'attaque par répétition d'une transmission (en langue anglaise « replay attack »), le vol de données ou la prédiction de nombres aléatoires.

Ce dernier système connu utilisant un mot de passe à usage unique OTP du type asynchrone, généré par logiciel ou par matériel, ne convient pas pour le niveau de sécurité demandé car il définit son mot de passe sans spécifier les moyens sécurisant l'intégralité du protocole. En particulier l'état de l'art actuel ne permet pas d'authentifier un utilisateur auprès d'une application, et ne garantit pas l'impossibilité d'utilisation de sa clé privée de signature par un autre moyen.

La présente invention a notamment pour but d'éviter ces inconvénients de la technique antérieure, en réalisant pour ce système de double authentification une liaison entre l'utilisateur, la clé privée de signature, et optionnellement, le document à signer, dans le cadre d'un protocole garantissant la sécurité du transport du mot de passe à usage unique OTP dans toute la procédure, qui supprime en particulier les possibilités d'attaque du type espionnage de réseau, et d'interception d'une communication entre deux parties MITM.

Elle propose, à cet effet, un système pour une deuxième authentification dynamique d'une signature électronique par un utilisateur signataire d'un document disposant de clés de signature se trouvant dans un conteneur de cl contenu dans un serveur de signature ; des applications d'enrôlement et de signature étant connectées à ce serveur. Ce système est remarquable en ce qu'il comporte un module matériel sécurisé prévu pour être relié au serveur de signature, comportant des moyens de construction d'un challenge d'activation à partir d'un identifiant de clé, et d'un mot de passe d'initialisation donné par le signataire, pour délivrer ce challenge au serveur de signature qui demande alors à une application de calcul de calculer un mot de passe à usage unique à envoyer au signataire.

Un avantage de ce système matériel sécurisé est qu'il constitue un élément extérieur fortement sécurisé délivrant le challenge d'activation pour obtenir la deuxième authentification, qui est lié à la fois à la clé de signature et au mot de passe d'initialisation, ce qui rend impossible tout accès à la clé contenue dans le conteneur de clés du signataire, sans l'activation de ce module. On obtient ainsi un niveau de sécurité élevé.

L'invention peut comporter de plus une ou plusieurs des caractéristiques suivantes, qui peuvent être combinées entre elles.

Avantageusement, l'invention comporte un procédé de mise en œuvre d'un système pour une deuxième authentification, mettant en œuvre un système comprenant les caractéristiques précédentes.

Avantageusement, le procédé réalise une génération de la clé de signature comprenant une étape de transmission par le serveur de signature au module matériel sécurisé, d'un identifiant de clé, d'un compteur d'utilisation maximum et d'un mot de passe d'initialisation, pour obtenir en retour une paire de clés sous forme de jeton de clé lié à l'utilisateur et contenu dans son conteneur de clés, qui est produit par ce module.

Avantageusement, le procédé réalise une demande de certificat de signature associée à la clé de signature générée, comprenant successivement une demande d'activation de la clé de signature, le calcul d'un mot de passe à usage unique, et une demande de signature de la demande de certificat.

Dans ce cas, la demande d'activation de clé de signature peut comprendre une étape de transmission par le serveur de signature au module matériel sécurisé, d'un identifiant de clé qui a été délivré par le signataire, et d'une date d'activation, pour obtenir en retour un challenge d'activation qui est délivré ensuite à une application de calcul calculant à partir de ce challenge un mot de passe à usage unique, puis une étape de transmission du serveur de signature au module matériel sécurisé, de l'identifiant de clé, du mot de passe à usage unique et de la demande de signature de certificat, pour obtenir en retour la demande de certificat signé démontrant la preuve de possession de la clé.

Le procédé peut réaliser ensuite un dépôt du certificat signé à une infrastructure de gestion de clé cryptographique, pour obtenir un certificat de signature délivré au serveur de signature. Avantageusement, le procédé réalise avec une application de signature, une activation de la clé de signature d'un document, puis une signature de ce document.

Dans ce cas, l'activation de la clé de signature du document peut comporter une étape de transmission par le serveur de signature au module matériel sécurisé, de l'identifiant de clé et de la date d'activation, pour obtenir en retour un challenge d'activation qui est délivré ensuite à une application de calcul calculant un mot de passe à usage unique, puis une étape de transmission de ce mot de passe au signataire, et ensuite après la saisie de ce mot de passe par le signataire et la transmission du document à signer, une étape de transmission par le serveur de signature au module matériel sécurisé, de l'identifiant de clé, du mot de passe à usage unique et d'un condensât de données à signer calculées à partir du document à signer, pour obtenir en retour la signature du condensât des données à signer afin de permettre au serveur de signature de constituer le document signé.

L'invention sera mieux comprise et d'autres caractéristiques et avantages apparaîtront plus clairement à la lecture de la description ci-après donnée à titre d'exemple, en référence aux dessins annexés dans lesquels :

- la figure 1 présente l'environnement d'un serveur de signature utilisant un système de deuxième authentification selon l'invention ;

- les figure 2, 3 et 4 présentent trois parties successives du procédé d'enrôlement du signataire par une application d'enrôlement utilisant le système de deuxième authentification ; et

- la figure 5 présente la partie suivante du procédé comprenant la signature d'un document par une application de signature.

La figure 1 présente un serveur de signature 4 comportant une application de serveur de signature présentant un module de signature 6 et un module de gestion des utilisateurs 8 réalisant des échanges avec une base de données 10.

D'une manière générale l'application de serveur de signature 4 comporte un logiciel de service de la toile « administrateur » 12 (« Web service » en langue anglaise), réalisant des échanges avec une application cliente extérieure d'enrôlement du signataire 14, et avec une application de calcul de mot de passe à usage unique OPT, et un logiciel de service de la toile « signature » (« Web service » en langue anglaise), réalisant des échanges avec une application cliente extérieure de signature.

Ces échanges sont réalisés par l'intermédiaire d'un protocole de transmission de messages entre objets distants du type « SOAP » (abréviation des termes anglais « Simple Object Access Protocol »), utilisant avantageusement un protocole de transfert hypertexte sécurisé du type « HTTPS » (abréviation des termes anglais « HyperText Transfer Protocol Secure »).

L'application de serveur de signature 4 comporte aussi une structure logicielle 1 6, appelée en terme anglais « Framework ».

L'application de serveur de signature 4 réalise des échanges avec un module matériel sécurisé extérieur 18 du type « HSM » (abréviation des termes anglais « Hardware Security Module »), par l'intermédiaire d'une interface de standard de cryptographie à clé publique du type « PKCS » (abréviation des termes anglais « Public Key Cryptographie Standards »), utilisant en particulier un protocole de sécurisation des échanges sur Internet du type « SSL » (abréviation des termes anglais « Secure Sockets Layer »).

Les figures 2, 3, 4 et 5 présentent à gauche l'application d'enrôlement du signataire 14 ou l'application de signature 122, qui est l'application cliente extérieure, comprenant une interface utilisatrice de l'application 20 tournée vers le signataire 30, et un module de communication 22 avec le serveur de signature 4, utilisant le protocole de transmission de messages SOAP.

Ces figures présentent à droite le serveur de signature 4 comprenant le logiciel de service de toile « administrateur » 12 « Web service », qui échange avec le module de communication 22 de l'application d'enrôlement du signataire 14 ou de l'application de signature 122, et une interface centralisée 24 échangeant avec le module matériel sécurisé extérieur 18 HSM qui est un appareil réputé inviolable offrant des fonctions cryptographiques, pouvant générer, stocker et protéger des clés cryptographiques. Les étapes suivantes présentées figures 2, 3 et 4 sont réalisées pour successivement enrôler un signataire et générer une clé de signature, puis activer cette clé pour réaliser une demande de certificat, et enfin déposer le certificat obtenu par une infrastructure de gestion de clé cryptographique.

La figure 2 présente la première partie du procédé d'inscription ou enrôlement de l'utilisateur ou signataire, qui va créer ce signataire et générer une clé de signature à parti d'un identifiant.

On réalise d'abord la création du signataire, comprenant les étapes suivantes.

Dans une première étape 32, le signataire 30 effectue une demande d'enrôlement, en donnant à l'application d'enrôlement 14 son nom d'utilisateur NU, et un secret d'activation de son conteneur de clé SA qui est le premier facteur d'authentification. Dans une étape suivante 34 l'application d'enrôlement 14 demande au serveur de signature 4 une ouverture de session.

Dans une étape suivante 36 l'application d'enrôlement 14 demande au serveur de signature 4 la création d'un utilisateur définissant un conteneur de clés dans ce serveur, dédié pour le signataire 30, en lui transmettant le nom de l'utilisateur NU et le secret d'activation du conteneur de clé SA.

Le conteneur de clé définit un espace dans le serveur de signature 4, dédié pour l'utilisateur, contenant des données qui ne sont accessibles que par lui.

En retour dans une étape suivante 38 le serveur de signature 4 génère un identifiant utilisateur IU transmis à l'application d'enrôlement 14, puis dans une étape suivante 40 cette application d'enrôlement transmet l'identifiant utilisateur IU au signataire 30.

En complément dans cette première partie le signataire 30 peut demander plusieurs clés de signature pour le même conteneur, afin de signer de manière différenciée différents documents contenus dans ce conteneur.

On réalise dans une deuxième partie du procédé, la génération de la clé de signature qui permettra la deuxième authentification, réalisant les étapes suivantes. Dans une première étape 42 pour obtenir un identifiant de clé IC et permettre d'accéder au conteneur, le signataire 30 transmet à l'application d'enrôlement 14 l'identifiant utilisateur reçu IU, le secret d'activation du conteneur de clé SA, un identifiant de clé IC, et un mot de passe d'initialisation de la clé MdP qui peut être fourni par une application tiers de confiance, afin de créer le système de deuxième facteur d'authentification qui sera lié à la clé.

Dans une étape suivante 44 de génération de la clé de signature, comportant une partie publique et une partie privée restant cachée dans le module matériel sécurisé 18, l'application d'enrôlement 14 transmet au serveur de signature 4 l'identifiant utilisateur IU, l'identifiant de clé IC et le mot de passe d'initialisation de la clé MdP.

Dans une étape suivante 46 de génération de la clé de signature, le serveur de signature 4 transmet au module matériel sécurisé 18 l'identifiant de clé IC, un compteur d'utilisation maximum CU et le mot de passe d'initialisation MdP, pour lui permet de générer une clé de signature.

Le module matériel sécurisé 18 va utiliser le mot de passe d'initialisation MdP pour associer à la génération de la clé de signature une propriété particulière permettant de construire un secret dynamique, appelé aussi mot de passe à usage unique OTP, qui est lié à la clé et donc à l'utilisateur. Dans une étape suivante 48 le module matériel sécurisé 1 8 transmet au serveur de signature 4 un jeton de clé, associé à l'utilisateur JC, formant une paire de clés appelée aussi bi-clé.

Dans une étape suivante 50 le serveur de signature 4 transmet l'identifiant de clé IC à l'application d'enrôlement 14, cette application l'adresse à son tour dans une étape suivante 52 à l'utilisateur 30.

On réalise dans une troisième partie du procédé présentée figure 3, la demande de certificat permettant d'activer la clé de signature comprenant les étapes suivantes.

La figure 3 présente dans une première étape 56 la demande d'activation de la clé de signature par l'application d'enrôlement 14 transmettant au serveur de signature 4 la demande d'activation de la clé de signature, comprenant l'identifiant utilisateur IU, l'identifiant de clé IC et le secret d'activation du conteneur de clé SA.

Le serveur de signature 4 transmet au module matériel sécurisé 18 l'identifiant de clé IC, et une date d'activation DA. Le module matériel sécurisé 18 associe alors à la clé de signature un challenge d'activation CA qui est calculé à partir du mot de passe d'initialisation MdP, et le transmet dans une étape suivante 60 au serveur de signature 4.

Dans une étape suivante 62 le serveur de signature 4 transmet à l'application d'enrôlement 14 le challenge d'activation CA, qui le transmet à son tour dans une étape suivante 64 à une application de calcul OTP 66 calculant à partir de ce challenge un secret d'activation dynamique qui constitue un mot de passe à usage unique OTP. En retour dans une étape suivante 68 l'application de calcul OTP 66 transmet à l'application d'enrôlement 14 le mot de passe à usage unique construit OTP.

Dans une étape suivante 70 l'application d'enrôlement 14 transmet au serveur de signature 4 une demande de signature de certificat « CSR » (abréviation des termes anglais « Certificate Signing Request »), couplé à la clé de signature, comprenant l'identifiant utilisateur IU, l'identifiant de clé IC, le secret d'activation du conteneur de clé SA et le mot de passe à usage unique construit OTP.

Le serveur de signature 4 transmet dans une étape suivante 72 au module matériel sécurisé 18 cette demande de signature de certificat CSR, comprenant l'identifiant de clé IC, le mot de passe à usage unique construit OTP et la demande de certificat à signer CaS. En retour dans une étape suivante 74 le module matériel sécurisé 18 transmet au serveur de signature 4 la demande de certificat signée CS, qui est ensuite transmis dans une étape suivante 76 à l'application d'enrôlement 14.

On réalise dans une quatrième partie du procédé présenté figure 4 le dépôt du certificat dans le serveur de signature 4, comprenant les étapes suivantes.

Dans une première étape 78 l'application d'enrôlement 14 transmet la demande de certificat à une infrastructure extérieure de gestion de clé cryptographique « IGC » (abréviation des termes « Infrastructure de Gestion de clés »).

Dans une étape suivante 82 l'infrastructure de gestion de clés IGC délivre à l'application d'enrôlement 14 un certificat de signature CdS comprenant des données publiques couplées à la clé de signature.

Dans une étape suivante 84 l'application d'enrôlement 14 réalise un dépôt du certificat au serveur de signature 4, en lui transmettant l'identifiant utilisateur IU, l'identifiant de clé IC, le secret d'activation du conteneur de clé SA et le certificat de signature CdS.

En particulier le certificat de signature CdS peut être suivant la norme

X509, qui est une norme de cryptographie de l'Union internationale des télécommunications pour les infrastructures à clés publiques, établissant notamment un format standard de certificat électronique et un algorithme pour la validation de chemin de certification.

En variante le serveur de signature peut demander directement à l'infrastructure de gestion de clés IGC la délivrance du certificat au serveur de signature 4.

Le serveur de signature 4 vérifie à ce moment-là que le certificat de signature reçu correspond bien à la clé privée du signataire, puis dans une étape suivante 86 délivre à l'application d'enrôlement 14 l'information que le certificat de signature importé CdS est disponible. Dans une étape suivante 88 l'application d'enrôlement 14 présente au signataire 30 la clé de signature et le certificat de signature CdS disponible.

On réalise dans une cinquième partie du procédé présenté figure 5 la signature par le signataire de documents dans le serveur de signature 4, comprenant les étapes suivantes.

Dans une première étape 90 pour la signature d'un document, le signataire 30 délivre à l'application de signature 122 le secret d'activation du conteneur de clé SA, et en option le document à signer DOC. En variante le document à signer peut être fourni dans une étape ultérieure.

Pour la demande d'activation de la clé de signature, l'application de signature 122 transmet alors dans une étape suivante 92 l'identifiant utilisateur IU, l'identifiant de clé IC et le secret d'activation SA à l'application de calcul OTP 66, qui transmet à son tour ces éléments au serveur de signature 4 dans une étape suivante 94.

Ensuite le serveur de signature 4 effectue une demande d'activation de la clé de signature, en transmettant par une étape suivante 96 l'identifiant de clé IC et la date d'activation DA au module matériel sécurisé 18, qui établit alors un challenge d'activation CA calculé à partir du mot de passe d'initialisation MdP, et en option du condensât du document si celui-ci lui a été fourni, pour le délivrer dans une étape suivante 98 au serveur de signature.

L'ajout du condensât de document comme information permet de lier la signature à ce document uniquement, ce qui garantit que la clé ne sera pas utilisable pour signer d'autres documents.

Dans une étape suivante 100 le serveur de signature 4 délivre le challenge d'activation CA à l'application de calcul OTP 66, qui d'une part dans une opération suivante 102 envoie au signataire 30 un message du type SMS contenant le mot de passe à usage unique construit OTP, et d'autre part dans une opération parallèle 104 informe l'application de signature 122 de cet envoi.

On notera que l'application de calcul OTP 66 ne peut délivrer son mot de passe à usage unique construit OTP que si elle reçoit le secret d'activation du conteneur de clé SA et le challenge d'activation CA. Sans cette dernière information venant du module matériel sécurisé 18, le mot de passe à usage unique OTP ne peut être délivré, ce qui assure un bon niveau de sécurité.

On notera aussi que l'application de calcul OTP 66 ne transmet pas le mot de passe à usage unique OTP à l'application de signature 122, cette application ne peut donc pas réaliser l'opération de signature sans l'intervention du signataire. De plus l'application de signature 122 ne peut pas réaliser d'échange avec le serveur de signature 4 en utilisant le service de la toile « administrateur » 12 pour demander elle-même l'activation de la clé, ce qui assure un bon niveau de sécurité par cloisonnement des actions permises auprès de ce serveur de signature.

Dans une étape suivante 106 le signataire 30 rentre le mot de passe à usage unique construit OTP sur l'application de signature 122. On a ensuite la signature du document comprenant une étape suivante 108 dans laquelle l'application de signature 122 transmet à un logiciel de service de la toile « signature » 120 du serveur de signature 4, l'identifiant du signataire IS, l'identifiant de la clé IC, le secret d'activation du conteneur de clé SA, le mot de passe à usage unique construit OTP et le document à signer DOC.

On a ensuite la signature du condensât ou empreinte des données à signer, constitué à partir du document à signer, comprenant une étape suivante 1 10 dans laquelle le serveur de signature 4 transmet au module matériel sécurisé 18 l'identifiant de clé IC, le mot de passe à usage unique construit OTP et un condensât du document à signer CDOC. En retour dans une étape suivante 1 12, le module matériel sécurisé 18 renvoie au serveur de signature 4 la signature du condensât du document à signer CDOCS

Dans une étape suivante 1 14 le logiciel de service de la toile « signature » 120 du serveur de signature 4 transmet à l'application de signature 122 le document signé ou la signature détachée DS. Dans une dernière opération 1 16 l'application de signature 122 transmet au signataire 30 le document signé pour qu'il puisse le récupérer.

On obtient ainsi grâce au module matériel sécurisé 18 qui peut être facilement connecté au serveur de signature 4, un composant indépendant qui génère des clés de signature et les garde avec un haut niveau de sécurité, et qui ne peut délivrer la signature de données à signer CDOCS que si on lui donne le bon mot de passe à usage unique construit OTP. Le signataire et la clé privée de signature sont liés dans ce module matériel sécurisé 18, et non au niveau applicatif, ce qui offre une sécurité renforcée sur l'utilisation de cette clé.

Le caractère dynamique du secret d'activation permet de garantir l'unicité des transactions, en supprimant le problème du re-jeu. En particulier les moyens connus dans l'art antérieur pour générer des mots de passe à usage unique OTP ne permettent que d'authentifier un utilisateur auprès d'une application, ils ne garantissent pas contre l'utilisation de la clé de signature par un autre moyen. On notera que l'application de signature 122 ainsi que l'application d'enrôlement 14 ne connaissent pas le module matériel sécurisé 18 qui est un composant extérieur, ce qui fait qu'il est protégé d'une attaque de ces ensembles comportant des logiciels qui peuvent être plus facilement forcés.