Elaboration d’un modèle d’identité numérique adapté à la convergence

La problématique de la conception d’un modèle d’identité numérique répondant à des exigences de sécurité permettant de protéger les utilisateurs contre l’usurpation d’identité est très étroitement liée avec celle de l’assurance d’une authentification forte. Cela implique que la définition d’un modèle d’identité numérique n’a de sens que lorsque l’on envisage la compatibilité de ce dernier avec des protocoles d’authentification. De fait, un modèle d’identité tend à s’exprimer en termes de format, tel qu’un certificat X509[11] ou un couple « identifiant / mot de passe », mais en réalité, ce format comporte, en soi, une orientation qui lui permet d’être compatible avec tel protocole, et non avec tel autre. Ainsi, un certificat X509 ne pourra jamais être utilisé dans une authentification n’impliquant pas le protocole TLS[9]. La conséquence directe de cette observation triviale s’exprime par le fait que les failles de sécurité observables dans la gestion de l’identité numérique sont parfois davantage liées au format de l’identité numérique qu’au protocole d’authentification déployé.

En effet, à l’heure actuelle, la faiblesse la plus importante, et la plus évidente également, de l’identité numérique, est celle de la faiblesse des contraintes imposées aux modèles en vogue. Ainsi, le modèle le plus simple, celui de type «identifiant / mot de passe », où chacun des deux éléments est saisi au clavier par l’utilisateur, est soumis par nature à de nombreuses attaques indépendantes des protocoles mis en place pour l’authentification proprement dite.

Comme évoqué précédemment, le modèle « identifiant / mot de passe » reste le format d’identité numérique le plus répandu, à l’heure actuelle, parmi les utilisateurs. Dans le contexte de la convergence des flux de données à travers des services, potentiellement payant, de voix ou de vidéo à la demande, mais aussi au cœur de la mouvance de la dématérialisation des biens, l’identité numérique de l’utilisateur reste réduite à son plus simple appareil lorsque l’usurpation de celle-ci peut conduire à de nombreux déboires – fuite d’informations privées sensibles, achats frauduleux, etc. Les grands acteurs de l’Internet, tels que Facebook, Google (et ses déclinaisons), Amazon, mais aussi les banques, ont en commun de privilégier ce format d’identité numérique, et de ne pas vouloir en bouger.

Le protocole d’authentification dans ce cas est extrêmement simple : il s’agit d’une simple requête HTTP, en général non chiffrée, à partir de laquelle le serveur distant vérifie simplement que les données fournies coïncident avec celles enregistrées dans sa base de données. A l’issue de cette vérification, si l’authentification est réussie, un cookie de session est transmis à l’utilisateur afin de « certifier » le statut authentifié de ce dernier. Dans le cas, assez répandu, où le protocole HTTP[3] n’est pas protégé par une préalable authentification TLS à sens unique de la part du serveur, les possibilités d’attaque sont nombreuses. Espionner l’échange suffit ainsi à récupérer les données, ce qui est extrêmement facile à réaliser dans les espaces publics de réseaux sans fil non protégés (ou protégés avec le protocole WEP[21], dont les failles sont désormais bien connues[22]).

Une première contre-mesure, évidente, est la mise en place obligatoire du protocole TLS sur toute session HTTP réalisée sur le serveur . Cela n’a aucune incidence sur l’interface utilisateur, et permet à la fois de certifier l’identité du serveur auprès de l’utilisateur, et de chiffrer les données transmises postérieurement à l’établissement de la session – au prix, toutefois, d’un surcoût pour le serveur en termes de volumes de données échangées et de temps de calcul. Cette contre-mesure, qui ne procure que des avantages d’un point de vue sécuritaire et sans inconvénient vis-à-vis de l’utilisateur, a le mérite d’augmenter la confiance de l’environnement d’authentification, mais reste toutefois largement insuffisante. En effet, elle ne donne aucune garantie sur la force des mots de passe choisis par les utilisateurs, qui possèdent généralement une entropie assez faible . De plus, les attaques par phishing ne sont pas neutralisées pour autant, même si leur efficacité est moindre.

Il est alors possible, pour un serveur, d’obtenir une borne supérieure de l’entropie du mot de passe de l’utilisateur, et avec des considérations de théorie des langages et de linguistique plus avancées, d’obtenir une estimation plus fine de son entropie réelle. En effet, par défaut le serveur connaît l, et par une analyse de la chaîne saisie, il est assez simple d’avoir une estimation de b (utilisation de minuscules seules, de chiffres, de majuscules et minuscules, de caractères spéciaux, etc.). L’équation précédente correspond, avec ces paramètres, à un mot de passe parfaitement aléatoire, ce qui n’est en général pas le cas. L’entropie réelle est donc nécessairement plus faible.

L’expérience montre alors, à la lumière de ces éléments théoriques, que les jugements de « force » des mots de passe sont généralement fallacieux, car il est souvent considéré comme impossible, et contre-productif, de demander à un utilisateur de composer une chaîne pseudoaléatoire. Ainsi, dans le cadre de la création d’un compte sur le serveur de Gmail, un mot de passe a été jugé « fort » alors qu’il ne contenait que 9 lettres minuscules, où consonnes et voyelles étaient suffisamment alternées pour qu’il fasse éventuellement partie de la langue anglaise ou française. Cet exemple donne les paramètres l = 9 et b = 26 (contre une valeur maximale de 95 pour b). Le calcul donne alors une borne supérieure de l’entropie de 42 bits. Cependant, l’utilisation du tableau figurant dans la même annexe A de [24], et la prise en compte d’une distribution fort peu aléatoire des caractères de l’alphabet courant, donne une estimation de l’entropie réelle plus proche de 24 bits, ce qui peut être considéré comme acceptable, pour protéger l’accès à des données peu sensibles, mais non « fort ». Par ailleurs, le serveur de Microsoft permettant de vérifier dynamiquement la force d’un mot de passe[25] l’a jugé « faible ». De fait, une estimation du temps nécessaire pour casser un tel mot de passe, sur un serveur qui ne disposerait pas de contre-mesures supplémentaires, peut être obtenue en imaginant une attaque par force brute. Le temps maximal nécessaire pour retrouver le mot de passe est fonction du nombre de requêtes par secondes envoyées au serveur.