Brevet FR2948839A1 — publié le 20110204

La présente invention entre dans le domaine de l'authentification d'un utilisateur et l'accès sécurisé à des données via un réseau de communication. L'invention concerne plus particulièrement l'authentification sécurisée d'un utilisateur depuis un terminal via un serveur distant pour lui permettre d'accéder à des données de manière sécurisée. L'invention trouvera une application préférentielle, mais aucunement limitative, dans l'authentification sécurisée d'un utilisateur pour accéder au contenu chiffré d'un support, au travers de la connexion à un serveur distant via ledit réseau de communication, notamment de type informatique. De plus, l'invention entre dans le cadre de l'authentification d'un utilisateur par mot de passe, en particulier un mot de passe court, tel un code PIN pour � Personal Identification Number �. L'authentification par mot de passe, notamment un code PIN, requiert la saisie dudit code pour vérification auprès d'un serveur distant. Le cas le plus utilisé de ce type d'authentification est le paiement bancaire par carte à puce. L'inconvénient majeur de cette authentification réside dans la taille du mot de passe, à savoir quatre caractères pour un code PIN. Dès lors, le nombre limité de combinaisons, à savoir 10000 dans le cas d'un code à caractères numériques, soulève un problème majeur de sécurité. En effet, une recherche du mot de passe par � force brute �, à savoir la recherche et le test systématique de toutes les combinaisons possibles, rend aisée sa découverte avec les capacités de calcul actuelles des ordinateurs. C'est pourquoi, un mécanisme de comptage a été introduit afin de limiter le nombre de tentatives pour découvrir le code. En effet, le serveur distant chargé de vérifier ledit code, effectue une incrémentation du nombre d'essai erroné. De manière connue, ce comptage limite à trois essais erronés le nombre de possibilités. Si un essai est vérifié, alors le nombre d'essai possible revient à zéro et l'accès est autorisé, sinon le serveur bloque l'accès, incrémente le nombre de tentatives et demande un nouvel essai, puis, au bout de trois tentatives infructueuses, le serveur bloque l'accès et aucune tentative ultérieure ne pourra être réalisée. Toutefois, ce type de protocole pose des inconvénients. Dans le cas d'un serveur distant auquel est transmis le code personnel de l'utilisateur, ce code est comparé avec un code enregistré auprès du serveur. Il est alors possible pour un tiers de falsifier le serveur et de récupérer ledit code. C'est pourquoi, ce code est chiffré et généralement transmis au travers d'une connexion sécurisée. Toutefois, il existe une faille de sécurité si ledit tiers récupère le code chiffré et tente de le déchiffrer. De plus, si un tiers peut avoir accès audit serveur, il peut récupérer le code. L'invention a pour but de pallier les inconvénients de l'état de la technique en proposant une solution alternative d'authentification sécurisée d'un utilisateur, par l'intermédiaire d'un serveur distant, par saisie d'un mot de passe, afin d'accéder à des données contenu sur un support. En particulier, l'invention permet de vérifier un mot de passe sans que ce dernier soit connu ou transmis en tant que tel, à savoir dans une forme qui puisse être interceptée et déchiffrée par un tiers. Pour ce faire, la présente invention prévoit, dans un premier temps, au cours d'une étape d'initialisation, de créer une graine de chiffrement à partir en outre d'un mot de passe et d'un identifiant propre à un support, ladite graine étant traitée par un serveur distant. Le chiffrement des données contenues sur ledit support sont ensuite chiffrées en fonction de la graine obtenue. Ensuite, au cours d'une étape d'authentification, est envoyé audit serveur distant au moins l'identifiant dudit support accompagné d'une graine à traiter, cette graine contenant un mot de passe saisi par un utilisateur. Après vérification, ledit serveur traite alors cette graine et la renvoie pour permettre le déchiffrement des données. Si le déchiffrement est possible, alors c'est que le mot de passe saisi était valide. En particulier, la vérification consiste à comparer le nombre d'essai restant pour ledit support. Ainsi, l'invention permet de s'affranchir de la prise de connaissance du mot de passe au niveau dudit serveur, limitant les risques de sécurité y relatif. De plus, le traitement effectué étant obligatoire pour obtenir la graine de déchiffrement des données, il n'est donc 10 pas possible de se passer du serveur distant. D'autres caractéristiques et avantages de l'invention ressortiront de la description détaillée qui va suivre des modes de réalisation non limitatifs de l'invention, en référence aux figures annexées dans lesquelles : 15 - la figure 1 représente schématiquement l'étape d'initialisation ; et - la figure 2 représente schématiquement l'étape d'authentification. La présente invention concerne l'authentification 20 sécurisée d'un utilisateur 1 désireux d'accéder à des données chiffrées. En particulier, lesdites données 2 sont contenues sur un support 3, notamment enregistrées sur un support informatique portable équipé d'un espace mémoire adapté au stockage desdites 25 données 2. Un tel support 3 peut avantageusement se présenter sous la forme d'un CD-ROM ou DVD-ROM, ou bien d'un terminal portable, tel un périphérique de stockage ou un téléphone cellulaire. L'authentification dudit utilisateur 1 s'effectue par 30 connexion dudit support 3 à un serveur distant 4. Concrètement, ledit support 3 peut être combiné à un terminal relié audit serveur distant. Cette combinaison dépend du type de support et peut être, selon les cas, son insertion au sein d'un lecteur ou bien la connexion sur ledit terminal, notamment au travers 35 d'une connectique adaptée et normalisée, par exemple de type USB pour � Universal Serial Bus �. On notera que cette connexion peut aussi s'effectuer directement au travers d'un réseau de communication, filaire ou non, comme un réseau hertzien de communication. Un tel réseau est préférentiellement informatique, tel Internet. Dans un premier temps, comme représenté sur la figure 1, le procédé selon l'invention consiste à initialiser ledit support 3. Pour ce faire, au cours d'une étape d'initialisation, on crée une graine initiale 5 de chiffrement. Cette graine initiale 5 est créée au moins à partir d'un mot de passe 6 et d'un identifiant 7 propre audit support 3. D'autres données peuvent être prises en compte pour créer une telle graine initiale 5. Selon le mode préférentiel de réalisation, ledit mot de 15 passe 6 peut être court et constitué de quatre caractères numériques, tel un code PIN. De plus, ledit identifiant 7 permet de caractériser ledit support 3 de manière unique, tel un numéro de série. Par ailleurs, on transmet ladite graine initiale 5 audit 20 serveur 4 qui est chargé de la traiter, puis de la renvoyer. Dès réception, on chiffre 17 les données 2 contenues sur ledit support 3 en fonction de la graine traitée 8. Cette étape d'initialisation est implémentée afin de s'assurer de la sécurité des communications et des transferts 25 de données. De plus, un chiffrement supplémentaire des données transmises peut être effectué par l'intermédiaire d'un système de cryptographie à clef publique, en utilisant une clef symétrique partagée entre ledit support 3 et ledit serveur 4. 30 Une telle clef symétrique peut être du type AES pour � Advanced Encryption Standard � (ou standard de chiffrement avancé) d'une longueur de 256 bits. Dans un second temps, une fois l'initialisation du support 3 effectuée, l'utilisateur 1 désireux d'accéder aux 35 données chiffrées 9 et contenues sur le support 3 doit s'authentifier. Cette opération est représentée à la figure 2. Par conséquent, au cours d'une étape d'authentification, l'utilisateur 1 saisit un mot de passe 10. Ce dernier sert à créer une graine 11, avec notamment ledit identifiant 7 du support 3. Cette création s'effectue de la même manière qu'au cours de l'étape d'initialisation. Cette graine 11 est alors envoyée audit serveur 12 accompagnée d'au moins l'identifiant 7 dudit support 3. On notera qu'avec ledit identifiant 7 peut être transmis un numéro de session, tel un identifiant ou une clef de 10 session. Selon un mode préférentiel de réalisation, au moment de la transmission, le numéro de session sert au chiffrement dudit identifiant du support 7, tandis que ledit numéro de session est chiffré par la clé publique du certificat dudit serveur 12. 15 Dès lors, seul ledit serveur 12 en possession de son certificat peut déchiffrer le numéro de session puis l'identifiant 7 du support 3. Par le biais de cette signature électronique, le serveur 12 peut ainsi vérifier la validité de l'identifiant 7 du support 3. 20 Puis, après vérification, ledit serveur 12 traite ladite graine 11 et la renvoie. Le traitement est identique au traitement effectué à l'étape d'initialisation. Enfin, à partir de la graine traitée reçue 13 on tente le déchiffrement des données 9. S'il réussi, c'est que le mot de 25 passe 10 saisi par l'utilisateur 1 était valide. Sinon, le déchiffrement a échoué et l'utilisateur 1 doit saisir à nouveau un mot de passe. On notera que le déchiffrement 18 est permis par l'obtention d'une graine traitée 11 valide qui permet de 30 dériver la clef de chiffrement des données 9 contenues sur le support 3. Une autre graine servant pour la dérivée peut être le mot de passe 10, à savoir le code PIN. Plus particulièrement, ladite vérification peut consister à comparer le nombre d'essai restant par rapport à 35 l'identifiant 7 dudit support 3. En effet, le serveur 12 peut garder en sauvegarde toutes les tentatives erronées pour un support 3 donné, classées notamment par l'intermédiaire dudit identifiant 7 du support 3. Dès lors, ledit serveur 12 peut valider l'existence d'une entrée pour l'identifiant 7 d'un support 3. Selon le mode préférentiel de réalisation, le nombre de tentatives erronées maximum peut être de trois. A chaque nouvelle tentative, un compteur peut être incrémenté ou bien la graine transmise peut être sauvegardée. Dès dépassement, le serveur 12 peut renvoyer une fausse graine traitée 13, une action vers le terminal invalidant le support 3 ou simplement ne rien renvoyer du tout. Une tentative vérifiée permet d'effacer les lignes de graines ou de remettre ledit compteur à zéro. En particulier, une réponse de validation est renvoyée vers le serveur 12 en cas de succès du déchiffrement 18. Cette réponse peut contenir la clef et/ou le certificat du serveur d'initialisation 4. En effet, ces données ont été chiffrées au moment de l'initialisation et leur transmission prouve que le déchiffrement 18 a réussi, empêchant une attaque directe dans le programme en faisant des sauts dans le code. A ce titre, on notera que les serveurs d'initialisation 4 et d'authentification 12 peuvent être distincts et donc posséder deux certificats distincts. Toutefois, lesdits serveurs 4,12 partagent une même clef symétrique de chiffrement, en particulier une même clef symétrique de chiffrement AES-256. Avantageusement, chaque création, au moment de l'initialisation ou de l'authentification, peut consister à effectuer une fonction de hachage cryptographique 14 sur au moins ledit mot de passe 6 ou 10 et ledit identifiant 7, notamment la concaténation dudit mot de passe 6 ou 10 avec ledit identifiant 7, ou inversement. En particulier, ladite fonction de hachage peut être une fonction SHA pour � Secure Hash Algorithm � de 256 bits dont la graine est le condensat. En retour, la graine traitée 13 et les autres données transmises par le serveur 12 peuvent être chiffrées avec ladite clef de session, garantissant l'intégrité et la non-répudiation des informations et par conséquent la certitude d'échanger avec le bon serveur. De plus, le chiffrement 17 et le déchiffrement 18 peuvent s'effectuer à partir d'une clef générée 15 depuis la graine traitée 8 ou 13. En particulier, la clef générée 15 peut être une clef AES-256. Selon un mode optionnel de réalisation, au cours de l'authentification, cette génération peut être une auto-attaque en force brute dudit mot de passe 10, en particulier du code PIN à quatre caractères. En effet, une des graines, permettant de dériver la clé de chiffrement 15 des données chiffrées 9, peut être générée aléatoirement sur le serveur d'initialisation 4, et n'est donc connue de personne. Sa longueur peut être choisie en fonction du nombre souhaité de combinaisons. Par exemple, si cette graine fait 8 bits, on obtient 256 combinaisons. Ces 8 bits étant totalement inconnus au niveau du support 3, pour déchiffrer 18 les données chiffrées 9, il faut, non seulement prendre en compte le mot de passe 10, à savoir le code PIN, saisi par l'utilisateur 1, la graine traitée reçue 13, mais en plus il convient de tenter toutes les combinaisons sur 8 bits jusqu'à ce que la clé de chiffrement 15, qui est ainsi dérivée avec tous ces éléments, soit valide. Selon un mode particulier de réalisation, ledit serveur distant 12 est un serveur Web connecté à Internet. Dès lors, au moment de l'authentification, ledit support 3 doit contenir l'adresse distante dudit serveur 12, telle son URL pour � Uniform Resource Locator �. De plus, une connexion sécurisée peut être réalisée avec ce serveur, notamment au travers d'une connexion HTTPS pour � HyperText Transfert Protocol Secure �. Toutes les données requises peuvent être introduites au sein d'une application contenues sur ledit support 3 et exécutées à partir de celui-ci, notamment au cours de la combinaison avec un terminal. On notera que les étapes de traitement 16 de la graine initiale 5 ou 11 peuvent uniquement consister à la chiffrer à l'aide de la clef partagée par chaque serveur 4,12. Dès lors, la présente invention permet d'authentifier un utilisateur sans transmission en clair de son mot de passe, pour lui permettre d'accéder à des données chiffrées contenues sur un support. Bien entendu, l'invention n'est pas limitée aux exemples illustrés et décrits précédemment qui peuvent présenter des variantes et modifications sans pour autant sortir du cadre de l'invention. REVENDICATIONS1. Procédé d'authentification sécurisée pour autoriser l'accès aux données chiffrées contenues sur un support (3), 5 dans lequel, au cours d'une étape d'initialisation : - on crée une graine initiale (5) de chiffrement au moins à partir d'un mot de passe (6) et d'un identifiant (7) propre audit support (3) ; - on transmet ladite graine initiale (5) à un serveur (4) 10 qui la traite et la renvoie ; - on chiffre (17) les données (2) contenues sur ledit support (3) en fonction de la graine traitée (8) ; puis, au cours d'une étape d'authentification : - un utilisateur (1) saisit un mot de passe (10) 15 - on envoie audit serveur (12) au moins l'identifiant (7) dudit support (3) et accompagné une graine (11) créée à partir dudit mot de passe (10) et dudit identifiant (7) ; - après vérification, ledit serveur (12) traite ladite graine (11) et la renvoie ; 20 - on tente le déchiffrement (18) des données (9) à partir de la graine traitée reçue (13). 2. Procédé d'authentification selon la revendication 1, caractérisé en ce que chaque création consiste à effectuer une fonction (14) de hachage cryptographique au moins dudit mot de 25 passe (6 ou 10) et dudit identifiant (7). 3. Procédé d'authentification selon l'une quelconque des revendications 1 ou 2, caractérisé en ce que ladite vérification consiste à comparer le nombre d'essai restant par rapport à l'identifiant (7) dudit support (3). 30 4. Procédé d'authentification selon l'une quelconque des revendications précédentes, caractérisé en ce que le chiffrement et le déchiffrement s'effectuent à partir d'une clef (15) générée depuis la graine traitée (8 ou 13). 9