Gestion des smartcards sous Linux
Signature : | Mis en ligne le : 30/11/2007
Catégorie(s) :
  • GNU/Linux Magazine
  • | Domaine :
    Commentez
    Article publié dans :
    Achetez
    Linux Magazine 88 :
    Version Papier
    Avec l’accroissement des transactions sur le Net, l’hostilité grandissante de cet environnement et la fragilité de certaines applications, l’utilisation des mots de passe ne garantit plus vraiment de sécurité. Il faut alors se tourner vers des méthodes d’authentification matérielles. L’utilisation de cartes et tokens USB est l’une d’elles. Vous avez sécurisé vos serveurs et vos postes clients. Vous choisissez vos applications avec discernement et les mettez à jour régulièrement. Vous suivez avec assiduité les rapports de bugs, les annonces de failles et appliquez tous les patchs immédiatement. Enfin, vous n’oubliez pas de faire preuve d’un soupçon de paranoïa, bref, vous êtes l’administrateur parfait. Mais le risque d’intrusion et de vol d’informations est toujours présent. De plus, peut-on calquer ce comportement sur tout le monde ? J’en doute. Les systèmes informatiques ne sont pas sûrs et ne le seront sans doute jamais totalement. Une clef privée, un fichier de mot de passe ou un formulaire enregistré par le navigateur peuvent être corrompus ou volés sur le système qui les héberge et compromis. Deux solutions se présentent : soit vous trouvez le moyen de sécuriser le système à 100% (et les pages du magazine vous seront grandes ouvertes pour y décrire la méthode et l’implémentation), soit vous déléguez le stockage des informations sensibles sur un support robuste, transportable, modulaire et souple : une smartcard. La biométrie est également une voie possible, mais bien que les deux premières caractéristiques soient vérifiées, on ne peut pas en dire autant de la modularité et de la souplesse. Difficile de stocker un certificat X.509 dans un doigt ou un oeil. En tout cas, pas de nos jours.

    Les smartcards

    On associe parfois abusivement le terme "smartcard" à une simple carte à puce et c’est une grosse erreur. Une carte à puce est un simple support. Le composant qu’elle intègre n’est pas nécessairement à même de fournir les fonctionnalités attendues pour en faire une smartcard. Si nous prenons le cas d’une carte téléphonique prépayée, par exemple, il ne s’agit que d’une simple mémoire (à peine améliorée). "smart" signifie "intelligente" et cela suppose qu’une smartcard intègre un minimum de logique : un microcontrôleur ou un microprocesseur.

    /img-articles/lm/88/art-3/fig-1.jpg

    Une smartcard se résume donc à une puce intégrant un microcontrôleur et une mémoire qui n’est pas directement accessible. Les premiers tokens (clefs intégrant la puce et une interface de communication USB) mis sur le marché étaient des circuits relativement vulnérables. Avec de la patience et une certaine expertise, il était possible pour un attaquant de démonter le token emprunté, puis de lire (dumper) directement le contenu de la mémoire (EEPROM) pour créer un faux. Le vol simple d’un token ou d’une carte ne représente qu’un danger limité dans le temps. Si le propriétaire se rend compte du vol, les informations stockées seront rapidement déclarées corrompues et le certificat immédiatement révoqué. L’intégration est donc le maître mot de la sécurité des smartcards. Il est extrêmement difficile (voire impossible) et peu rentable d’attaquer physiquement une smartcard. Ce type de sécurité est facile à mettre en œuvre. On la retrouve même ainsi dans des cartes dont l’utilisation n’est absolument pas critique. La probabilité de pouvoir accéder physiquement aux données contenues dans une carte téléphonique ou de lavage automobile sont quasi nulles. Mécaniquement ou chimiquement, vous avez toutes les chances de détruire la puce plutôt que d’en obtenir le contenu. Il en va de même pour les cartes bancaires. Cette comparaison n’était, bien sûr, pas innocente. Si vous aviez en tête le mot "YEScard", sachez que ce n’est en aucun cas la technologie de la carte qui a été piratée, mais le dispositif de lecture. Il en va de même pour les télécartes, il y a une dizaine d’années, ou encore pour les systèmes de réception par satellite. C’est l’utilisation d’un montage se substituant à la carte qui permet de "gruger" le dispositif de lecture en exploitant ses faiblesses et non celles de la carte. Dans le cas d’une smartcard, le microcontrôleur sert d’interface. Vous n’avez jamais directement accès aux données stockées. La manière de dialoguer avec le microcontrôleur dépend de la smartcard. Il existe cependant une norme permettant de standardiser ce dialogue, c’est PKCS#11. Il s’agit d’une API standard permettant à n’importe quelle application supportant PKCS#11 d’accéder à une smartcard pour peu que le fabriquant ait mis à disposition un pilote PKCS#11. On parle ici d’un type spécial de smartcards, celles disposant de fonctionnalités cryptographiques. Elles sont capables de stocker des informations sans jamais les révéler (clefs privées), de générer des paires de clefs ou encore de chiffrer des informations. Le pilote compatible PKCS#11 permet de gérer les données sous forme d’objets. Une clef publique est un objet, un code PIN également. Une autre norme permet de standardiser l’organisation de ces objets et leur présentation, c’est PKCS#15. On notera que PKCS#11 et PKCS#15 ne vont pas nécessairement de pairs. La première concerne l’API d’accès à la carte et la seconde la présentation des données. Une même carte pourra parfaitement être initialisée dans un format propriétaire ou selon PKCS#15. C’est le cas, par exemple, des eToken d’Aladdin selon qu’on souhaite les utiliser avec un logiciel propriétaire sous Windows ou avec OpenSC sous GNU/Linux.

    Infrastructure en couche

    Afin d’uniformiser et de rendre compatibles les applications et les smartcards, l’industrie informatique a choisi un modèle sous forme de couches.

    /img-articles/lm/88/art-3/fig-2.jpg

    Matériel

    La couche la plus basse est, bien sûr, le matériel, à savoir le lecteur de carte lui-même. Il en existe de plusieurs sortes et disposant de différentes connectiques. On notera cependant que les lecteurs sur port série ont presque totalement disparu, ne reste que l’USB. Là, il faut encore distinguer trois cas :
    • le lecteur série/USB composé en réalité d’un lecteur série et d’un adaptateur USB. Il sera supporté sous Linux via le chargement d’un support usbserial ou approchant (pl2303 par exemple). Dans bien des cas, les distributions modernes chargeront le module adéquat automatiquement grâce au support udev. Ces lecteurs, de plus en plus rares, seront donc accessibles physiquement via /dev/ttyUSB[1-9].
    • Le lecteur propriétaire. Son support peut prendre trois formes, soit un module noyau, soit un greffon/pilote pour le middleware (voir plus bas), soit les deux. Ce type de lecteur est encore très courant et cela inclut les tokens USB. Il faut alors disposer d’un support sous GNU/Linux, ce qui est le cas pour la plupart des lecteurs "de marque".
    • Le lecteur CCID. C’est la voie de la standardisation. A l’instar de la classe Mass Storage (0x08), Printer (0x07) ou HID (0x03), il existe une classe Smart Card (0x0b). Comme vous le savez sans doute, tous les périphériques USB d’une classe répondent à une interface identique. Cela permet de ne pas avoir à développer un pilote par périphérique, mais simplement un pilote unique pour la classe. Dans le cas de la classe CCID (Chip/Smart Card Interface Devices), le support CCID n’est pas dans le noyau, mais le périphérique est géré par le middleware via la libUSB.

    Middleware et support des lecteurs

    C’est bien connu, les fabricants de matériel adorent développer leur support pour GNU/Linux. Ca l’est tant que des groupes de développeurs indépendants finissent par créer des projets pour offrir à l’utilisateur un support convenable et stable et finir par faire le travail desdits fabricants. C’est ainsi que, devant le manque de support, différents projets de middleware (se plaçant entre le pilote et l’application) ont vu le jour. Aujourd’hui, on distingue clairement deux manières d’accéder aux informations stockées sur une smartcard. Nous avons, d’une part, le standard PC/SC défini par le groupe de travail du même nom. Ce standard définit une API permettant d’accéder de manière unifiée à un lecteur de carte et une carte quels que soient le modèle et le fabricant, pourvu qu’il existe un driver. Une implémentation libre du standard PC/SC est PC/SC Lite. Selon votre distribution, l’organisation et la répartition des éléments logiciels en paquets peuvent varier, mais PC/SC Lite se compose comme suit :
    • Un démon pcscd fonctionnant comme gestionnaire de ressources et partageant l’accès aux périphériques pour les applications. Il est normalement lancé dès le démarrage du système.
    • Des pilotes sous la forme de bibliothèques dynamiques appelés "ifdhandlers". Ces pilotes permettent d’accéder aux lecteurs, le plus souvent via la libUSB. Ces ifdhandlers sont normalement placés dans le répertoire /usr/lib/pcsc/drivers selon une arborescence précise. Un fichier XML Property list accompagne le pilote et décrit, entre autres, à quels lecteurs il est destiné (VendorID/ProductID). Pour les lecteurs connectés au port série, il est nécessaire de créer une entrée dans le fichier /etc/reader.conf. Ceci n’est pas nécessaire pour un lecteur USB. C’est une erreur fréquente que de chercher à créer ou compléter le reader.conf, mais pcscd se débrouille très bien seul avec la libUSB.
    • Une bibliothèque dynamique libpcsclite.so permettant la création d’applications voulant accéder à la carte. C’est l’API unifiée fournie par PC/SC Lite.
    La configuration d’une installation PC/SC Lite se résume donc à l’installation du démon et d’un ou plusieurs ifdhandlers. Avec une distribution Debian, ceci prend la forme de l’installation du paquet pcscd et d’un ou plusieurs paquets qu’on listera facilement avec apt-cache search "PC/SC driver". Notez que quelques pilotes sont devenus obsolètes du fait du support via OpenCT (voir plus bas). L’autre middleware pour notre système est le fruit du projet OpenSC. Ce projet produit plusieurs bibliothèques, applications et outils en rapport avec les smartcards, leur support et leur gestion. Les deux éléments importants sont OpenCT et OpenSC. Le premier est le middleware à proprement parler permettant l’accès aux lecteurs de cartes (Card Terminal). Son principal intérêt est d’être totalement générique. Le couple OpenCT/OpenCS intègre son propre support pour certains lecteurs, mais peut également accéder aux services fournis par PC/SC Lite et accéder aux lecteurs uniquement supportés via CT-API. CT signifie Chipcard Terminal. Il s’agit d’une API concurrente à PC/SC. Il ne me semble pas nécessaire d’insister sur ce point dans le présent article. Bon nombre de pilotes CT-API se déclinent également d’une version PC/SC et, à moins de disposer d’une application reposant sur cette API, il n’est pas utile ici de compliquer les choses. Sachez simplement qu’OpenCS est en mesure d’utiliser des pilotes CT-API. Inversement, et c’est là toute la souplesse d’OpenCT, il existe des pilotes pour PC/SC et CT-API permettant de faire le pont, dans l’autre sens. Ainsi, si votre lecteur, comme le CardMan 2020, ne dispose que d’un support PC/SC, il est toutefois possible de l’utiliser avec les outils OpenSC. OpenSC, pour sa part, se place au-dessus d’OpenCT, PC/SC ou CT-API et permet de manipuler les données de la smartcard au format PKCS#15. Nous verrons, par ailleurs, un exemple complet d’utilisation. Vous avez donc l’embarras du choix pour trouver la solution permettant l’accès au lecteur. OpenCT se configure via le fichier /etc/openct.conf. Là, sont listés les identifiants fabricant et produit des lecteurs directement supportés. OpenSC n’a que faire du type de lecteur. Il lui faut simplement connaître via quel middleware il doit passer. Le fichier /etc/opensc/opensc.conf contient les paramètres pour chacun d’eux. La ligne importante du fichier est : C’est à vous de déterminer les supports en présence. Ne laissez sur cette ligne que les middlewares installés sur le système. Dans le cas contraire, vous risquez d’obtenir de désagréables messages d’avertissement ou d’erreur. C’est le cas, en particulier, pour PC/SC. Si votre lecteur est supporté directement par OpenCT et que pcscd n’est pas installé ou lancé, vous obtiendrez, à chaque commande, le message Cannot open public shared file: /var/run/pcscd.pub. Pour corriger le problème, il vous suffira de ne laisser dans votre opensc.conf que le support OpenCT et, donc, d’éliminer les mentions pcsc et ctapi. Pour conclure cette partie, je préciserais qu’il faut, avant configuration, évaluer vos besoins et faire au plus simple. De quelles applications vous servirez-vous ? Quelles API utilisent-elles ? Quel middleware supporte votre ou vos lecteurs ? Si nous prenons l'eToken PRO 64 d’Aladdin, celui-ci n’est supporté que par OpenCT. Il est donc possible de le rendre accessible par PC/SC Lite via l’ifdhandler fourni par OpenCT. Enfin, les outils OpenSC peuvent utiliser PC/SC Lite (pcscd). La question est : avez-vous vraiment besoin de PC/SC Lite ? Si ce n’est pas le cas, configurez simplement OpenSC pour reposer sur OpenCT et désinstaller PC/SC Lite. Il en va de même lorsque le lecteur, comme le SCR335, est supporté à la fois par PC/SC Lite et OpenCT. Tâchez d’éliminer ce qui ne sert à rien, sinon vous risquez de perdre beaucoup de temps en cas de dysfonctionnement d’un maillon de la chaîne.

    Exemples

    Les explications qui précèdent sont très théoriques. Voyons donc ce que cela donne lorsqu’on passe à la pratique. Le but est de permettre l’utilisation du lecteur par les outils OpenSC et les applications comme OpenSSH, FireFox ou des systèmes d’authentification basés sur PAM. Cet aspect applicatif sera traité dans un article séparé.

    OmniKey CardMan 2020

    Voici l’exemple type du produit non standard (non CCID), vieux, mais pas cher. Le produit a été acheté sur un site d’enchère en ligne pour quelques euros et est libellé comme lecteur de carte de marque Cherry (c’est d’ailleurs marqué dessus). Comme bien souvent avec les périphériques USB, le nom étiqueté ou moulé dans le plastique n’est pas toujours celui du fabricant. Ici, nous avons affaire à un produit fabriqué en réalité par OmniKey AG. N’étant ni compatible CCID, ni équipé d’un simple convertisseur USB/série (type PL2303), ni pris en charge directement par OpenCT, il est nécessaire d’installer un support spécifique. Dans le cas présent, cela prendra la forme d’un module noyau et d’un pilote pour le middleware PC/SC Lite (un ifdhandler en bibliothèque partagée). Heureusement, nous avons de la chance dans notre malheur, OmniKey AG fournit un support récent (janvier 2006) pour Linux 2.4 et 2.6. Il suffit d’aller sur le site du constructeur à la section support et de récupérer l’archive cm2020_installer_v2_4_1_src.tar.gz. Une fois désarchivé, on se rend compte que l’ensemble est relativement bien écrit, mais qu’une partie des sources ne sont pas disponibles. En effet, les sources du module noyau sont bien présents, mais le pilote PC/SC Lite est binaire. Autre surprise désagréable, les sources semblent conçues pour un noyau 2.6.12. Un certain nombre d’appels à des fonctions internes du noyau ne sont plus valables pour une version 2.6.15 par exemple (elle provoquait déjà un avertissement avec un 2.6.12). Heureusement, il existe une série de patchs [1] qu’on appliquera très simplement directement en se plaçant dans le répertoire cm2020_installer_v2_4_1_src/src/cm2020. Ceci fait, pour un système Debian, il faudra également modifier le script compile.sh également présent dans ce répertoire. En effet, les fichiers en-têtes du noyau sont recherchés dans /usr/src/kernel-headers* au lieu de /usr/src/linux-headers*. Il convient donc de changer la valeur de LINUXDIR. Ceci fait, il suffit de revenir à la racine des sources fournies par OmniKey et de lancer sh install. S’en suit la compilation et l’installation du module cm2020.ko, d’un script d’init un peu maladroit destiné à charger le module, et de l’arborescence /usr/lib/pcsc/drivers/ifd-ccid.bundle. Cette dernière correspond au pilote du lecteur et au fichier de descriptions (fichier Info.plist). Attention Cette installation est indépendante de tous systèmes de gestion de paquets. Cela peut poser problème sur un serveur en production. On notera, par exemple, que sur le système de test utilisant Debian, le script /etc/init.d/pcscd installé par le paquet pcscd est écrasé par le script install. Bien entendu, le script d’init en question n’est pas fonctionnel et il faudra réinstaller le script Debian. Dans le cas contraire, le démon pcscd ne sera pas lancé. Cependant, après tous ces tracas, l’ensemble fonctionne, comme le montre l’utilisation de la commande pcsc_scan (paquet pcsc-tools avec Debian) : Je vous fais grâce du résultat de la commande avec une carte insérée dans le lecteur. Pour rendre ce lecteur accessible par les outils OpenSC, il suffit de configurer reader_drivers = pcsc; dans votre opensc.conf. Pour preuve, voici l’utilisation d’une commande d’OpenSC sur ce type de configuration : L’installation de ce lecteur montre plusieurs points intéressants qui prêtent à réflexion :
    • Les pilotes de matériels anciens ont clairement tendance à disparaître ou ne plus être maintenu, en particulier lorsqu’ils ne sont pas officiellement intégrés au noyau.
    • Il existe une nette tendance au support privilégié pour les périphériques standardisés (classe CCID). La plupart des lecteurs, dont les nouveaux modèles d’Omnikey sont compatibles CCID.
    • L’initiative d’un fabricant proposant un pilote Linux n’a que peu de poids s’il n’existe pas de suivi de sa part dans le temps, ceci incluant les changements dans le noyau lui-même, mais aussi au niveau des distributions. Les patchs disponibles pour rendre les sources compatibles avec les nouvelles versions du noyau proviennent des sources d’un paquet RPM Red Hat.
    • GNU/Linux est un système ouvert où il reste possible d’obtenir des résultats en creusant un peu. Bref, quand on veut, on peut. Bien entendu, l’énergie dépensée, n’est sans doute pas intéressante dans un contexte de production. On préfèrera ainsi porter son attention vers des modèles plus récents et parfaitement supportés.

    Aladdin eToken

    Aladdin est une entreprise qui, depuis fort longtemps, œuvre dans le domaine de l’authentification matérielle. Cette activité est d’ailleurs tellement ancienne qu’elle date d’avant la généralisation des spécifications PKCS. Il en découle un sérieux problème de compatibilité avec les standards. Le support logiciel pour GNU/Linux (SUSE, RH et Fedora) fourni par Aladdin n’est absolument pas compatible avec le format PKCS#15. Ainsi, un token initialisé via les outils Aladdin (fournis sans les sources) ne pourra être utilisé avec OpenCT/OpenCS. Inversement, une carte initialisée au format PKCS#15 ne pourra servir avec les outils Aladdin. On notera que le produit eToken PRO est dit "pleinement supporté et bien testé" sur le site officiel du projet OpenSC. D’autre part, il est dit également que, faute de documentation sur la version 4.2 et 4.3b de CardOS, les développeurs ne peuvent développer de support pour les versions 64k et NGOTP. Seul un test effectif peut donc nous dire de quoi il retourne. Aladdin nous a prêté deux de leurs produits pour la durée des tests, un eToken Pro 64k et un eToken NG-OTP (OTP pour One Time Password). J’en profite pour les en remercier au passage. Le eToken NG-OTP n’est absolument pas supporté autrement que via les outils propriétaires fournis par Aladdin. Bien entendu, il est possible que cela change à plus ou moins court terme, puisque le développement OpenCT/OpenSC est très actif (Aladdin a également fourni gracieusement des tokens aux développeurs). Pour l’heure donc, seul l'eToken Pro 64k nous intéresse. Vous trouverez certainement un pilote ifdhandler PS/SC dans votre distribution (exemple, pour Debian le paquet libetoken). Il est tout aussi certain que ce pilote est non seulement obsolète (limité à la version 32k), mais que cet état de fait est clairement spécifié. On nous invite ainsi à nous tourner vers OpenCT. Là, avec une rapide installation de la version 0.6.8, on retrouvera dans le fichier /etc/openct.conf une mention commentée du token d’Aladdin : C’est bien ça : Inutile de configurer quoi que ce soit, un simple redémarrage éventuel du service openct fera l’affaire après "décommentage". La détection et la prise en charge du token, qui est pour les middlewares, un lecteur avec carte intégrée, sont immédiates : On notera également qu’une installation d’OpenCT inclut des scripts hotplug exécutés par le démon udev. Ces scripts ont pour but de lancer la commande openct-control permettant d’attacher et détacher des lecteurs du middleware. Il suffit à présent, de spécifier reader_drivers = openct; dans votre opensc.conf et l’ensemble sera fonctionnel avec les outils et applications reposant sur OpenSC. Profitons de l’occasion pour présenter la manière de procéder pour rendre disponible tout lecteur supporté par OpenCT au middleware PC/SC. OpenCT met à disposition un ifdhandler pour PC/SC Lite, mais celui-ci, avec Debian, n’est pas installé automatiquement (il semble que Fedora Core dispose d’un paquet faisant le lien entre les deux middlewares). Nous procédons comme ceci : Voici donc l’ifdhandler installé. Ne reste plus qu’à créer le fichier Property list au format XML : C’est une grosse tartine, je vous l’accorde. Mieux vaut donc prendre le Info.plist de l’ifdhandler libCCID par exemple et le modifier. Notez que nous avons ici spécifié uniquement les ifdVendorID et ifdProductID spécifiques au eToken PRO 64k. Une adaptation plus générique aurait été de spécifier ces valeurs pour tous les lecteurs présents dans openct.conf. Il est rare toutefois de changer de lecteurs de cartes ou de tokens assez fréquemment pour justifier une telle approche. Après modification, il suffira de relancer le démon PS/SC Lite. Ceci fait, la commande pcsc_scan, outil de détection de carte et d’information de PS/SC Lite, fonctionne très bien : Cette utilitaire reposant sur PC/SC Lite est donc parfaitement capable d’accéder à un eToken uniquement supporté par OpenCT. Oui, si maintenant vous spécifiez reader_drivers = pcsc; dans votre opensc.conf, cela fonctionnera, mais quel intérêt si ce n’est le plaisir de passer pas plus d’intermédiaires ?

    Tester le matériel

    Tout est configuré correctement et aucun message d’erreur ne vient vous alarmer. Comment savoir si le ou les lecteurs fonctionnent ainsi que la carte ? La réponse tient en trois lettres : ATR. Cet acronyme signifie Answer To Reset. C’est une chaîne de caractères envoyée par la carte lorsqu’elle est réinitialisée. Cet ATR permet non seulement de savoir que la carte répond et que le lecteur fonctionne, mais apporte aussi une information sur le type de carte et le système d’exploitation utilisé. N’oubliez pas, les puces des cartes intègrent un microprocesseur, de la mémoire, des E/S... tout un ensemble doté de son propre système d’exploitation. Pour vous assurez que tout fonctionne, voici quelques commandes. Vous pouvez, dans un premier temps, lister les lecteurs actuellement gérés par OpenCT : Vous pouvez ensuite tenter d’accéder à la smartcard en affichant son ATR et le nom associé : Ici c’est un eToken PRO 64k. Voici ce que nous obtenons avec une carte OpenPGP : Enfin, si la carte le permet, vous pouvez obtenir des informations plus complètes sur son système d’exploitation (une partie de la sortie a été ici supprimée) :

    Accessibilité du matériel

    Par accessibilité, j’entends la facilité pour un utilisateur de se procurer le matériel adéquat. C’est encore un vrai problème bien que des initiatives commencent à voir le jour de la part des constructeurs.L’acquisition d’un lecteur de carte est relativement aisée. On en trouve, en effet, facilement chez les détaillants de périphériques informatiques. Pour les petites bourses ou les utilisateurs souhaitant s’initier, les sites d’enchères en ligne sont une bonne solution pour peu que l’on ne souhaite pas acquérir le dernier lecteur à la mode. Il en va malheureusement tout autrement pour les smartcards elles-mêmes. Bien souvent, le choix se limite à soit faire appel à une SSII qui ne manquera pas d’essayer de vous fournir le service accompagnant le matériel, soit se tourner vers des boutiques étrangères où le port dépasse, bien souvent, le prix d’une ou plusieurs smartcards (Boutique Axalto). Mais la solution réside sans doute, tout simplement, dans l’attente, puisque le besoin est clairement présent et qui dit "besoin" dit "marché à prendre". Apparemment, Aladdin semble l’avoir compris et propose aux utilisateurs Windows une solution appelée "eToken WSO pour Web Sign On". Il s’agit d’un kit comprenant un eToken PRO 64k et un eToken NG-OTP, ainsi qu’un support logiciel pour Windows permettant de sécuriser les authentifications Web et le remplissage des formulaires en ligne (voir article sur les applications des smartcards). Cependant, pour l’heure, les distributeurs sont surtout des SSII et il faudra sans doute attendre pour voir apparaître des blisters dans les magasins ou les boutiques en ligne.

    Sécurité absolue ?

    Une smartcard ou un token USB représente-t-il une sécurité absolue ? Certainement pas. Même si l’on part du principe que la sécurité informatique totale n’est pas une illusion, ce type de solutions n’est qu’un début. "Mais la carte ne peut être violée et les renseignements qu’elle contient ne peuvent en être extraits", me direz-vous. Certes, mais n’oubliez pas que la sécurité d’un système réside dans la sécurité de chaque élément qui le compose et non dans un seul. Difficile de simuler une smartcard, c’est vrai, et en particulier les travaux qu’elle peut réaliser avec la clef privée qu’elle est seule à connaître. Mais qu’en est-il du système d’exploitation, des applications et des bibliothèques ? L’élément faible est là et la solution pour le renforcer est risquée en termes de libertés individuelles : le Trusted Computing (TC). La carte forme un élément sécurisé difficile, voire impossible à falsifier. On peut avoir confiance en la sécurité qu’elle apporte et dans les informations qu’elle fournit. Sans renforcement, on ne peut pas en dire autant du système d’exploitation. Un rootkit correctement conçu pourrait parfaitement se placer à n’importe quel point sensible, tromper l’utilisateur et lui dérober son code PIN. Pire encore, le rootkit pourrait faire en sorte que l’application croit avoir vérifié toutes les données alors qu’il n’en est rien. Bref, sur un système compromis, la sécurité apportée par une smartcard n’a plus aucun intérêt. Un doute ? Voyons un cas très simple. Vous créez un hash MD5 des fichiers critiques du système et vous signez le fichier MD5 avec la clef privée contenue dans la smartcard. Un attaquant compromet le système et installe un rootkit qui détourne l’interrogation de la carte vers un code dans le rootkit. Il remplace ensuite les fichiers critiques, génère un fichier MD5 correspondant et le signe avec sa clef privée. Lorsque vous vérifiez le fichier, vous croyez utiliser la clef publique contenue dans la carte, mais le rootkit intercepte la demande et utilise sa clef publique. Vous vous croyez à l’abri, mais ce n’est pas le cas. Bien entendu, vous pouvez trouver des parades (stocker le hash signé sur un CDR par exemple), mais le système est corrompu et l’attaquant peut parfaitement, lui aussi, trouver des parades (véroler les outils de vérification). L’utilisation de la smartcard n’apporte plus rien. Retour à la case départ. Pour se débarrasser du problème, il faut que l’utilisateur puisse avoir confiance en sa machine. Comprenez-moi bien, je parle d’un ordinateur qui est totalement maîtrisé par l’utilisateur et non d’un PC équipé d’un système d’exploitation propriétaire où la sécurité et la gestion d’accès sont confiées à l’éditeur. Dans ce type de contexte, si un module cryptographique est en mesure d’authentifier le BIOS, que ce dernier vérifie le bootloader qui lui-même s’assure de la validité du système (noyau, modules, scripts)... alors nous obtenons une chaîne de confiance dans laquelle un rootkit serait immédiatement repéré (à moins d’exploiter des failles éventuelles du module). Sans possibilité de compromettre le système, l’utilisation de la smartcard apporte à nouveau la sécurité mobile tant attendue. La présence d’un dispositif matériel de type TPM (Trusted Platform Module) est une solution pour obtenir un Trusted OS et une chaîne de confiance. Cependant, il faut également comprendre qu’un tel dispositif, si l’utilisateur n’a pas la maîtrise de l’ensemble, peut confier les clefs de votre système et de vos libertés à un éditeur de logiciels propriétaires. C’est le prix à payer et le paradoxe du Trusted Computing. La question pourrait se poser de savoir s’il faut ou non écarter de telles fonctionnalités, car le risque que l’utilisateur perde la maîtrise de son système est trop grand. Mais le choix a déjà été fait par l’industrie et les TPM commencent déjà à peupler nos cartes mères. Le mouvement est en route, la seule solution réside maintenant dans le choix des systèmes et des applications. Mais une solution existe pour renforcer vraiment la sécurité des systèmes. C’est déjà ça. Contrairement à ce qu’on pense généralement, la carte à puce n’est pas une invention française. Le premier brevet fut déposé en 1969 par deux allemands. Ce n’est qu’en 1974 que Roland Moreno dépose ses 47 brevets dans 11 pays. M. Moreno n’a donc pas inventé la carte à puce, mais l’a massivement brevetée. Il est possible que vous rencontriez un problème avec le support PC/SC Lite des lecteurs Omnikey. L’IfdHandler propriétaire accède au périphérique via /dev/usb/cm0, mais udev crée /dev/cm0. Vous devrez donc probablement ajouter une règle udev en précisant NAME="usb/%k" pour le périphérique. Liens [1] Patchs pour le pilote OmniKey : http://mirrors.ircam.fr/pub/kde-redhat/apt/livna.org/cm2020-kmod/devel/ Projet OpenSC : http://www.opensc-project.org/ Les eToken d’Aladdin : http://www.aladdin.fr/etoken/default.asp Axalto maintenant Gemalto et ancienne division carte de Schlumberger : http://www.axalto.com/France/ Homepage du projet MUSCLE : http://www.linuxnet.com/ Le bon vieux Smartcard Howto : http://www.linux.com/howtos/Smart-Card-HOWTO/index.shtml Définition Wikipédia pour "carte à puce" : http://fr.wikipedia.org/wiki/Carte_%C3%A0_puce
    Vous souhaitez commenter cet article ?
    Brèves Flux RSS
    Édito : GNU/Linux Magazine Hors-Série N°72
    Édito : Linux Pratique N°84
    Édito : MISC N°74
    Édito : GNU/Linux Magazine N°173
    Édito : MISC Hors-Série N°9
    Communication RSS Com. RSS Presse
    HACKITO ERGO SUM
    GNU/Linux Magazine, partenaire du SymfonyLive Paris
    Opensilicium, partenaire de RTS EMBEDDED
    Linux Pratique et Linux Essentiel, Partenaire de l’Open World Forum
    Gnu/Linux Magazine, Partenaire des JDEV 2013
    Rechercher un article dans notre base documentaire :
    Désolé, aucun article ne correspond à vos critères.