Brevet FR2823927A1 — publié le 20021025

numérique. 1 2823927 Définition: L'invention concerne un moyen de cryptographie asymétrique visant à sécuriser toutes transactions électroniques. Cette sécurisation cryptographique est réalisoe à travers une double authentification asymétrique générce de manière pseudo-aléatoire. Les principes de protection ou d'authentification par systèmes à clefs publiques et privées reposent sur une communication point à point, de l' émetteur vers le récepteur, avec l' intervention d 'un tiers communément qualifié "annnaire" qui est consulté par l'émetteur afin de conna^itre la clef publique de chiffrement du destinataire dans un but de confidentialité du message, puis par le destinataire afin de conna^itre la clef publique de signature de l'émetteur dans un but d'authentification de la provenance du message. Différents obstacles sont identifiables pour la mise en oeuvre de ces principes: a) L'émetteur et le destinataire sont tenus d'8tre équipés des logiciels adéquats afin de chiffrer, déchiffrer, signer et authentifier un message. b) L'émetteur et le destinataire sont tenus de posséder, et d'avoir a leur disposition au moment o ils désirent échanger des données, une clef secrète permettant le chiffrement et la signature. Une clef étant souvent une longue séquence de chiffre et de lettres, il est malaisé et fastidieux pour un utilisateur nomade de transférer sa clef d'un poste de travail à un autre en fonction de ses besoins. c) L'émetteur et le destinataire sont tenus de publier leurs clefs publiques sur le méme système d'annnaire. d) Un utilisateur peut être contraint, sous la menace, d'authentifier un message qu'il ne désire pas signer. e) Dans les systèmes de communication standard (SMTP, POP...) I'émetteur est rarement informé de la bonne récepti on du message. Lorsqu'il l' est. cet accu sé de récepti on est rarement authentifié, et donc sans valeur logale. Description de l'invention: Les utilisateurs communiquent via un serveur centralisé (nommé ci-après "serveur") qui prend en charge les problèmes d'authentification. Ce serveur propose une interface web, par applet Java, afin de fournir des services de cryptage et d'authentification à des utilisateurs ne disposant pas d'un poste de travail spécfflquement équipé. Lors de son inscription au service, le système choisira aléatoirement une graine, codée sur un nombre de caractères aisément saisissable sur un clavier. Cette graine, fournie à un générateur aléatoire convenu, permettra de générer un couple clefs privoelpublique RSA. Le service remet alors à l'utilisateur la graine et son login, et ne mémorise dans le serveur que la clef publique ainsi que le login qui lui est associé. Le login est. classiquement, un couple identifiantlmot de passe. Cependant, deux mots de passes seront fournis à l'utilisateur. Le premier pour une identification "normale", le second étant une "alarme silencieuse" informant le service qu'il s'authentifie sous la contrainte. Le couple clef privéclpublique précédemment évoqué ne sert que pour l'authentification. Les échanges entre un utilisateur et le serveur sont chiffrés à l'aide de clefs RSA générées spécifiquement pour la transaction en cours. Le serveur se charge de stocker le message, puis de le transmettre de la même manière (chiffrée par une nouvelle clef RSA générce au moment de la transaction) au destinataire lorsque celui-ci se connectera afin de consulter ses messages. Si le destinataire n'est pas un utilisateur du service, il recevra par un e-mail classique, un court message l'informant qu'il peut consulter sur le serveur, un e-mail authentifié. Cependant, dans ce cas, le service ne pourra garantir l'identité du destinataire du message, et l'accusé de réception ne pourra être alors fourni à l'émetteur qu'à titre indicatif, sans la moindre valeur logale. Le serveur agit donc comme un "tiers de confiance". Cependant les clefs d'authentification restent la - propriété exclusive des utilisateurs, le serveur ne possédant que les clefs de vérifications. L'invention sera mieux comprise à l'aide de la description suivante des différentes étapes entre le client et le serveur: figure 1 On nomme " poste client " un system informatique à la disposition de l'utilisateur qui est doté d'un programme spécifique ou bien de la possibilité de télécharger une applet JAVA. On nomme " applications " un programme informatique fournis par " Fullcrypt " et installé sur le poste client ou bien une applet JAVA qui a été télécharge au préalable. On nomme "serveur" le system informatique central de la société "Fullcrypt" qui est doté de connexion à l'lnternet d'une base de donnée et de la possibilité d'émettre l'applet JAVA. On nomme " l'utilisateur " la personne physique inscrite au service et détenteur d'une clef Fullcrypt. L'utilisateur exécute l'application du poste client et se connecte sur le serveur. ( 1) L'application génère un couple clef publique, clef privée RSA nommé (PaKa) aleatoirement et garde en mémoire la clef privée (Ka). (2) L'application ouvre une connexion (C) sur le serveur et transmet la clef publique (Pa) (3) Le serveur mémorise la clef (Pa) reçu puis généré un couple clef publique/clef privée RSA nommé (PbKb) et garde en mémoire la clef privée (Kb) (4) Le serveur émet sur (C) la clef publique (Pb) (5) L'application mémorise (Pb) puis demande à l'utilisateur son identifiant et son mot de passe (6) L'utilisateur saisis son identifiant et son mot de passe. Ce couple est matérialisé soit par deux châmes (l'identifiant et le mot de passe) de caractère saisis par l'intermédiaire d'un clavier soit par une châîne de caractère (l'identifiant) et une mesure Biométrique (le mot de passe) lu par un équipement spécifique. (7) L'application calcul le digest MD5 du mot de passe puis chiffre a l'aide de la clef (Pb) le couple identifiantlmot de passe. (8) L'application émet sur (C le message ainsi chiffré (9) Le serveur déchiffre le message a l'aide de (Kb) et vérifie dans la base de donnce le couple identifiantldigest MD5. Si le digest MD5 correspond à celui du mot de passe " prise d'otage " de l'utilisateur, une alarme silencieuse est déclenchée. (10) Si le digest MD5 fournis correspond au mot de passe de 1'utilisateur ou bien a son mot de passe " prise d'otage ", le serveur émet sur (C) une validation de la connexion. (11) L'application est désorrnais entièrement accessible a l'utilisateur. I1 peut y effectuer des opérations de maintenance courante ou bien émettre un message authentifié. (12) L'utilisateur saisis le message (M) à authentifier. (13) L'utilisateur signe son message a l'aide de la clef Fullcrypt qui est en sa possession ( 14) L' application calcul la clef publique/clef privée (PfK a l'aide d'un générateur pseudo aléatoire prédéfini qui prendra comme graine de génération la clef Fullcrypt saisis. (15) L'application calcul la signature (S) RSA de (M) à l'aide de (Kf) (16) L'application calcul le chiffrage RSA (R) du message (M) et de la signature (S) a l'aide de (Pb). (17) L'application émet sur (C) le message (R) (18) Le serveur déchiffre (R) a l'aide de (Kb), vérifie la signature (S) a l'aide de la clef (Pf, présente dans la base de donnée et aectée a l'utilisateur qui s'est connecté, puis stock dans la base de donnée le message (M). (19) Le serveur calcul le digest MD5 (DS) de l'ensemble des donnces avant cryptage qu'il à émis. (20) Le serveur émet (DS) sur (C) 3 2823927 (21) L'application vérifie que le digest MD5 correspond bien au données qu'elle à reçues. (22) L ' application calcul le digest MD5 (DA) de l' ensemble des données avant cryptage qu'elle à émise. (23) L'application émet (DA) sur (C). Le serveur vérifie que le digest MD5 est bien celui des donnces qu'il à reçues et dans ce cas valide la transaction. (24) Lorsque l'utilisateur quitte l'application, la connexion (C) est fermée. so 4 2823927 REVENDICATIONS: 1. Le procédé d'authentification est caractérisé par l'utilisation d'une graine aisément saisissable (2) qui génère une clef privée (5) d'un algorithme de chiffrement asymétrique (4) donnant lieu à une authentification forte (3). 2. Le procédé d'authentification selon la revendication 1 est caractérisé par une vérification en ligne (" ON-LINE ") d'une identification et d'un mot de passe (3) afin de limiter les risques de collisions. 3. Le procédé d'authentification selon la revendication 1 et 2 est caractérisé par la fourniture a l'utilisateur d'un mot de passe qualifié de " code prise d'otage " permettant à celui-ci de déclencher une alarme silencieuse s'il emploi le procédé d'authentification sous la contrainte d'un tiers. 4. Le procédé d'authentification selon l'une quelconque des revendications est caractérisé par un chiffrage asymétrique de l'ensemble des échanges entre l'application et le serveur a l'aide de clefs générées aléatoirement en début de transaction. 5. Le procédé d'authentification selon la revendication 1 est caractérisé par la validation de la transaction par échange de la table de donnces MD5 (" digesf MDS ") de l'ensemble des données transmises entre l'application et le serveur, garantissant la non-immixtion d'un tiers dans les échanges de donnces. sc