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

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