Brevet FR3046271A1 — publié le 20170630

DEUXIEME AUTHENTIFICATION DYNAMIQUE D'UNE SIGNATURE ELECTRONIQUE UTILISANT UN MODULE MATERIEL SECURISE 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 oeuvre 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 3046271 2 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. 5 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, 10 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 15 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 20 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 25 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 30 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 3046271 3 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 5 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 reconnaitre. 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. 10 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. 15 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 20 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 25 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 30 « 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 3046271 4 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 5 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. 10 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 15 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 20 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 25 à 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 30 é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é 3046271 5 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. 5 Avantageusement, l'invention comporte un procédé de mise en oeuvre d'un système pour une deuxième authentification, mettant en oeuvre 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 10 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 15 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 20 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 25 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 30 signature délivré au serveur de signature. 3046271 6 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 5 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 10 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 condensat de données à signer calculées à partir du document à signer, pour obtenir en retour la signature du condensat des données à signer afin de 15 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 20 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 25 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. 30 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 3046271 7 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. 5 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 10 Secure »). L'application de serveur de signature 4 comporte aussi une structure logicielle 16, 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 15 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 Cryptographic Standards »), utilisant en particulier un protocole de sécurisation des échanges sur Internet du type « SSL » (abréviation des termes anglais 20 « 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 25 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 30 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. 3046271 8 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. 5 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. 10 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 15 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. 20 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 25 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. 30 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. 304 62 71 9 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 5 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 10 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 15 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 20 une étape suivante 48 le module matériel sécurisé 18 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 25 à 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 30 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, 3046271 10 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é 5 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 à 10 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. 15 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 20 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 25 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 30 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é 3046271 11 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 5 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. 10 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. 15 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 20 é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 25 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 30 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 3046271 12 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 5 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 condensat du document si celui-ci lui a été fourni, pour le délivrer dans une étape suivante 98 au serveur de signature. 10 L'ajout du condensat 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 15 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 20 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 25 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 30 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. 3046271 13 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 5 clé SA, le mot de passe à usage unique construit OTP et le document à signer DOC. On a ensuite la signature du condensat ou empreinte des données à signer, constitué à partir du document à signer, comprenant une étape suivante 110 dans laquelle le serveur de signature 4 transmet au module 10 matériel sécurisé 18 l'identifiant de clé IC, le mot de passe à usage unique construit OTP et un condensat du document à signer CDOC. En retour dans une étape suivante 112, le module matériel sécurisé 18 renvoie au serveur de signature 4 la signature du condensat du document à signer CDOCS Dans une étape suivante 114 le logiciel de service de la toile 15 « 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 116 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 20 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 25 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 30 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. 3046271 14 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. 5 REVENDICATIONS1 - Système pour une deuxième authentification dynamique d'une signature électronique par un utilisateur signataire (30) d'un document disposant de clés de signature se trouvant dans un conteneur de clé contenu dans un serveur de signature (4), à partir d"applications d'enrôlement du signataire (14) et de signature (122) connectées à ce serveur, caractérisé en ce qu'il comporte un module matériel sécurisé (18) prévu pour être relié au serveur de signature (4), comportant des moyens de construction d'un challenge d'activation (CA) à partir d'un identifiant de clé (IC), et d'un mot de passe d'initialisation (MdP) donné par le signataire (30), pour délivrer ce challenge au serveur de signature (4) qui demande alors à une application de calcul (66) de calculer un mot de passe à usage unique à envoyer au signataire (30). 2 - Procédé de mise en oeuvre d'un système pour une deuxième authentification, caractérisé en ce qu'il met en oeuvre un système selon la revendication 1. 3 - Procédé de mise en oeuvre selon la revendication 2, caractérisé en ce qu'il réalise une génération de la clé de signature comprenant une étape (46) de transmission par le serveur de signature (4) au module matériel sécurisé (18), d'un identifiant de clé (IC), d'un compteur d'utilisation maximum (CU) et d'un mot de passe d'initialisation (MdP), pour obtenir en retour une paire de clés sous forme de jeton de clé lié à l'utilisateur (JC) et contenu dans son conteneur de clés, qui est produit par ce module. 4 - Procédé de mise en oeuvre selon la revendication 2 ou 3, caractérisé en ce qu'il 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 (OTP), et une demande de signature de la demande de certificat. 5 - Procédé de mise en oeuvre selon la revendication 4, caractérisé en ce que la demande d'activation de clé de signature comprend une étape (58) de transmission par le serveur de signature (4) au module matériel sécurisé 3046271 16 (18), d'un identifiant de clé (IC) qui a été délivré par le signataire (30), et d'une date d'activation (DA), pour obtenir en retour un challenge d'activation (CA) qui est délivré ensuite à une application de calcul (66) calculant à partir de ce challenge un mot de passe à usage unique (OTP), puis une étape (72) de 5 transmission du serveur de signature (4) au module matériel sécurisé (18), de l'identifiant de clé (IC), du mot de passe à usage unique (OTP) et de la demande de signature de certificat (CaS), pour obtenir en retour la demande de certificat signé (CS) démontrant la preuve de possession de la clé. 6 - Procédé de mise en oeuvre selon la revendication 5, caractérisé en 10 ce qu'il réalise ensuite un dépôt de demande de certificat signé (CS) à une infrastructure de gestion de clés cryptographiques (IGC), pour obtenir un certificat de signature (CdS) délivré au serveur de signature (4). 7 - Procédé de mise en oeuvre selon l'une quelconque des revendications 2 à 6, caractérisé en ce qu'il réalise avec une application de 15 signature (122), une activation de la clé de signature d'un document, puis une signature de ce document. 8 - Procédé de mise en oeuvre selon la revendication 7, caractérisé en ce que l'activation de la clé de signature du signataire comporte une étape (96) de transmission par le serveur de signature (4) au module matériel sécurisé 20 (18), de l'identifiant de clé (IC) et de la date d'activation (DA), pour obtenir en retour un challenge d'activation (CA) qui est délivré ensuite à une application de calcul (66) calculant un mot de passe à usage unique (OTP), puis une étape (102) de transmission de ce mot de passe au signataire (30), et ensuite après la saisie de ce mot de passe par le signataire et la transmission du document 25 à signer, une étape (110) de transmission par le serveur de signature (4) au module matériel sécurisé (18), de l'identifiant de clé (IC), du mot de passe à usage unique (OTP), et d'un condensat de données à signer (CDOC) calculées à partir du document à signer, pour obtenir en retour la signature du condensat des données à signer (CDOCS) afin de permettre au serveur de 30 signature de constituer le document signé.