Authentification dans un système réparti

Par BeRgA

Table des matières

• Introduction et contexte ;
• I - Problématique ;
• II - Authentification ;
• II.1 - Mécanismes cryptographiques ;
• II.2 - Protocole d’authentification ;
• II.2.1 - Modèle de l’attaquant ;
• II.2.2 - Propriétés d’un protocole d’authentification ;
• II.2.3 - Principales failles des protocoles d’authentification ;
• III - Protocole d’authentification retenu ;
• IV - Protection physique des clé ;
• V - Conclusion ;

Introduction et contexte

Dans tout système de communication, les entités en jeu fonctionnent à l’aveugle, elles ne voient que ce qu’il se passe de leur côté, pas plus loin. Par exemple, une machine connectée à un LAN a uniquement accès aux informations transitant par son interface réseau, elle n’a aucune vue directe sur les élèments de son environnement. Afin de repérer les différents acteurs d’une communication, il est donc nécessaire de pouvoir les identifier : savoir qui est qui.

Pour des communications sans grande importance, il n’est pas nécessaire d’attacher une grande importance à la façon donc le système va identifier les différentes entités.

En revanche, lorsque celle-ci devient un facteur clé du système, il faut alors pouvoir s’assurer que l’identité déclarée d’un des éléments est légitime, afin d’éviter des situations d’usurpation d’identité. Il faut alors non seulement identifier une entité, mais également l’authentifier : s’assurer de façon sécurisée de son identité.

Le but de ce document est d’expliquer les principes de l’authentification, les outils utilisés, ainsi que les différents problèmes à prendre en compte lorsqu’il s’agit de mettre en place un système d’authentification. Nous nous appuyerons pour cela sur un exemple, afin de faciliter l’assimilation des différentes notions dont il sera sujet, en permettant de les ancrer à une situation concrète.

Considérons donc un système composé d’émetteurs et de bornes communiquant entre eux via un canal radio. Les émetteurs sont nomades et associés à des utilisateurs différents. Les bornes communiquent, via un réseau quelconque, avec une station centralisée qui contient des informations sur les utilisateurs. Cette structure se retrouve dans un grand nombre de réseau utilisés quotidiennement (architecture mobile/BCS/MCS (cf article Gutek), carte/terminal/banque (simplifié et mis à part le canal radio), badge/lecteur/centre dans un système de contrôele d’accès, etc.). La structure est donc la suivante :

Nous ne nous intéresserons pas ici à la technologie utilisée pour la communication radio, ni à la nature des informations traitées par le système. On supposera simplement que l’émetteur permet à son propriétaire d’accéder à des services personnels et confidentiels depuis n’importe lequel des récepteurs. Le réseau interne est pour le moment supposé propre au système, et sûr.

Dans ce cadre, étant donné que l’émetteur est utilisé pour permettre à son utilisateur l’accès à des informations personnelles et confidentielles, il est primordial que le système soit sûr que l’émetteur avec lequel il communique est légitime, et est bien celui qu’il dit être.

Réaliser un clone d’un émetteur utilisé dans de telles circonstances permettraient à un individu de consulter les informations d’autres utilisateurs, d’utiliser le système sans y être autorisé. Il est donc nécessaire de mettre en place un système d’authentification des émetteurs. Nous considérerons enfin que les émetteurs s’auto-alimentent en énergie (batteries), et qu’il est donc nécessaire de prenre en considération les problématiques de consommation.

I Problématique

A priori, rien n’empêche quelqu’un de créer un émetteur contenant les mêmes données qu’un émetteur légitime afin d’accéder à des fonctionnalités du systèmes auxquelles elle n’a pas normalement accès. L’émetteur doit donc prouver son identité à la borne qui le sollicite : il est donc nécessaire d’introduire un premier niveau de sécurité ; l’authentification d’un émetteur par une borne. La technique première serait d’enregistrer dans l’émetteur une information secrète qu’il transmettrait à la borne à chaque sollicitation. C’est ce qu’on appelle « l’authentification faible ». C’est le principe général des protections par mot de passe : Lors de votre enregistrement à un service, vous définissez un secret, souvent une chaîne de caractères, que le système vous demandera à chaque fois que vous souhaiterez utiliser ce service. Le système supposant que vous seul connaissez ce secret, si vous lui fournissez, il vous authentifie.

En revanche, ceci n’empêche en rien un intrus situé à proximité d’une borne d’enregistrer cette information (étant donné que le support de transmission utilisé, ici les ondes radios, permet à n’importe qui d’écouter l’échange), afin de la rejouer plus tard, faisant ainsi croire à la borne qu’il a bien la télécommande qu’il a espionné auparavant. Rappelons que la borne, comme toute entité du système, fonctionne en aveugle : si on rejoue la bonne information, il n’a absolument aucun moyen de savoir qu’elle n’a pas été envoyée par le bon émetteur).

En aucun cas, dans un mécanisme d’authentification, le message envoyé par le tag ne doit être fixe, afin d’éviter ces problèmes de rejeu.

Le mécanisme d’ « authentification forte » permet d’éviter ce problème. Là encore, notre émetteur contient un secret connu uniquement de lui et la borne au moment de l’échange, mais ce secret ne sera jamais transmis. La borne va poser une question à laquelle seul l’émetteur peut répondre. La réponse attendue par la borne est le résultat du chiffrement de cet aléa grâce au secret que possède la télécommande. La borne n’a ensuite qu’à comparer la réponse de l’émetteur avec le résultat de l’opération qu’elle aura effectué de son côté (étant donné qu’elle possède elle aussi le secret partagé). Si les deux sont identiques, alors l’émetteur est bien celui qu’il prétend être.

L’utilisation d’un algorithme asymétrique rend la chose un peu plus simple : la borne envoie un aléa à l’émetteur. Ce dernièr le chiffre avec sa clé privée, et envoie le résultat à la borne. La borne déchiffre le message avec la clé publique de l’émetteur avec lequelle il pense communiquer. Si elle retrouve son aléa, alors elle est sûre qu’il a bien été chiffré avec la clé privée de l’émetteur, connue uniquement de ce dernièr, et authentifie donc l’émetteur.

On évite ainsi tous les problèmes liés à l’usurpation d’identité : donner un accès à un bâtiment ou à une zone protégée, autoriser des actions sensibles, faire payer ses achats à un pauvre bougre, etc.

En revanche, l’authentification de l’émetteur par la borne n’empêche pas à un attaquant de mettre en place une borne illégitime pour dialoguer avec les émetteur. Cela pourrait amener à des problèmes de diffusion d’information, à la récupération d’informations contenues dans l’émetteur.. Il est donc en théorie nécessaire d’avoir une authentification double, c’est-à-dire de faire en sorte que la télécommande s’assure de l’identité de la balise avec laquelle elle dialogue. Le principe et la démarche étant les mêmes que pour l’authentification de l’émetteur par la borne, nous nous limiterons à cette seule problématique dans le reste de cet article.

Maintenant que l’intérêt de mettre en place un mécanisme d’authentification dans notre système est clairement démontré, voyons comment le réaliser.

II Authentification

Un mécanisme d’authentification s’appuie toujours sur l’utilisation conjointe et coordonnée de deux outils :

• Des mécanismes cryptographique, qui permettent d’assurer à la fois le secret des informations échangées entre les entités à authentifier ;
• Un protocole d’authentification, qui régit l’ordre et le contenu des messages que les deux entités doivent s’échanger.

II.1 Mécanismes cryptographiques

L’utilisation d’un lien radio pose un premier problème : Tout le monde peut avoir accès aux messages échangés entre l’émetteur et la borne, de part la nature même du média utilisé. Il est donc nécessaire de rendre ces messages inintelligibles pour tout acteur extérieur au système : On ne peut empêcher la lecture par un tiers des messages envoyés, il faut donc lui empêcher l’accès à l’information contenue dans les messages.

Notre système doit donc déployer des mécanismes cryptographiques, afin de chiffrer et déchiffrer les messages émis sur le lien radio : faire en sorte que seul le destinataire du message (soit l’émetteur, soit la borne) soit en mesure de lire le message. Cette propriété se décompose en deux :

• Le propriétaire doit être capable de déchiffrer le message, donc il doit posséder une clé de déchiffrement ;
• Seul le destinataire doit être capable de le faire, donc la clé utilisée doit être secrète (connue uniquement par les entités en jeu dans la communication).

Nous avons donc à utiliser un algorithme de chiffrement à clé secrète.

Il en existe deux types :

• Les algorithmes symétriques : la même clé est utilisée pour chiffrer et déchiffrer le message, et un message chiffré avec une clé ne peut être déchiffré qu’avec cette même clé, appelée clé partagée. L’inconvénient de ces mécanismes est le fait que la clé doit être connue des deux entités, ce qui implique une session de synchronisation avant la communication (échange de la clé partagée), ou une configuration en « dur » sur la télécommande (donc une protection physique de la clé, nous y reviendrons plus loin dans ce document);
• Les algorithmes asymétriques : chacune des deux entités communicantes ne possèdent plus une clé, mais deux, une clé publique et une clé privée. La clé publique est distribuée librement à l’ensemble des entités susceptibles de communiquer avec son propriétaire. La clé privée, elle, reste secrète et n’est connue que de son propriétaire.

Les deux clés ont les propriétés suivantes :

• Un message chiffré avec une des deux clés (publique ou privée), ne peut être déchiffrée qu’avec l’autre ;
• La connaissance d’une des deux clés ne permet pas le calcul de l’autre.

Ainsi, lorsqu’Alice veut envoyer un message à Bob, elle va le chiffrer avec la clé publique de ce dernier. Le message transitera sur le réseau, n’étant lisible que par Bob, puisque seule sa clé privée peut déchiffrée le message chiffré avec sa clé publique. L’avantage de ces systèmes est qu’ils ne nécessitent pas de gestion des clés (chaque entité n’a qu’à connaître sa clé privée et partager sa clé publique pour pouvoir communiquer). En revanche, les calculs utilisés dans les algorithmes asymétriques sont lourds et grands consommateurs de ressources, donc peut adapté à des systèmes embarqués.

Notons ici que le système à chiffrement asymétrique possède un autre intérêt, celui de la signature numérique. Supposons qu’Alice chiffre son message avec sa clé privée avant de l’envoyer. Chaque autre entité peut récupérer la clé publique d’Alice, et donc déchiffrer le message. L’intérêt ne réside donc pas dans la confidentialité du message. En revanche, étant donné que Bob peut déchiffrer le message avec la clé publique d’Alice, cela signifie qu’il a nécessairement été signé par sa clé privée, de part les différentes propriétés des clés. La clé privée d’Alice étant connue d’elle-seule, alors Bob est sûr qu’Alice est bien l’émettrice du message. On introduit ainsi un concept de signature numérique, qui permet à la fois d’authentifier l’émetteur d’un message, mais également d’attester que le message n’a pas été modifié entre son envoi et sa réception.

Il est important de noter que dans les deux cas, la robustesse du système cryptographique repose (presque) entièrement sur la longueur de la clé. Que nous choisissions l’un ou l’autre, nous devrons nous assurer de la longueur suffisante des clés utilisées.

II.2 Protocole d’authentification

Il est nécessaire de définir la façon dont l’authentification, quelle soit faible ou forte, doit se faire : quels sont les messages envoyés, à qui, par qui, les réponses attendues. Il s’agit donc de définir le protocole d’authentification qui, une fois mené à terme, permettra aux entités d’être sûres de l’identité de leurs interlocuteurs.

II.2.1 Modèle de l’attaquant

Afin de définir correctement notre protocole, il nous fait faire des hypothèses sur les capacités de l’attaquant potentiel qui tenterait de contourner la sécurité de notre système. L’utilisation du canal radio pour la transmission nous permet d’utiliser le modèle de l’attaquant de Dolev-Yao, qui stipule que ce dernier :

• Peut intercepter tout message transitant sur le canal ;
• Peut créer des messages conformes au protocole de communication (taille des trames, contenu);
• Possède les ressources matérielles pour effectuer des opérations lourdes (chiffrement/déchiffrement s’il possède les clés, brute-force);
• Ne peut déchiffrer un message que s’il possède la bonne clé.

Pour résumer, nous considérons l’attaquant comme maître du réseau, et les algorithmes de chiffrement comme sûrs. Ce modèle permet de définir l’attaquant sans pour autant le limiter dans ces capacités.

NB : Dans ce modèle, l’attaquant est censé ne pouvoir s’appuyer que sur les informations disponibles sur le réseau. Dans notre cas d’utilisation, il pourrait également disposer d’informations récupérées physiquement sur un émetteur légitime. Il est donc nécessaire de protéger également les informations directement sur les dispositifs matériels. Nous reviendrons sur ce point à la fin de l’article.

II.2.2 Propriétés d’un protocole d’authentification

Un protocole d’authentification définit la façon dont deux entités communicantes doivent s’échanger des messages amenant à s’assurer de l’identité l’une de l’autre. Cet échange ne doit pas pouvoir être effectué par une entité non-légitme.

Pour assurer ceci, un protocole doit vérifier plusieurs propriétés. Tout d’abord, le contenu des messages doit être chiffré, afin qu’un attaquant n’ait pas accès à l’information échangée. Dans une authentification faible, l’impact de cette propriété est immédiate. Il est évident que si un émetteur légitime envoit son secret (son mot de passe par exemple) en clair sur le canal radio, il suffira à l’attaquant de le récupérer, et l’envoyer plus tard à la balise, qui le prendra pour l’émetteur légitime. L’intérêt du chiffrement est un peu moins évident dans le cas d’une authentification forte utilisant un challenge. Mais en récupérant un grand nombre de challenges et les réponses associées, alors lorsqu’un challenge sera réutilisé une seconde fois (ce qui arrivera nécessairement étant donné que la taille des challenges est fixe, donc leur nombre limité), il pourra prévoir la réponse à envoyer pour faire croire à la balise qu’il possède le secret utilisé normalement pour calculer la réponse. L’interêt du chiffrement est donc clair.

Notons ici qu’un chiffrement asymétrique permet à la fois de chiffrer le contenu des messages tout en assurant aux entités l’identité de l’émetteur du message (signature par clé privée). Mais les opérations de chiffrement asymétrique étant lourdes en terme de ressource et de temps, il est nécessaire de les utiliser au minimum. Le chiffrement de la plupart des messages doit donc se faire par une clé partagée. Le protocole doit amener au partage de cette clé.

La clé partagée entre les deux entités doit vérifier des propriétés de robustesse et de fraicheur.

La robustesse signifie que la clé est suffisament grande pour résister aux attaques de type brute-force sur une durée raisonnable. Pour assurer cette propriété, nous utilisons un chiffrement symétrique AES-128, utilisant des clés partagées de 128 bits. Cet algorithme est aujourd’hui le standard américain utilisé pour les données classifiées « Défense », nous assurant ainsi sa robustesse. Il est également à noter que AES a été spécialement conçu pour être adapté aux systèmes disposant de peu de ressoures. Il est donc très intéressant pour nous au niveau consommation énergétique et temps de calcul.

La fraîcheur d’une clé signifie que cette dernière n’a jamais été utilisée dans ce contexte. Il faut donc qu’à chaque authentification, une nouvelle clé symétrique soit générée pour être utilisé pour chiffrer les messages entre l’émetteur et la balise. Notre système devra donc générer à chaque session une nouvelle clé aléatoire de 128bits qui sera utilisée pour le chiffrement AES.

Enfin, un protocole d’authentification doit assurer la propriété d’aliveness. Cela signifie que lors du déroulement de la procédure, tous les acteurs doivent être actifs. Nous utiliserons pour cela un nombre aléatoire généré par la balise, qui sera incrémenté à chaque message envoyé. Cela assure que les entités sont actives (puisqu’elles devront modifier une partie du message reçu), mais également que les messages de deux sessions d’authentification différentes seront différents, et ne pourront donc pas être rejoués pour simuler une nouvelle session.

II.2.3 Principales failles des protocoles d’authentification

Les différents protocoles d’authentification élaborés dans divers domaines ont permis d’identifier des failles récurentes. Voici les plus importantes, ainsi que les solutions que nous avons choisi pour les contrer.

II.2.3.a 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.

II.2.3.b 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.

II.2.3.c 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.

II.2.3.d 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.

Dans notre système, le firmware de la balise défini un tableau à deux dimensions, associant un émetteur à son état (présent, authentificatione n cours, authentifié), ainsi que les informations liées à la session : aléa utilisé, clé AES. Un émetteur ne passe dans l’état « authentifié » qu’une fois la dernière étape du protocole validée. Cela permet également à notre système de traiter l’authentification de plusieurs émetteurs en parallèle.

De même, le firmware de l’émetteur définit un tableau identique, à cela près qu’il n’a qu’une dimension (un émetteur ne peut être authentifié qu’auprès d’une seule balise).

Les différents états possibles, ainsi que les étapes du déroulement d’une session d’authentification sont détaillées plus loin.

III - Protocole d'’authentification retenu

Le protocole que nous devons mettre en place dans notre système doit donc répondre à toutes ces contraintes, afin d’assurer une authentification sécurisée de nos émetteurs.

Nous allons pour cela spécifier ce que doivent contenir les trames échangées.

Il faut d’abord que les balises puissent se rendre compte de la présence d’un nouvel émetteur dans leur champ, et vice versa. Pour des raisons évidentes de consommation en énergie, il n’est pas possible de positionner les émetteurs en écoute permanente jusqu’à ce qu’ils reçoivent une trame de la balise. En revanche, ces dernières n’ont pas ce problèmes : elles sont fixent, donc les relier à une source d’alimentation ne pose pas de problème.

Les émetteurs vont donc émettre régulièrement des trames de présence, contenant leur adresse (donc leur identifiant), et attendre pendant un petit temps une réponse éventuelle d’une balise avant de se remettre en sommeil. Les balises, quant à elles, sont continuellement en écoute, et possèdent un tableau identifiant/état (présent | authentification en cours | authentifié)/clé qui assure le suivi des différents émetteurs. Lorsqu’une balise reçoit une trame de présence d’un émetteur, elle vérifie la présence de l’id dans son tableau de suivi. On a alors 3 scénarios :

1°) Emetteur absent du tableau :

Il vient donc juste d’arriver dans le champ de la balise, il est nécessaire de l’authentifier. Il est placée dans le tableau avec l’attribut "présent", et la balise lance une session d’authentification. Pour cela, elle récupère la clé publique de l’émetteur via le serveur de clé, et envoie à l’émetteur sa clé publique (celle de la balise), et un aléa, le tout chiffré avec la clé de l’émetteur. Ce dernier récupère la clé de la balise et l’utilise pour chiffrer l’aléa+1, après l’avoir signé avec sa clé privée. La balise récupère la trame envoyée, déchiffre le message, vérifie la signature et l’incrémentation de l’aléa, et authentifie alors l’émetteur. Elle lui envoie ensuite une clé de session de 128bits, générée aléatoirement, et un identifiant de session, le tout chiffré avec la clé publique de la télécommande. La balise met alors à jour le statut de l’émetteur à "authentifié" dans son tableau de suivi, et lui associée la clé de 128 bits générée.

2°) Télécommande présente :

La procédure d’auth est donc en cours, les paquets en provenance de la télécommande sont dropés s’ils ne s’inscrivent pas dans cette procédure. La denrière étape validée est identifiée par un numéro inscrit dans le tableau de suivi.

3°) Télécommande authentifiée :

La balise droppe tout paquet en provenance de cet émetteur dont le payload n’est pas chiffré avec la clé de session de 128bits. Les échanges de messages correctement chiffrés (donc avec la bonne clé) contiennent dans le payload chiffré un numéro de séquence, incrémenté à chaque échange de message entre la balise et la télécommande. Si, et seulement si, la balise vérifie à la fois le bon chiffrement et l’incrémentation du numéro de séquence, alors elle fait remonter le payload en clair.

On considère également qu’après un certain temps d’inactivité de la télécommande (pas de message de présence), la balise vire le contexte correspondant de son tableau d’état.

Ce protocole ne prend pas en compte la sécurité du réseau de communication utilisée entre la balise et le serveur de clé. Cependant, s’agissant certainement d’un réseau IP, nous suggérons que l’échange (demande de clé -> envoi la clé publique) soit signé et chiffré par les deux entités, afin d’éviter une altération volontaire du message par un attaquant souhaitant soit obtenir la clé d’une télécommande, soit tromper la télécommande.

De même, l’authentification ici est à sens unique, l’émetteur n’authentifie pas la balise, pouvant amener à de la diffusion non souhaitée d’informations. Cependant, deux facteurs motivent notre choix de ne développer que l’authentification de la télécommande par la balise :

D’une part, les informations potentiellement diffusables sont celles contenues sur l’émetteur, c’est-à-dire son identifiant et sa clé privée. Or, l’identifiant est diffusé en clair dans toutes les trames envoyées par l’émetteur, il n’est donc pas nécessaire d’en empêcher sa récupération dans le cas d’une usurpation d’identité. L’identifiant est utilisé par la balise pour suivre les émetteurs, mais ce dernier n’est en aucun cas suffisant pour l’authentification. Sa diffusion en clair ne pose donc pas de problème de sécurité. La clé privée, quant à elle, n’est en aucun cas diffusée sur le canal radio. Le fait d’utiliser une fausse balise n’apporterait donc aucune information supplémentaire ou intéressante à un attaquant.

De plus, rajouter cette deuxième authentification signifierait consommer plus de ressources. Celles de l’émetteur étant limitées, et l’intêret ici de cette double authentification étant très faible, il n’est pas nécessaire de la mettre en place.

Elle reste cependant possible. Si des développements ultérieurs nécessitaient sa mise en place, voici une façon de le faire :

Lorsque le serveur de clés reçoit une requête de la part d’une balise, ce dernier peut joindre à son message un bloc, chiffré avec la clé publique de l’émetteur, contenant la clé publique de la balise à l’origine de la requête, signé avec sa clé privée.

La balise récupérerait alors la clé de l’émetteur et lui transmettrait le bloc chiffré (la balise ne possédant pas la clé privée de l’émetteur, elle ne pourrait pas le déchiffrer ni modifier son contenu).

L’émetteur recevrait alors la clé publique de la balise directement du serveur de clé, entité certifiée du système. La signature du message par le serveur de clé attesterait alors de son authenticité.

La seule modification que cela apporterait à notre système est le fait que les émetteurs devront alors connaître les clés publiques des serveurs de clés. Etant donné que ces serveurs seront en nombre restreint, cela est viable.

IV - Protection physique des clés

Le principal problème lié à l’authentification (et par conséquent à l’anticlonage), est le stockage sécurisé des secrets sur l’émetteur. En effet, afin d’empêcher un clonage, il faut empecher l’accès à ces secrets, qui sont nécessaires (mais non suffisant) pour réaliser une session d’authentification.

Cette problématique appliquée à un cas réel, dans lequel des télécommandes contenant un microcontroleur PIC18f4620 devaient s’authentifier auprès de balises, avait mené à la reflexion suivante :

Le stockage de données est un point sensible, car il doit être tel que même un accès physique à un émetteur légitime ne suffise pas pour récupérer les secrets. Dans notre cas, la télécommande de base ne comportait qu’un circuit capable de stocker des données : le PIC. Or, les données placées sur le PIC sont récupérables. Il n’était donc pas envisageable de stocker les clés directement sur le PIC (c’est-à-dire à les faire figurer dans le code source du firmware de la télécommande).

La solution consistait donc à exporter ces clés, soit sur une mémoire sécurisée, soit dans un cryptoprocesseur.

Les mémoires sécurisées stockent les données après les avoir chiffrées (avec différents algorithmes selon les types de mémoire), ce qui empêche l’accès aux données avec une simple récupération du contenu de ces mémoires. En revanche, les données sont déchiffrées avant d’être transmises à l’unité de traitement, elles circulent donc en clair sur les bus. Une écoute de ces bus amène donc à la récupération des données, c’est-à-dire des clés privées dans notre cas, soit un clonage possible de la télécommande.

Les cryptoprocesseurs sont des puces composées d’une mémoire et d’un processeur. La mémoire permet de stocker des données chiffrées, et la présence du processeur à l’intérieur même de la puce permet d’effectuer les opérations de chiffrement directement. Les données ne sont donc pas transmises en clair sur les bus.

Le TPM est un cryptoprocesseur évalué EAL4 (cf. le rapport sur les normes de sécurité), à faible coût. Il était donc un bon compromis entre sécurité et coût, répondant aux attentes du client en terme de normes, nous permettant de stocker de façon sûre nos clés privées (empêchant ainsi le clônage des télécommandes), et n’apportant pas un surcoût important en terme de production. Nous redirigeons le lecteur vers le rapport sur le TPM pour plus de détails à son sujet.

Dans le cadre de notre projet, l’acquisition de TPM et leur implantation sur la télécommande aurait demandé trop de temps. Nous avons donc, en accord avec le client, décidé d’opter pour le développement d’un simulateur. Une puce TPM est fournie avec un fichier de configuration permettant de faire l’interface entre elle et un micro-contrôleur. L’étude des datasheet nous a permis d’identifier les fonctions dont nous avions besoin, ainsi que leur prototype (paramètres, nom, et sorties). Notre firmware fait donc appel à ces fonctions, simulant les fonctions réelles. Ainsi, si LC&I décide d’implanter des puces TPM sur ses télécommandes, il leur suffira de remplacer le fichier de configuration de notre simulateur par celui fournit avec le TPM, et la télécommande utilisera alors les vraies fonctions de la puce plutôt que notre simulation, sans aucune modification nécessaire au niveau du firmware

Ce choix nous a permis d’implémenter notre protocole d’authentification tout en facilitant au maximum le passage à une vraie puce.

Cependant, le microcontroleur des télécommandes ne disposant pas des ressources nécessaires pour effectuer les opérations de chiffrement asymétriques, normalement réalisées par la puce TPM, les fonctions que nous avons développées n’effectuent aucun chiffrement ni stockage sécurisé des données, et la fonction de génération de nombre aléatoire resta basique. Nous déconseillons par conséquent au client de conserver notre simulateur pour la production ultérieure des télécommandes, car les secrets sont conservés en clair sur le PIC, donc récupérables.

V - Conclusion

Les problématiques liées à l’authentification d’entités sont généralement complexes, et les solutions non-portables, puisqu’elles reposent sur des compromis à faire en fonction du contexte : nombres d’acteurs, mobilité, capacités de calculs, consommation, canal utilisé, contraintes temporelles, transparence pour l’utilisateur final, etc. Plutôt que de retenir la solution développée ici, il est donc nécessaire de comprendre la démarche, et les raisons expliquant tel ou tel choix (par exemple, le serveur tiers utilisé ici n’aurait pas été nécessaire si le nombre d’émetteurs était limité et fixe, et n’aurait pas été envisageable si les balises avaient dû être autonomes), afin de reproduire ces compromis face à une problématique se situant dans un contexte différent.

BeRgA

Contacter l'auteur ;