Principales failles des protocoles d'authentification

Un protocole d'authentification est un protocole d'échange de messages, utilisant des mécanismes cryptographiques afin d'assurer l' authentification d'une entité. Cette page résume les principales failles pouvant mettre en péril un tel protocole.

Rejeu

Cette faille apparaît lorsque les messages échangés pendant le déroulement du protocole ne différent pas d’une session à une autre. Il est alors possible pour un attaquant de récupérer ces messages et de les ré-emettre ultérieurement, dans l’ordre, afin de simuler une session légitime, sans avoir besoin de les décrypter.

Afin d’éviter les attaques par rejeu, la balise générera un nombre aléatoire au début de chaque session, qui sera incorporé au message. Les opérations de chiffrement appliquées sur le message auront pour conséquence de « répartir » l’impact de cet aléa sur l’ensemble du message : deux messages qui ne différent que d’un bit se verront totalement différenciés l’un de l’autre une fois chiffrés.

faille de binding

Une faille de binding vient de la faiblesse potentielle du lien entre clé publique et son propriétaire. En effet, la force des mécanismes asymétriques vient en partie du fait que lorsqu’on reçoit un message chiffré avec une clé privée (donc signé), alors on est assuré que l’émetteur est l’entité associée à la clé publique permettant de le déchiffrer. Dans notre cas, si l’émetteur fournit lui-même sa clé publique à la balise auprès de laquelle elle souhaite s’identifier, alors un attaquant pourrait, en générant une paire de clés, suivre le protocole en utilisant l’identité de n’importe quelle télécommande : le système n’aurait aucun moyen de vérifier que l’association entre l’identifiant et la paire de clé est légitime.

Il est donc nécessaire que ce ne soit pas l’émetteur qui fournisse sa clé publique. Nous avons alors deux solutions : soit toutes les balises connaissent les clés publiques de toutes les télécommandes, ce qui n’est absolument pas viable (nombre de clé trop important, problème de la fabrication de nouveeaux émetteurs, etc.), soit la clé publique est fournie par un serveur tiers, de confiance. C’est cette solution que nous avons retenue. D’autant plus que, afin d’offrir aux utilisateurs du systèmes les services en question, il est nécessaire de disposer d’une base de données centrale. L’accès de toutes les balises à un système centralisé n’est donc pas un problème supplémentaire.

faille d’oracle

Cette faille apparaît lorsqu’il est possible d’obtenir des informations sur le protocole, les entités en jeu, au travers d’un dialogue. Afin d’éviter cela, tous les messages de notre système sont chiffrés, soit asymétriquement pendant le déroulement de la session, soit symétriquement par une clé unique une fois la télécommande authentifiée.

Les seuls messages non chiffrés qui transiteront sur le canal radio sont les messages de présence, contenant l’identifiant de la télécommande. Cet identifiant étant inutile tant que la télécommande n’est pas authentifiée, sa diffusion en clair ne pose pas de problème de sécurité supplémentaire.

Faille de type

Cette faille exploite l’incapacité d’au moins un participant à associer un message avec un état particulier du protocole. Il est donc nécessaire que chaque entité impliquée dans une session d’authentification sache à tout moment où elle en est, quel message est attendu, quelle est la prochaine étape du protocole, etc.