Journal Smartcard, X.509, OpenLDAP... et OpenSSH... pourquoi, monde cruel ?

Posté par .
Tags : aucun
0
27
mai
2008
Howdy, Journal !


C'est à la lecture d'un message dans la sous-partie "Astuces.divers" du forum [1] que je me suis décidé à t'écrire...


L'affirmation "Une passphrase sur une clé privé, c'est déjà de l'authentification forte" m'a tout particulièrement parue discutable (j'espère que l'auteur me pardonnera de répondre ici plutôt qu'à la suite de son message)...

Une clé privée avec passphrase, ce n'est pas vraiment quelque chose que l'on a et quelque chose que l'on sait, mais plutôt deux choses que l'on sait...

... la passphrase connue, le contenu de la clé privée est connu en clair... ce dont on n'a même pas besoin pour la dupliquer... on peut garder le fichier autant au chaud qu'on le veuille, il reste dupliquable (enfin, en principe), extractible, pour prendre son temps à faire sauter les deux remparts (la passphrase, et la nécessité de connaître la clé déchiffrée), sans pour autant devoir posséder autre chose...


Avec une smartcard, par exemple, si l'on y génère un couple de clés en interne, pas moyen de la récupérer, la clé privée... la clé n'est pas dupliquable, et il faut donc bien posséder quelque chose.

Après, la clé protégée par un PIN, c'est le "quelque chose à savoir"... la sécurité est d'autant plus élevée qu'au bout d'un certain nombre d'essai (3 a priori), la smartcard est bloquée (le PUK peut la réinitialiser, mais il faudra a priori régénérer les clés)... avec l'utilisation de certificat, ça offre une répudiation facile (ce que n'offrent par exemple pas des token OTP basés sur le temps, à moins d'encore avoir le token et de pouvoir le détruire physiquement, ce qui n'est pas nécessairement possible)...


Donc, non, de la clé privée avec passphrase, je ne vois pas vraiment ça comme de l'authentification forte... à la limite, on pourrait plutôt parler d'émulation logicielle d'authentification forte, ou de double secret à connaître.





Malheureusement, le support des smartcards (je ne connais pas grand chose au sujet des OTP) dans OpenSSH (dont il est question dans le sujet originel), ce n'est pas terrible...

Il y a officiellement un support pour OpenSC, dans OpenSSH, mais il ne prend pas en compte la demande d'un PIN, plutôt que d'un mot de passe (du coup, il faut patcher avec des sources que l'on trouve dans celles d'OpenSC, ce qu'utilise par exemple Gentoo, bien qu'elles soient qualifiées de "crude-hack" ["contournement grossier"] dans le "README" qui les accompagne, par leurs auteurs).

Sinon, il y a des patches non officiels qui essaient de s'intégrer upstream, notamment pour apporter le support de PKCS#11 (standard d'opérations cryptographiques via smartcard), de X.509, et de la distribution des clés via OpenLDAP (cf patches de Alon Bar-Lev [2] et de Roumen Petrov [3]).


Avec ça, on aurait authentification forte, avec facilités de répudiation. Mais bon, upstream, ie chez OpenSSH, n'a pas l'air très chaud pour intégrer ça de base, fut-ce dans la version "portable" (un autre patch OpenLDAP, ie le patch LPK n'a pas trouvé sa voie upstream non plus... ce qui a valu la perte du support d'Inverse Path Ltd, frustré de la non-communication d'upstream [4])... et comme la plupart des distros ne veulent pas (plus...) patcher OpenSSH avec de l'externe... on se mord la queue...

... et c'est vraiment dommage, parce que "oui!", du token crypto aurait permis, après la merde récente sur OpenSSL chez Debian, en se servant de clés RSA, d'avoir des clés générées proprement (dans la smartcard), et qui n'auraient pas dues être recrées, à moins que, par un incongru hasard, elles aient fait partie des clés à faible entropie (bien que du coup, le patch X.509+OpenLDAP de Roumen Petrov aurait permis des facilités de bannissement/redéploiement indéniables)...

C'est là que j'ai honte d'avouer que le bugreport que j'avais préparé avec tant d'amour, pour ma distro de prédilection [5], ait une si sale gueule... j'étais sur un PC sur lequel Kmail n'était pas configuré, et après avoir lancé reportbug-ng, pour formater mon mail comme il faut, je me dis : "Allez zou ! Je copie-colle dans yahoo mail, je l'envoie au daemon à bugs de Debian, et ça va le faire"... prout ! (que tu me le permettes ou pas, cher Journal)... chaque paragraphe sur une ligne... j'ai honte : je ne sais pas ce que j'ai pu foutre pour que ça aie cette gueule là, mais je ne me fais pas trop d'illusions sur le fait que ce sera beaucoup lu (déjà que c'est long... oui, je sais, c'est une maniaquerie : j'ai une ferme tendance au flood)...


M'enfin, l'idée était de préciser ce qu'il en est de l'antique et boitilleux support officiel d'OpenSC, et de souhaiter la création d'autres paquets, prenant en compte les patches PKCS#11 et X.509 (qui permet de la distribution via OpenLDAP aussi)...

OpenSSH est génial (je n'ai pas encore testé le support des chroots au login du 4.8p1, mais j'ai hâte), mais il pourrait être encore mieux... plus sécurisé grâce à PKCS#11, et plus gérable pour ce qui est des clés publiques autorisées grâce à X.509/OpenLDAP... des choses qui auraient pu permettre de réduire à néant l'impact du bug de packaging d'OpenSSL (j'ai fait les fraies de la plaie ; c'est aussi la mienne : je la remue si je veux)... d'autant que de plus en plus d'applications ont désormais une forme de support pour PKCS#11, au moins via le patching (OpenSSL [6], OpenVPN [7], GnuTLS [8], ... OpenSSH et autres [9])...

Mais voilà : pour le shell distant, upstream fait le sourd, et les distros font les aveugles quant à ce qui est de ces patches... ce n'est pas un coup de gueule, mais juste un souhait, que soit généralisé, au pire, un paquet openssh-pki, distinct, qui intègrerait ces deux patches, qui sont d'ailleurs écrits de façon à pouvoir fonctionner ensemble (Gentoo permet d'activer le support X.509, via le useflag idoine, mais pour ce qui est des smartcards, ils utilisent le patch goretto de chez OpenSC, bien qu'ils aient répondu à Alon Bar-Lev qu'ils ne voulaient plus rajouter des patches externes dans des paquets cruciaux comme ça, ce qui peut se comprendre, qu'on soit ou pas en ces temps d'après-mega-boulette Debianneuse).

Cela dit, si quelqu'un a le courage d'ouvrir mon bugreport de manière à le rendre lisible, et si ce quelqu'un le trouve intéressant et a les capacités de produire un patch à l'OpenSSH de Debian pour intégrer les deux que j'ai cités (capacités que je n'estime pas suffisamment avoir), pour étoffer le bugreport, et qu'il voulait bien le publier, qu'il ne se gêne pas ;)

Bon, voilà, ça, c'est fait...





Maintenant, Journal, je vais quand même faire une petite disgression sur le matériel qu'il est possible d'acquérir, pour jouer avec ce qui peut fournir de l'authentification forte... et plus particulièrement les smartcards...

Cela fait maintenant quelques années que me trotte l'idée de générer mes clés privées dans un coffre fort dont on ne peut les faire quitter (au mieux est-il possible de les effacer ou de s'authentifier/chiffrer/signer avec elles)... mais qu'en est-il sur la banquise ?

Et bien, tout d'abord, peu de cartes sont compatibles avec Linux, sans recourir à un middleware (un composant logiciel permettant de fournir une interface PKCS#11 vis à vis de l'OS qui tourne lui-même sur la smartcard, qui est factuellement un mini-ordinateur spécialisé dans la cryptographie) proprio, afin de pouvoir dialoguer avec elle... notons que le support de PKCS#11 ne permet que de réaliser des opérations cryptographiques (authentifier/chiffrer/signer), et pas de gérer les informations sur la carte elle-même (effacer des banques de données, changer les PIN, réinitialiser la carte), ce qui est le rôle de PKCS#15.


Eh bien, pour ce qui est des smartcards qui semblent être bien supportées, c'est assez pauvre : pour ce que j'ai trouvé qui se vend encore, il semble qu'il faille se diriger vers des versions particulières des Cryptoflex E-Gate 32K, qui, contrairement à certaines versions des Aladdin Etoken Pro32k (non, toutes les versions, fonction de quel OS embarque la carte, ne sont pas supportées), permettent la gestion des clés RSA de 2048 bits, ce qui est le top-moumoute qu'il semble qu'on puisse atteindre sur un client où tout est libre (à défaut de l'OS de la smartcard, mais on n'est plus vraiment sur le client... bien qu'une SmartCard complètement libre, jusqu'à ses spécifications détaillées, serait bougrement sexy).

A noter d'ailleurs que la boutique outre-Atlanticienne où j'ai trouvé ces artefacts en vente a une section dédiée à Linux [10], dans laquelle on peut d'ailleurs remarquer que tout ce qui est cartes récentes ne nous est pas conseillé... d'ailleurs, l'utilitaire pkcs15-init, du projet OpenSC, ne gère même pas, par exemple, les clés AES, que beaucoup de nouvelles smartcards peuvent manipuler.


Alors oui, une smartcard, OK, mais faut un lecteur (puisqu'il n'est pas intégré aux Cryptoflex, comme il l'est aux Etoken)... de ce côté, c'est plus simple : tout ce qui supporte la norme CCID [11] est censé pouvoir fonctionner... on peut aussi passer par OpenCT [12], via un wrapper CCID, ou non, bien que le support de matériel via d'autres méthodes semble moins large.

Et là, c'est chez Etronsec [13] que j'ai trouvé ce qui m'attirerait le plus : du lecteur de SIM et/ou de smartcard classique, combiné à de la clé USB à mémoire flash.

Avec ça, j'imagine tout un tas de libertés d’esprit cosmique vers un nouvel âge réminiscent ! Comme avoir une clé USB avec une SIM, qui me permettrait de me connecter à une machine, peut-être via un VPN, pour faire les mises à jour et la maintenance courante, dans laquelle je pourrais insérer une autre smartcard au format classique, que je garderais dans mon portefeuille, et qui me donnerait des droits autrement plus touffus. D'autres imagineront se servir d'une smartcard pour simplement se loguer [14], accéder via LUKS [15] à leur /root ou Pr0N chiffré, éventuellement en passant par SFTP ou SSHFS, ou que sais-je encore ? "Ré-mi-ni-scent", que j'ai dit !





Bref, tu l'auras compris, Journal, je vais craquer prochainement pour de la smartcard et le lecteur-kivabien, ne serait-ce que pour tester, notamment avec OpenSSL et OpenVPN... J'essaierais probablement aussi de bidouiller OpenSSH (en me réinstallant peut-être une Gentoo, au passage... c'est vrai que ça fait longtemps...)... mais c'est une toute autre histoire, et chaque chose en son temps.

L'existant ne semble pas très utilisé, bien qu'apparemment fonctionnel... mais du coup, on n'en parle pas trop et ce n'est pas très connu... tant et si bien qu'encore récemment (ça arrive une fois par an à peu près), quelqu'un a réouvert un bug chez Debian pour demander le support d'OpenSC (j'y ai dailleurs moi-même pensé aussi, avant de chercher à me renseigner un poil plus, pour finalement pondre un bugreport tout mal formaté), qui n'a en fait jamais été trop propre... bref, si vous vous le sentez de faire de la pub ou du taf dans votre distro pour ça, ou d'acheter de la smartcard pour tester, voilà un peu les infos sur ce qu'il est possible de faire, et avec quoi, que j'ai pu récolter récemment...





[1] http://linuxfr.org/forums/47/25192.html
[2] http://alon.barlev.googlepages.com/openssh-pkcs11
[3] http://roumenpetrov.info/openssh/
[4] http://dev.inversepath.com/trac/openssh-lpk
[5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482806
[6] http://www.opensc-project.org/engine_pkcs11/wiki/QuickStart
[7] http://openvpn.net/index.php/documentation/howto.html#pkcs11
[8] http://alon.barlev.googlepages.com/gnutls-pkcs11
[9] http://alon.barlev.googlepages.com/open-source
[10] http://www.usasmartcard.com/component/page,shop.browse/categ(...)
[11] http://pcsclite.alioth.debian.org/ccid.html
[12] http://www.opensc-project.org/openct/
[13] http://www.eutronsec.it/infosecurity/Contents/ProductLine/De(...)
[14] http://www.opensc-project.org/pam_pkcs11/
[15] http://www.etokenonlinux.org/et/HowTos/eToken_and_LUKS
  • # c'est bien, mais j'ai pas tout compris

    Posté par . Évalué à 6.

    Bon, au fil de la lecture, j'ai compris des choses, mais vu que tu as tendance à flooder, tu aurais pu faire une jolie intro sur les smartcards, les sim et autres bestioles, car perso je ne suis pas au fait de ces trucs là, et je pense ne pas être le seul.

    Et pour améliorer les choses, rédige comme si tu écrivais un article, avec des sections etc. ça sera plus lisible, vu que tu avais plein de choses à dire.

    Sinon, j'ai lu jusqu'au bout et j'ai bien aimé le sujet, merci
    • [^] # Re: c'est bien, mais j'ai pas tout compris

      Posté par . Évalué à 2.

      C'est vrai que j'ai un peu retranscrit mes trips du moment pèle-mêle, aussi ;)

      Disons qu'à la base j'aurais plutôt voulu attendre de recevoir les smartcards et d'avoir joué avec elles avant de faire un journal... puis, voulant réagir au message du forum, et quand même faire partager ce que j'avais pu comprendre de la problématique, j'ai un peu tout enchaîné d'un trait.

      Sinon, si ce que j'ai évoqué, sur le fait que les smartcards sont en fait des ordinateurs crypto qui gèrent des clés (notamment RSA) et la manière de s'en servir, pour ne jamais les exposer et faire de la smartcard quelque chose que l'on possède, il y a deux bons articles sur UnixGarden [1] [2], originellement parus dans Linux Magazine qui donnent un bon aperçu de ce dont il s'agit... mea culpa de ne pas les avoir mis en lien, pour débroussailler le sujet.

      Et je prends bonne note pour les sections : à ce stade de flood, mettre un peu plus de retours à la ligne, pour vaguement tenter de séparer, ne rend ostensiblement pas les choses assez claires...



      [1] http://www.unixgarden.com/index.php/securite/gestion-des-sma(...)
      [2] http://www.unixgarden.com/index.php/securite/smartcards-appl(...)
  • # Basiccard

    Posté par (page perso) . Évalué à 2.

    Tu devrais te pencher sur les basiccard :

    http://www.basiccard.de/

    Malgré le nom un peu effrayant, ce sont des cartes faciles à programmer. Il doit être possible d'en faire une carte PKCS#11. Après, elles doivent pouvoir être intégrées avec un simple lecteur PC/SC à coup de MUSCLE dans du Linux.

    Tout ça, c'est de la théorie, mais pour une âme motivée, il n'y a pas d'obstacle majeur à la mise en pratique.
    • [^] # Re: Basiccard

      Posté par . Évalué à 2.

      Tiens, c'est rigolo : elles gèrent les courbes elliptiques... et aussi AES. Par contre, RSA seulement en 1024 bits...

      Vu que RSA est l'essentiel de ce que j'utilise, et que le peu de support pour les smartcards que l'on a semble se concentrer sur cet algo, je pense que je vais aller au plus simple en restant sur les Cryptoflex.
  • # Sécurité physique

    Posté par . Évalué à 3.

    Tout d'abord merci pour cet article, je suis justement à la recherche de solutions de cartes à puces libres.

    Juste une remarque pour préciser la protection physique des cartes à puces : est-ce que les cartes dont tu parles sont certifiées, et si oui à quel niveau ? Parce que les attaques sur les cartes à puce notamment par canaux cachés, bien que pas à la disposition de Mme Michu, sont très efficaces et accessibles en pratique (notamment ceux qui chercheraient à attaquer la phrase de passe).
    bref encore une fois en matière de sécurité, contre quoi cherches-tu à te protéger ?
    • [^] # Re: Sécurité physique

      Posté par . Évalué à 3.

      Alors, niveau certification, je n'en sais rien : comme je l'ai dit, je voudrais d'abord jouer avec... quant à me protéger, de rien d'autre que de ma paranoïa : je me prophylaxise joyeusement, c'est tout.



      ... mais en effet, le principe d'inviolabilité, si on n'a pas les specs complètes des cartes (et encore, faudrait aussi être sûr que le produit correspond aux spécifications), rien ne nous garantit qu'il n'est pas rendu caduque par une backdoor du constructeur ou des hacks de spécialistes, voire les Chinois du FBI.

      J'ai juste essayé de trouver de quoi gérer du RSA 2048 bits sous linux, sans middleware proprio, et à part les Cryptoflex, je n'ai rien vu... idéalement, j'aurais aimé trouver quelque chose qui gère aussi l'AES (même si bon... apparemment, les outils sous Linux ne sont pas trop faits pour ça)...



      M'enfin, déjà, le fait d'avoir une smartcard pour stocker mes clés privées (et plein d'autres trucs, avec le lecteur combiné à de la flash, et aussi la possibilité de stocker autre chose que des clés privées, en tant qu'objets privés accessibles via un PIN), ça me forcera toujours à y faire plus attention (artefact précieux, perte définitive des clés privées si on fait trop le con, nombre d'écritures probablement limité, nécessité de commander outre-Atlantique, ...), tout en augmentant le degré de sécurité par rapport à des clés à pasphrase qui peuvent trop facilement traîner n'importe où, voire qui peuvent même avoir été générées sur une Debian.
  • # Carte OpenPGP

    Posté par . Évalué à 2.

    Tu peux aussi voir du côté des cartes OpenPGP:
    http://www.g10code.de/p-card.html

    Pour le lecteur, j'utilise un SCM SCR-335 et tout fonctionne parfaitement une fois les paquets PC/SC installés.

    Je n'ai pas d'action chez eux, mais Kernel Concepts propose à la fois des cartes et des lecteurs qui fonctionnent avec GPG (en plus ils sont sympa :)
    http://www.kernelconcepts.de/shop/products/security.shtml?ha(...)


    Sinon une dépense utile c'est d'adhérer au programme « Fellowship » de la FSF Europe.
    Chaque « fellow » reçoit une carte OpenPGP à son nom
    http://www.fsfe.org/en/card

    Tu n'aura plus qu'à te procurer le lecteur et à toi les joies de l'authentification forte :)
  • # tpm

    Posté par . Évalué à 3.

    Et les tpm que l'on commence à voir sur certaines machines, elles ne sont pas capables de gérer des clefs comme les smartcards ?
    • [^] # Re: tpm

      Posté par . Évalué à 2.

      A priori, ce devrait en être capable...

      ... par contre, il faudrait sûrement une interface PKCS#11 pour en tirer partie sous une majorité de logiciels où ça pourrait être utile...

      Je ne sais d'ailleurs pas si les puces TPM et cie sont déjà supportées sous Linux...



      Par ailleurs, je ne trouve pas très pratique que les clés doivent être laissées dans une carte mère, pour ce qui est des clés SSH, des clés de signature, et cie : je trouve plus sécurisante l'idée de trimballer sur moi (ou de cacher physiquement) le "quelque chose que je possède", plutôt que de le laisser sur la machine ; parce que, niveau "quelque chose que je possède", une machine, c'est lourd, et plus difficile à garder du coin de l'oeil que quelque chose que je garderais la plupart du temps près de mes parties intimes, quand même...

      ... scénario type : mettons que je me serve d'une smartcard pour déchiffrer mon / ainsi que me logger, et de l'espace sur la clé USB pour mettre le /boot (histoire qu'il ne se fasse pas corrompre pour chopper le PIN). Je pars boire un café ou je vais satisfaire quelque autre besoin naturel (ou pas) : si c'est une smartcard que l'on peut dé-brancher, pas de souci, je verrouille ma session (en faisant en sorte d'avoir besoin de la smartcard pour la déverouiller) et j'emporte le token - il reste quelque chose à posséder et à connaître qui n'est absolument pas sur place... mettons que je me serve de la puce TPM de la mobo pour stocker les mêmes clés : ce qu'il faut protéger et ce qu'il faut posséder sont alors la même chose - ne reste vraiment qu'à connaître le PIN pour se servir de la machine... l'authentification forte, elle en devient borderline (même si la clé ne peut théoriquement pas être extraite... ce sur quoi j'ai des doutes, aussi bien pour les smartcards externe que pour TPM, mais qui m'inquiète beaucoup plus pour le dernier, vu que cacher la machine pour que n'importe quel grouillot n'en vienne pas à la posséder, ce n'est pas ce qu'il y a de plus simple...)...

      Bon, après, ça dépend des usages... là où je verrais plus l'intérêt d'utiliser ces puces TPM, ce serait pour des choses de l'ordre des clés identifiant la machine dans SSH, d'avantage que pour les clés permettant de s'y connecter.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.