Le problème de l'authentification

Le problème de l'authentification a plusieurs aspects et il faut bien les distinguer, car quand on se trompe d'aspect, on peut s'ouvrir à des vulnérabilités structurelles indépendantes de la qualité ou la robustesse du protocole d'authentification utilisé.  En général, le problème de l'authentification consiste, de la part d'une entité, à obtenir une preuve convaincante de l'identité d'une autre entité avec laquelle on est en communication, ou l' appartenance de cette entité à un groupe identifié.   

Il faut donc distinguer différentes possibilités:

  1. La nature de l'entité qui doit être convaincue:
    1. Est-ce une personne physique ?
    2. Est-ce une organisation administrative (une personne morale) ?
    3. Est-ce un logiciel ?
    4. Est-ce un appareil ?
  2. La nature de l'entité qui doit convaincre de son identité:
    1. Est-ce une personne physique ?
    2. Est-ce une organisation administrative (une personne morale) ?
    3. Est-ce un logiciel ?
    4. Est-ce un appareil ?
  3. Le genre d'identité qu'il faut vérifier:
    1. Est-ce l'identité physique d'une personne ?
    2. Est-ce une identité virtuelle de la-dite personne (un "avatar") ?
    3. Est-ce un nom DNS ?
    4. Est-ce un compte e-mail ? Un numéro de téléphone ? Une adresse postale ?
    5. Est-ce une appartenance à un club, groupe, ... ?

On ne se pose que rarement ces questions, car dans la vie de tous les jours, nous n'avons qu'un seul problème d'identification: celle d'une personne physique.  On a affaire à Jean, et c'est tout.  Jean, c'est en même temps Jean l'employé de l'entreprise, la personne "Jean", le client "Jean", le mari Jean, le père Jean, le Français "Jean", le propriétaire Jean etc...  Quand on reconnaît le visage de Jean, sa voie, etc.... nous ne nous posons plus de questions sur toutes ces identités.  Mais dans le monde informatique, Jean peut avoir 10 comptes Facebook, où Jean a des amis différents.  Jean peut avoir 5 comptes e-mail, et 3 téléphones.  Alors, quand on vote, est-ce que Jean votera avec ces comptes Facebook, ces comptes e-mail, ou ces numéros de téléphone ?  Si Jean a perdu un de ces téléphones, comment on fait pour reconnaître "le vrai Jean", si ce téléphone avait aussi accès à tous les comptes Facebook et e-mail de Jean, et quelqu'un abuse de ce téléphone qu' il a trouvé ?

Quand nous sommes entrés en contact avec une "personne" sur un forum, et nous voulons échanger d'avantage avec cette "personne", comment faire ?  La seule chose qu'on connaît de cette personne, c'est son avatar sur un forum.  Comment faire pour lui donner accès à un autre site web ?  Faut-il une identité physique pour cela ? 

Quand nous contactons un site de e-commerce sur internet, et nous voulons passer une commande, il n'y a pas une " personne" de l'autre coté.   Vérifier l'identité physique de l'employé qui traite votre commande (vous ne connaissez pas les employés de cette entreprise, peut-être de l'autre coté du globe) ne vous aide en rien.  Vous voulez savoir si le site web, le compte bancaire, et l'adresse e-mail correspondent à cette entité dont vous avez eu connaissance d'une certaine façon (Google ? Publicité dans la boîte au lettres ?  E-mail publicitaire ?) avec qui vous entrez en relation commerciale.  Peut-être voulez-vous aussi savoir quelle personne morale pourra être poursuivie en justice si elle tente de vous arnaquer.

Quand vous utilisez un service cloud comme Dropbox ou Mega, ces services veulent savoir si vous êtes la même entité que la dernière fois, mais ces services ne veulent pas savoir si vous êtes une personne, une entreprise, ou un appareil.   Il faut juste que vous soyez la même entité qui a déposé des fichiers, et qui vient les chercher.

Par contre, si vous voulez aller sur le site web de l'entreprise Apple, vous voulez être sûr que le site que vous contactez, est bien le site de cette entreprise, connue des publicités, des journaux, de la bourse, du journal télévisé (même si vous ne connaissez pas "personnellement" cette entreprise) et des Apple-store.  Même si le site s'appelle apple.co, vous ne voulez pas vous connecter à un site dont le propriétaire est un individu relativement inconnu, habitant de Cote d'Ivoire.

Ces exemples essayent d'illustrer que pour chaque problème d'authentification, il faut bien se poser ces questions avant de pouvoir mettre en place un système d'authentification adéquat.

Souvent, nous utilisons des "proxy" pour l'authentification, et il faut alors faire très attention à ce qu'on fait.  On entend par "proxy" une substitution de l'entité qu'on veut réellement connaître par une autre entité plus commode à utiliser.  Par exemple, l'application peut avoir besoin de l'identité d'une personne physique, mais elle va utiliser en réalité son numéro de téléphone.  Le numéro de téléphone est alors le proxy de la personne physique.  Il faut alors bien se rendre compte que toute personne physique qui a réellement accès au numéro de téléphone de la personne, sera reconnue comme entité légitime, et quelque soit la robustesse de la procédure d'authentification, elle sera satisfaite, car l'entité à identifier (le numéro de téléphone) était bien la bonne.

Il faut aussi distinguer deux cas:

  1. Les deux entités sont des entités physiques et ils sont en proximité
  2. Tous les autres cas

Effectivement, le premier cas est celui de l'authentification humaine standard: les deux entités sont des personnes physiques, et elles sont en proximité: on se reconnaît visuellement et autrement comme personne.  C'est relativement difficile de tromper cette forme d'authentification quand les deux personnes se connaissent bien.  Nous projetons souvent une procédure d'authentification sur ce cas précis.

On peut élargir ce premier cas au cas où une des entités est un appareil physique.  Dans le cas où un appareil physique doit identifier une personne humaine, on peut passer à la biométrie poussée: reconnaissance d'empreinte digitale, d'iris, de visage, ....  Il faut bien se rendre compte que ce genre d'identification, qui est une imitation du contact humain direct, n'a de sens que quand l'appareil à convaincre est en contact direct avec l'humain à reconnaître.  Pour un appareil à distance, l'information biométrique à envoyer n'est alors qu'une "clé", dont il est difficile de garder le secret, puisque ce "secret" est votre corps !  A distance, on ne peut pas distinguer un appareil qui fait une réelle mesure biométrique, d'un appareil qui envoie le fichier avec ces informations dedans.

Dans tous les autres cas, nous avons à faire à l'échange de données qui doit convaincre l'entité que l'autre entité est bien la bonne.  Ceci est quelque chose dont nous n'avons pas l'habitude dans la vie courante, sauf peut-être par un lien téléphonique, où on essaie de reconnaître la voix de l'autre personne: on connaît bien les canulars faits aux figures publiques (comme politiciens, ...) qui se font avoir par ce biais.

Finalement, dans le cadre limité de la cyber-sécurité, il faut se rendre compte que les seules formes d'authentification que nous pouvons considérer, sont des corrélations entre contacts avec des entités.  Nous ne pouvons pas faire l'identification absolue d'une entité, et pour quasi toutes les applications, cela ne sert d'ailleurs à rien.

En d'autres termes, les applications d'authentification que nous considérons, sont essentiellement du type: "l'entité avec qui je suis en contact maintenant, est bien la même entité avec laquelle j'étais en contact dans le passé".

Cependant, il faut bien se garder de confondre ceci, avec un autre problème d'authentification, qui est beaucoup plus difficile à résoudre: "l'entité avec qui je suis en contact maintenant, est bien une autre entité que celle avec qui j'étais en contact dans le passé".  Ce problème-là est bien plus épineux, mais nous pouvons le rencontrer dans des questions de vote, de distribution, ...

La raison pour laquelle la corrélation (ou la non-corrélation, comme ci-dessus) est l'essentiel du problème d'authentification, est que nos interactions avec ces entités sont souvent indépendants de l'identité absolue.   Dans une relation commerciale, si le client qui se nomme Jean, s'appelle en réalité Pierre, nous paie, achète un article, nous donne une adresse pour envoyer l'article, cela ne pose aucun problème qu'on l'identifie tout le temps comme "Jean".  Nous recevons l'argent de "Jean", nous envoyons un article à l'adresse de "Jean", nous rédigeons une facture au nom de Jean et c'est tout.  Si un nouvel employé d'une entreprise se fait appeler Jean, même s'il s'appelle Pierre, et on lui fait un compte dans le système informatique sous le nom "Jean", et il travaille chez nous pendant 10 ans, ce qui compte, c'est que c'est "Jean" qui peut se connecter à nos ordinateurs pour faire son travail.  Qu'en réalité, il s'appelle Pierre, on s'en fiche un peu.  Ce n'est que sur le plan de l'état civil, et pour la justice et les administrations légales que "Jean" peut avoir un souci, mais pour la cyber-sécurité, cela ne change rien.

Ceci est encore beaucoup plus évident si on considère des entités anonymes.  On peut se poser la question dans quelle mesure "l'authentification d'entités anonymes" pourrait avoir un sens, mais c'est exactement là qu'on voit que l'authentification qui compte, c'est la corrélation entre deux contacts.  Quand on parle d'entités anonymes, on pense peut-être à des actions illégales ou criminelles, comme des marchés de drogue ou d'armes sur le dark net, mais il y a beaucoup d'applications légitimes d'identités anonymes.  La correction de copies à des examens peut se passer avec des identités anonymes, par exemple.  L'interview de candidats à l'embauche, pour éviter toute forme de favoritisme ou de discrimination autre que les critères de sélection, en est une autre application.  Supposons qu'on veuille donner une aide psychologique à des gens dépressifs, suicidaires ou d'une autre façon en détresse.  Pour franchir la barrière de l'accès, on peut proposer un service anonyme: on peut proposer une aide régulière à la personne à distance, sans connaître l'identité de la personne.  Mais il faut quand-même s'assurer que pendant les différentes séances, on est bien en contact avec la même personne, car on va évoquer des éléments confidentiels d'une séance à l'autre.   Un autre exemple est la vente d'articles érotiques.  Souvent, les acheteurs ne veulent pas que leur identité réelle soit connue.  Mais il faut bien faire le lien entre l'acte d'acheter, l'acte de payer, l'acte d'envoyer ou de donner l'objet en question et le service après-vente.  L'identité absolue du client n'est pas connue, mais la corrélation entre les différents contacts doit être assurée.

Ainsi, dans une authentification relative, nous avons 2 étapes:

  1. La prise d'identité
  2. La preuve de même identité

Pendant la première phase, la nouvelle entité reçoit, ou donne, les "identifiants", c.a.d. les éléments qui vont prouver/vérifier son identité.  Pendant la deuxième phase, les identifiants sont vérifiés.  Ainsi, cette vérification établit la corrélation entre cette première phase, et toutes les phases de vérification.  La première phase est vulnérable à une attaque de l'Homme Du Milieu si elle doit se faire à distance.

Authentifier une personne physique, physiquement présent

Bien que nous avons souligné que le problème de l'authentification ne se limite pas à celle d'une personne, il faut reconnaître que dans beaucoup d'applications, c'est bien une personne physique qu'on veut identifier.  Comme nous nous intéressons surtout à l'authentification relative, la question que notre application veut poser, est: "est-ce que la personne avec laquelle je suis en contact maintenant, est la même personne que nous avons identifié comme X ?"

Comme nous avons déjà mentionné, cette authentification par un autre être humain date de la nuit des temps: un humain "reconnaît" facilement un autre humain qu'il a déjà rencontré: son visage, sa voie, sa façon de faire et de parler.... font une reconnaissance presque sans faille.   Mais pour que cela fonctionne, il faut que l'entité à convaincre soit un autre humain, et que l'entité à identifier soit présente physiquement.

Il peut sembler étrange, mais cette forme d'authentification reste importante en cyber-sécurité: les locaux qui contiennent du matériel informatique sensible (salle des serveurs...) peuvent être gardés par des gardiens humains, qui laissent entrer seulement certaines personnes qu'ils connaissent bien!  La "prise d'identité" est alors une chaîne de confiance pour les gardiens, dont l'ancre de confiance est établie au moment de leur embauche, quand on leur à expliqué qui est le patron de la boîte, qui est le responsable informatique, etc.... En dernier recours, ils iront voir le patron pour demander si une nouvelle personne a bien le droit d'accès à la salle informatique.  Il ne faut pas négliger cette protection physique par des barrières physiques, ouvrable seulement par des gardiens humains: relativement peu de matériel informatique résiste, en effet, à l'infraction locale et physique.  Les appareils dans une salle de serveurs ne sont pas conçus pour résister à une intrusion physique pendant leur fonctionnement.

Quand, cependant, c'est une entité technique (un appareil, un logiciel...) qui doit identifier une personne physique, la seule forme de reconnaissance qui imite la reconnaissance humaine, est la biométrie, par un appareil qui fait confiance à l'intégrité des capteurs biométriques qui font la biométrie sur le corps de la personne en question Il faut faire attention que les capteurs biométriques puissent être assez sophistiqués pour ne pas se laisser berner par des pauvres imitations biométriques, comme des photos.  A part la biométrie directe, toutes les autres méthodes d'identification d'une personne ne nécessitent pas la présence physique de la personne à proximité, car il s'agit de transmettre des informations.  Bien sûr, on peut exiger que l'information d'authentification soit entrée sur un terminal local, mais cela n'a rien à voir avec l'authentification en soi.  Il peut être judicieux de permettre certaines opérations délicates seulement "en local".  C'est une mesure de sécurité supplémentaire, qu'il faut considérer si le prix à payer, à savoir, ne pas pouvoir faire cette intervention à distance, est acceptable.

Authentification à distance: généralités

Dans tous les cas distinct de la présence physique d'une personne physique, l'authentification passe par la transmission d'une information que seul l'entité à identifier peut fournir, et que l'entité à convaincre peut vérifier.  
Il faut donc se rendre à l'évidence, que par principe, on ne peut pas authentifier directement une personne physique à distance, car la seule façon directe de distinguer une personne physique d'une autre, est l'authentification de son corps (par biométrie).  Il faut utiliser un, ou des proxies, qui sont des sources d'information, et qui remplacent la personne physique.  Ces proxies tombent dans des catégories différentes:

  1. la connaissance ou l'accès à la connaissance d'un secret (clé, mot de passe....) qui permet de produire l'information en question
  2. le contrôle physique d'un appareil (un téléphone, un dongle...) qui est source d'informations
  3. une autre authentification, qui permet d'obtenir des informations (un compte Facebook, un compte e-mail....)

Chaque proxy est appelé un "facteur" et pour plus de sécurité, on peut utiliser une authentification à plusieurs facteurs, c.a.d. il faut simultanément convaincre l'entité à convaincre par plusieurs épreuves: un mot de passe, un message SMS, un e-mail de confirmation....  Cependant, souvent, cette identification à plusieurs facteurs est illusoire, car les facteurs sont corrélés ; alors, cette identification à plusieurs facteurs donne un faux sens de sécurité.  Nous y reviendrons.

Il faut donc se rendre compte qu'une identification à distance identifie une autre entité qu'une personne physique, et la procédure d'authentification sera acceptée si cette entité est la bonne, ce qui est indépendant de la question si c'est la bonne personne qui contrôle cette entité.  Si l'authentification passe par la possession d'un téléphone, et que le bon téléphone est dans les mains de la mauvaise personne, on ne peut pas reprocher cela à la procédure d'authentification: elle à bien authentifié le bon téléphone !

S'il y a quelque chose à retenir du problème d'authentification, c'est bien ceci: il faut distinguer la robustesse de l'identification d'entités, et la pertinence du choix des proxies.  Une authentification robuste fera en sorte que les proxies sont les bonnes ; mais seulement la pertinence des choix des proxies peut assurer que ces proxies correspondent à la bonne entité (une personne physique par exemple) qu'on voulait réellement identifier.

On peut comparer cela à la distinction entre la qualité d'une serrure, et la question si la bonne personne possède la clé.  Une serrure de bonne qualité s'ouvre seulement si on met la bonne clé dedans.  Une serrure de mauvaise qualité se laisse aussi ouvrir avec un tournevis.  Mais on ne peut pas reprocher à une serrure de s'ouvrir avec la bonne clé, si cette clé est dans les mains de la mauvaise personne !  Si vous avez acheté une serrure de très bonne qualité, mais vous laissez la clé sous le paillasson, votre stratégie de proxy est mauvaise, et ce n'est pas la faute de la serrure.

Ainsi, une règle d'or est: comme l'authentification à distance est toujours plus fragile que l'authentification physique locale, car l'authentification à distance doit toujours passer par des proxies, ouvrez à l'authentification à distance seulement ce qui est réellement nécessaire et gardez, si possible, pour les choses très sensibles, l'authentification locale où "l'effet gardien" peut jouer.

Il peut ainsi être utile de réduire les permissions quand les employés travaillent à distance, surtout pour les utilisateurs qui ont beaucoup de permissions, dans la mesure où c'est possible et n'interfère pas avec le travail à faire.  Si un utilisateur a des droits d'administrateur, il peut être judicieux de ne pas accorder ces droits s'il est à distance.  Cela ne lui permet pas d'installer des logiciels de chez lui, mais il peut travailler normalement.  La maintenance de sa machine, il le fera quand il sera au bureau.

Certaines procédures d'identification peuvent se faire sans lien crypté, mais il est quand-même préférable d'utiliser un lien crypté dont on s'assure que seulement les deux parties identifiées possèdent la bonne clé.  Ceci est évidemment vrai pour toute interaction identifiée "après authentification", car sinon, une attaque de l'Homme Du Milieu est possible.  Si vous vous authentifiez sur un lien en clair correctement sur un serveur pour avoir la permission de donner des instructions à ce serveur, un attaquant peut en suite se substituer à vous pour donner les instructions qu'il voudra, si ce lien n'est pas crypté.  Les applications où on s'authentifie, sans suite dans la communication, sont rares.  Le chiffrement du lien ne sert qu'auxiliairement pour garder la communication confidentielle: elle sert surtout à faire en sorte que la communication ne soit pas altérée.

Comme nous avons vu, dans l'authentification, il y a deux aspects: la première mise en place de l'identité, et en suite, la vérification de l'identité.  Il faut se rendre compte que la mise en place de l'identité à distance est encore plus délicate que le contrôle de cette identité si elle était mise en place "localement et en personne".  Il faut donc, dans la mesure du possible, toujours préférer la première mise en place d'identité localement et en présence physique à la première mise en place à distance.  Ceci est particulièrement applicable au personnel d'une entreprise.
Ce n'est que dans le cas où le premier contact se fait déjà à distance, qu'on n'a pas le choix que d'avoir une première identification à distance.  C'est le cas pour tous les services "cloud" et "compte réseau sociaux".  Dans ce cas, il faut se rendre compte de la fragilité potentielle de cette identité, surtout quand on peut être victime d'une attaque de l'Homme Du Milieu.

Mots de passe

Une façon classique de prouver qu'on est la même entité que lorsqu'on s'est identifié, consiste à se mettre d'accord sur un secret au moment de l'identification initiale, et d'envoyer ce secret quand on veut se ré-identifier.  Si ce secret peut être mémorisé par un être humain, alors à première vue, on n'a même pas besoin d'un proxy: la seule entité au monde à pouvoir produire cette information, est cet être humain.  C'est pour cela que le mot de passe est toujours un outil souvent utilisé pour identifier un humain à distance.

Les inconvénients du mot de passe sont cependant nombreux:

  1. un être humain a du mal à retenir plusieurs mots de passe à grande entropie.  Ceci rend la technique vulnérable intrinsèquement.
  2. le mot de passe doit être saisi, être envoyé, et être donné en clair à un appareil qui pourrait le copier, le stocker. 
  3. le mot de passe peut facilement être donné volontairement à une autre entité (un script, une autre personne, ....).  C'est ainsi qu'un mot de passe est quand-même un proxy: l'entité qui "connaît" le mot de passe n'est pas nécessairement vraiment l'humain (contrairement à un test biométrique, qui ne peut pas être transmis à quelqu'un d'autre). 
  4. l'entité qui doit être convaincue, peut aussi bien se faire passer pour vous car elle reçoit le mot de passe.

Ces inconvénients font que l'utilisation à distance d'un mot de passe est à éviter comme seul moyen d'identification ; par contre, un mot de passe est souvent, avec une identification biométrique, la seule façon, pour un être humain, de se faire connaître localement par un appareil (son ordinateur portable, son téléphone....).

Du fait qu'un mot de passe est "fragile" car c'est un secret, l'entité qui doit vérifier un mot de passe a intérêt de ne stocker qu'un hachage du mot de passe, et non pas sa valeur en clair.  Ainsi, quand l'entité qui doit vérifier le mot de passe est elle-même compromise, le mot de passe en soi n'est pas disponible pour le voleur.  Pour vérifier le mot de passe, il suffit de recevoir le mot de passe et de le passer dans la fonction de hachage, et de vérifier si le résultat correspond au hachage stocké pour cet utilisateur.  Si c'est le cas, alors le mot de passe était le bon.

Clé symétrique

D'une certaine façon, une clé symétrique est la même chose qu'un mot de passe: c'est un secret qu'on à partagé au moment de l'identification initiale, qui servira à prouver qu'on est bien la même entité ultérieurement.   Mais, contrairement à un mot de passe, une clé symétrique est souvent trop compliquée pour être mémorisée par un humain (c'est essentiellement un très grand nombre aléatoire), et surtout, la clé n'est pas transmise en direct comme preuve.

Une clé symétrique est utilisée dans un dialogue pour prouver aux deux entités qu'ils sont bien les bonnes.  L'entité 1 prouve à l'entité 2 qu'il possède la clé, et l'entité 2 prouve à l'entité 1 qu'il a aussi la clé, sans que l'un puisse apprendre la clé de l'autre si jamais il ne la connaissait pas.  Ce dialogue va ainsi, quand on suppose que S est la clé symétrique que les deux entités sont supposé connaître:

  1. L'entité 1 choisit un nombre aléatoire R1 et envoie cette valeur à l'entité 2.
  2. L'entité 2 choisit un nombre aléatoire R2 différent de R1, et envoie cette valeur à l'entité 1.
  3. L'entité 2 calcule: P1 = hachage(S + R1) et P2 = hachage(S + R2)
  4. L'entité 1 calcule: P1' = hachage(S + R1) et P2' = hachage (S + R2)
  5. L'entité 2 envoie P1 à l'entité 1
  6. L'entité 1 envoie P2' à l'entité 2
  7. L'entité 1 compare P1 avec P1'.  Si c'est identique, c'est que l'entité 2 connaît S.
  8. L'entité 2 compare P2' avec P2.  Si c'est identique, c'est que l'entité 1 connaît S.

Ainsi, l'entité 1 a prouvé à l'entité 2 qu'il connaissait S, sans donner S, et vice versa.

Comparé au mot de passe, une clé symétrique a les avantages suivants:

  1. la clé possède beaucoup plus d'entropie
  2. la communication ne doit pas être confidentielle, il n'y a pas d'information confidentielle pendant la communication d'authentification
  3. si jamais on s'est connecté à une mauvaise entité, ce n'est pas grave, on ne divulgue pas son mot de passe
  4. les deux entités sont convaincues qu'elles ont les bonnes partenaires

Le grand désavantage de la clé symétrique comparé au mot de passe, cependant, est:

  1. comme cette clé n'est pas retenue par un humain, et que les opérations dessus ne sont pas faits par un humain, on ne peut qu'identifier un proxy avec cette technique: le logiciel, ou l'appareil, qui contient la clé.

La clé symétrique garde les propriétés du mot de passe, que l'entité 1 ou l'entité 2 peuvent passer cette clé à d'autres entités qui peuvent alors se faire passer pour l'entité 1 ou 2.  Cette fois, l'entité 1 doit aussi garder la clé en clair, et ne pas juste stocker un hachage de cette clé.  Ainsi, quand l'entité 1 est compromise, la clé même peut être compromise. 

Un problème potentiel avec la technique de la clé symétrique est qu'il faut donner cette clé à toute entité technique qu'on utilisera pour s'authentifier.  Si on utilise un ordinateur portable, un téléphone, deux ordinateurs fixes etc.... il faut que toutes ces entités possèdent, à un certain moment, la clé si on veut s'authentifier à travers ces appareils.  Ceci devient problématique, car cela veut dire que toutes ces entités ont la capacité de se faire passer pour vous: elles deviennent toutes un proxy valable, car elles connaissent toutes, la clé, ce qui était le proxy utilisé.  Dans le fond, ce n'est pas différent pour un mot de passe: si vous vous authentifiez avec un ordinateur portable, un téléphone, et deux ordinateurs fixes, à un certain moment, vous avez donné votre mot de passe à cet appareil, qui s'est chargé de l'envoyer à l'entité qui voulait contrôler votre identité, donc ces appareils auraient pu enregistrer votre mot de passe s'ils voulaient.  Seulement, dans un fonctionnement normal (donc avec un appareil qui n'est pas totalement compromis), l'interface qui vous permet de taper votre mot de passe n'est pas sensé de mémoriser votre mot de passe, tandis que la clé symétrique doit bien être installée sur l'appareil pour pouvoir faire le dialogue.  Ceci dit, il est peut-être justement bien de ne pas compter sur le fait qu'un appareil agisse "normalement" concernant un mot de passe.  Si vous hésitez à installer une clé symétrique sur un appareil, peut-être que vous devriez alors aussi hésiter à tape votre mot de passe sur la même machine ! Ce qui semble donc à priori à une vulnérabilité de la clé (il faut l'installer sur des machines dans lesquelles on n'a pas confiance) peut finalement être seulement une explicitation d'un risque inhérent que vous alliez ignorer si vous alliez taper votre mot de passe sur la même machine !

C'est ainsi que la clé symétrique permet, en fait, d'utiliser des machines peu sûrs pour vous identifier sans risque: vous pouvez garder votre clé sur un appareil sûr.  Alors vous n'avez qu'a transmettre les valeurs de R1, R2, P1 et P2 (avec un code QR par exemple) de l'appareil sûr vers l'appareil peu sûr et vice versa.   L'appareil peu sûr est alors seulement un appareil de communication, qui ne doit pas connaître votre clé.  Il est même possible d'utiliser un appareil spécifique dont il est difficile d'extraire la clé, mais qui peut faire l'interface pour transmettre les valeurs de R1, R2, P1 et P2.  En verrouillant la clé dans un petit appareil, on s'assure en plus que cette clé ne puisse pas (facilement) être transmise: le proxy est maintenant "celui qui a le contrôle sur le petit appareil".

Le mot de passe à usage unique

Le mot de passe à usage unique est une simplification de l'utilisation de la clé unique.  C'est une technique qui est souvent utilisée en combinaison avec un petit appareil (ou une imitation sur téléphone portable, comme "Google authenticator").   La base reste une clé symétrique qui a été convenue au moment de la première authentification.

Cette fois, la preuve d'identité n'est pas faite dans les deux sens.  L'unité 2 veut convaincre l'unité 1, mais l'unité 1 n'essaie pas de convaincre l'unité 2.

Alors, le protocole se simplifie:

  1. L'unité 1 envoie un "challenge" (un nombre) à l'unité 2: la valeur R1.
  2. L'unité 1 calcule P1 = hachage(S + R1)
  3. L'unité 2 calcule P1' = hachage(S + R1)
  4. L'unité 2 envoie P1' à l'unité 1
  5. L'unité 1 vérifie que P1 est bien égal à P1': alors l'unité 1 est convaincue que c'est le bon interlocuteur

Certaines banques utilisent cette méthode.  Vous avez une application, ou un appareil de la banque, qui contient la clé S.  Quand vous vous connectez à leur site, ils vous demandent de taper un numéro qui s'affiche sur leur site, dans l'application sur votre téléphone.  Quand vous faites cela, cette application va vous calculer un autre numéro, que vous êtes sensés taper comme réponse sur le site.

On appelle cette réponse parfois un "mot de passe à usage unique".

On peut encore simplifier d'avantage cette technique, en remplaçant le challenge aléatoire par:

  1. l'heure actuelle (en "unités" de 30 secondes pour permettre un peu de marge dans les horloges)
  2. un compteur

Alors, il n'est même plus nécessaire que l'unité 1 vous envoie quelque chose.  A chaque moment, l'unité 1 et l'unité 2 peuvent savoir quelle est le nombre T de fois que 30 secondes sont passées depuis le 1 janvier 1970 à minuit.  Ce nombre T remplace R1 dans le challenge.  Pendant 30 secondes, le "mot de passe" valable est donc P1 = hachage(S + T). 

Au lieu d'utiliser le temps comme challenge, on peut aussi bêtement utiliser un compteur, qui compte le nombre de fois que vous avez déjà utilisé avec succès, l'authentification.  On appelle ce nombre, N.  La première fois que vous vous identifiez, N = 0, et le mot de passe sera alors: hachage(S + 0).  Unité 1 et unité 2 savent maintenant que N = 1.  La prochaine fois que vous voulez vous identifier, il faudra utiliser comme mot de passe: hachage(S+1).  Ensuite, il faudra utiliser hachage(S + 2).  Etc...

L'avantage de cette dernière technique est qu'elle évite les 30 secondes de vulnérabilité de la méthode quand on utilise le temps ; mais cela est facile à éviter aussi, en ne permettant qu'une seule authentification tous les 30 secondes.

Ces deux techniques sont celles utilisés dans Google Authenticator.

Clé asymétrique

Chaque entité génère une paire de clés publique/privée et garde toujours la clé secrète pour elle.  Pendant une première identification, l'entité qui doit être convaincue, reçoit la clé publique de l'entité qui doit convaincre.  Ceci peut se faire dans les deux sens, mais strictement parlé, il faut juste que l'unité à convaincre ait la possession de la clé publique et ait la certitude que c'est la clé publique de l'entité qui veut pouvoir s'identifier plus tard.  Il faut s'assurer que lors de cet échange, le canal de communication n'est pas victime d'une attaque de l'Homme Du Milieu, mais cela est vrai pour toute première identification.  Ultérieurement, l'entité qui veut s'authentifier peut le faire facilement, en signant, avec sa clé privé, tout défi envoyé par l'unité qui doit être convaincue. 

L'avantage de la clé asymétrique sur une clé symétrique est qu'on peut utiliser la même paire de clés pour plusieurs identifications avec plusieurs entités différentes: l'unité à convaincre ne peut pas se faire passer pour vous.  Dans le cas où vous avez à faire à seulement une entité que vous voulez convaincre, cela ne joue aucun rôle.  Si vous partagez une clé symétrique avec seulement une autre entité, c'est vrai que cette entité peut se faire passer pour vous.... vis-à-vis de vous, et c'est tout.  Mais si vous partagez la même clé symétrique avec une dizaine d'entités (des systèmes informatiques au travail par exemple), alors une de ces entités peut se faire passer pour vous vis-à-vis une des autres entités.   Pour éviter cela, il faudrait que vous échangiez des clés symétriques différentes avec chacune de ces entités.  Une clé symétrique ne doit pas être utilisé entre plus que deux entités si on veut éviter la substitution possible d'identités.  Ce problème ne se pose pas avec une clé asymétrique.  Toutes les entités à qui vous donnez votre clé publique peuvent vérifier votre identité (et peuvent aussi, entre eux, se rendre compte que vous êtes la même entité) ; mais aucune ne peut se faire passer pour vous: pour cela, il faut être en possession de la clé privée, que vous ne divulguez jamais.

L'authentification par cette manière est utilisée dans le protocole d'authentification SSH.  Cette technique est particulièrement adaptée au problème où les entités qui doivent s'authentifier, sont des machines ou même, des procès.  Par exemple, on peut avoir un ordinateur A qui fait gérer sa sauvegarde par un autre ordinateur B.   Il est alors nécessaire que le processus de sauvegarde qui tourne sur l'ordinateur A puisse se faire reconnaître par l'ordinateur B.  On génère alors une pair de clés public/privé dits "ssh" sur l'ordinateur A.   On va copier la clé publique sur l'ordinateur B, en indiquant que c'est la clé de A.  On donne accès à la clé privée, enregistré sur A, au processus de sauvegarde.  Quand ce processus veut envoyer des données à sauvegarder, alors ce processus peut s'identifier auprès de l'ordinateur B comme étant A.  Un défi de la part de B peut être relevé par A en utilisant la clé privé sur A, et B peut vérifier cela avec la clé publique de B.  Le service cloud github.com fonctionne de cette manière.  On peut installer une clé publique sur un projet sur son compte github.  Le client local "git" peut alors utiliser la clé privée pour sauvegarder des nouvelles versions d'un jeu de documents qu'on veut enregistrer dans ce projet.  Si on veut avoir accès au même projet à partir de plusieurs ordinateurs, la pratique n'est pas d'aller transporter la clé privé d'un ordinateur vers l'autre ; c'est plutôt qu'on génère une autre pair de clés sur l'autre ordinateur, et qu'on installe cette deuxième clé publique aussi dans le projet sur github.com: nous voyons ici que l'entité qui est authentifiée, n'est pas un utilisateur (humain), mais une machine.  Si, comme utilisateur unique, on travaille sur 10 machines, alors chaque machine aura sa propre pair de clés publique/privée, et github.com aura 10 identités de 10 machines attachées à votre projet.

L'utilisation d'une authentification de machine, avant d'authentifier l'utilisateur, peut aussi être un facteur qui renforce la sécurité.   Dans le cadre d'une entreprise avec des employés qui s'identifient à distance, on peut leur demander d'authentifier d'abord toutes les machines à partir desquelles ils pourraient éventuellement se connecter (par exemple, leur ordinateur portable, leur téléphone etc...) avec un système comme SSH.  Les clés publiques de ces appareils seront alors enregistrés sur les serveurs de l'entreprise, leur permettant d'établir une connexion, avant même de vouloir identifier l'employé même.  Ainsi, il faut que la connexion se fasse à partir d'un appareil qui possède déjà une bonne clé, ce qui est déjà une première protection contre toute tentative d'intrusion. 

Mot de passe, le retour

Autant que l'authentification classique par mot de passe est une technique peu sûre, le mot de passe, mémorisé par l'humain, a cependant un atout que les autres systèmes à distance n'ont pas: a priori, seulement l'humain peut produire ce mot de passe.   Les deux grands défauts du "mot de passe mémorisé par l'humain" sont:

  1. peu d'entropie
  2. l'humain ne peut pas faire des calculs sur son mot de passe, il peut seulement le reproduire

mais on a construit des systèmes qui combinent l'avantage du mot de passe (mémorisé par l'humain, donc pas enregistré par un proxy) avec les avantages de systèmes à clé (beaucoup d'entropie, peut être utilisé dans un système cryptographique sophistiqué).   Il y a des protocoles sophistiqués sur le plan cryptographique pour combiner le mot de passe avec une clé en protégeant au maximum, la faible entropie du mot de passe (en réduisant l'attaque brute force au minimum avec seulement un essai possible par tentative de connexion).

Une façon classique est de chiffrer la clé stockée avec un mot de passe sur un appareil sûr.  Dans la mesure où l'appareil est sûr, il ne stockera jamais le mot de passe, mais il l'utilisera "en volée" pour déchiffrer la clé en mémoire, afin de l'utiliser.  Dès que la clé n'est plus nécessaire, sa forme en clair en mémoire est effacée et seulement sa forme chiffrée est présent sur disque.  Le mot de passe n'est jamais enregistré: il existe juste le temps nécessaire pour fabriquer la clé en clair.  Ceci est le fonctionnement supposé d'un appareil sûr, qui protège ainsi l'utilisation de la clé secrète en absence de l'humain qui connaît le mot de passe.  Le proxy est donc bien l'appareil sûr, mais il peut seulement être utilisé s'il obtient aussi le mot de passe.  Même si ce mot de passe est faible, quelqu'un qui met la main sur l'appareil peut seulement faire un seul essai de mot de passe par utilisation de la clé déchiffrée.  Il ne peut pas hors ligne, essayer plusieurs mots de passe pour "voir laquelle fonctionne", car tout mot de passe va donner lieu à une clé "déchiffrée", qui peut être la bonne, ou pas.  Dans la mesure où l'appareil n'est pas sûr, et peut être compromis, il peut bien sûr enregistrer le mot de passe et alors, la protection est partie.

Conclusion

Dans le cadre d'une gestion de la cyber-sécurité, la question de l'authentification est primordiale, et il faut analyser la situation au cas par cas pour choisir la meilleure politique d'authentification possible, en tenant compte des nécessités d'usage, des risques et des besoins.  Dans la mesure du possible, il faut bien sûr se replier sur des standards existants, mais il existe beaucoup plus de possibilités que le simple mot de passe.  Le choix judicieux de la bonne politique d'authentification est un des piliers d'une bonne gestion du risque sécuritaire.  On peut presque dire que sans bonne gestion des authentifications, le reste de la politique de sécurité perd un peu son sens.