Howdy journal !

En ayant un peu marre de madwifi (ça, c'est pour la confession... honte à moi d'avoir utilisé un démon proprio) qui ne me faisait que des misères sur une Sid, j'ai décidé de tenter le coup avec ath5k (la Sid est repassée en Lenny depuis... c'est de toute façon le même kernel, pour l'heure... et puis j'en ai marre de faire tourner une Sid dans le salon, maintenant juste pour LCDproc... si jamais il était mis à jour pour Lenny, étant en exception de freeze [faut dire que c'est la même version, à une révision debianesque près, depuis Sarge... mon LCD/IR Imon ne demandant qu'un LCDproc 0.5, au moins], tant mieux... sinon, tant pis, ce sera sans... au pire, je me ferai moi-même le paquet, comme j'ai fait par le passé).




Au premier abord, si madwifi me donnait l'impression d'être très sensible au bruit ambiant (d'autant plus depuis que je suis passé au 2.6.26... je ne sais pourquoi), ath5k ne m'a pas enchanté plus que ça...

Le plus gros problème étant une variation cyclique de la vitesse de la connexion, de 1Mb/s à 54Mb/s et ainsi de suite, occasionnant moult coupures... ce qui est ballot, la bête (une AR2414 en PCI, de je ne sais plus quelle marque) étant dans mon HTPC, qui n'a bien évidemment pas besoin de ça...

... bref, un peu désappointant. Et c'est là que je me suis rappelé les heures de galère avec le chip broadcom des WRT54G (oui, oui... j'ai des orties dans mon jardin ; je me flagellerai avec... et puis, maintenant, c'est le seul, unique et dernier truc proprio qui tourne sur mes CPU - et je pense depuis un moment à m'en séparer), et les services que peut rendre iwconfig.

Un petit coup de "iwconfig wlan0 rate 24M" plus tard, afin de forcer la puce à se maintenir à un taux de transfert constant, là, c'est devenu le bonheur... j'ai expérimenté diverses valeurs, et ça donne à peu près ça :

24M --> ping -c 100 mon_routeur
1.034/1.348/4.182/0.495/0.495ms, avec aucun paquet perdu...
scp un_gros_truc.avi : 2,4Mio/s (!)

36M --> ping -c 100 mon_routeur
1.269/5.679/20.555/6.013ms, avec 93% de paquets perdus
scp un_gros_truc_2.avi : 300kio/s

Au-dessus, avec un taux fixe, je perds la connexion ("Destination host unreachable").

Sans rien toucher, j'avais entre 15 et 20% de paquets perdus, et le transfert via scp (ou fish, ou sshfs... je n'utilise que ça, pour transférer, gardant NFS pour la lecture seule) commençait fort, puis tendait vers zéro, avant de lamentablement bloquer, à moins que je ne fasse tourner le proc (par exemple, en mâtant une video, auquel cas, ça allait à ~1Mio/s... vraiment bizarre)...

Ca, c'était pour l'astuce (pas grand monde ne semble lire le forum, à ce que semble confirmer une récente dépêche [1] ... et puis bon, il y aussi de la confession... et puis du retour sur un module important ; de l'émotion fébrile, quoi ! En somme, c'est un journal... 'fin je crois ;) ).




Bref, en rajoutant un petit "post-up /sbin/iwconfig wlan0 rate 24M" dans mon /etc/network/interfaces, tout va bien, dans le meilleur des mondes... j'obtiens même, avec mes antennes +7dB, une qualité de signal de 100-110% (pas sûr que ce soit pertinent... pas plus que de ce que ça veut vraiment dire, ni en quelle unité c'est, s'il y en a une), là où avant, je peinais aux alentours des 50%.

Les miniatures des répertoires de MythVideo (chopées via NFS, sur le serveur de stockage) ont maintenant le poil brillant et apparaissent aussi vite que l'éclair (bon, j'exagère... disons que c'est quand même le jou[i]r et la nuit)...

Il faut toujours que je bufferise un peu avant de lire les videos via MPlayer (MythVideo ayant toujours autant de problèmes avec les MKV et le H.264, même dans le CVS de la 0.22, en fort joli QT4, que j'ai testé avant hier... je le réserve donc pour relire les MPEG-TS des enregistrements TNT, non indexés, et donc, assez peu maniables avec MPlayer... il est beaucoup plus pratique de les streamer du backend MythTV), mais beaucoup moins qu'avant (avant, je mettais un "cache=8192" dans le fichier de conf de MPlayer... maintenant, ça passe bien avec "cache=4096", voire "cache=2048"... et en plus, le transfert va beaucoup plus vite pendant la mise en cache).

Ce genre de soucis semble en outre être connu, comme en témoigne la page d'ath5k sur linuxwireless.org, où il est annoncé que le taux de transfert est censé chuter à 1MBps, par défaut, pour l'heure, et où il est précisé qu'on est censé pouvoir le fixer jusqu'à 11MBps...

... au final, avec mes 24MBps (réels, mais pas full-duplex, et en comptant l'overhead, étant en WPA2-PSK, de ce que j'en ai testé brièvement), je peux dire que ath5k, ça progresse, et que : "çaybonmangézan" !




[1] http://linuxfr.org/2008/09/08/24193.html
[2] http://linuxwireless.org/en/users/Drivers/ath5k

> Lire le journal (22 commentaires, moyenne: 2,5).

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

> Lire le journal (10 commentaires, moyenne: 2,7).

Howdy, Journal !



Peut-être connais-tu les télécommandes de la gamme Harmony... sinon, pour faire court, il s'agit de télécommandes universelles fabriquées par Logitech, plutôt bling-bling à tendance classieuse (de la télécommande de Président, farpaitement ! ) [1]...

La particularité la plus notable de ces petites bêtes est que leur configuration s'effectue via un site web [2], ce qui permet d'accéder à une grosse base de données de constructeurs (tout ce que j'ai, TV, récepteur AV, tuner TNT, récepteur IR en USB, est dans la base, sans avoir besoin de passer par quelque mode d'apprentissage que ce soit ; on peut quand même passer par un mode d'apprentissage au besoin, mais aussi configurer des macros, auxquelles on assigne un nom de tâche directement accessible via l'écran LCD). Une fois (et puis d'autres, encore, et encore, pour geekement affiner) la configuration effectuée en ligne, on peut alors télécharger un fichier la décrivant, à uploader dans la télécommande via USB.



Oui, mais voilà... si point de banquise n'était supportée, ce n'est tout de même pas le genre de chose que j'aurais achetée... Déjà qu'il faut faire avec une base de données proprio (qui peut disparaître du jour au lendemain), qu'il faut télécharger un firmware proprio (bon, ça, encore... et pourtant, je suis debianneux)... m'enfin, je relativise : 59€, port offert, pour une Harmony 555... je pourrai y survivre...

Par contre, sans le moindre support linuxien, ce serait plus difficile... et bien, si ce n'est pas chose pleinement accomplie, c'est pour le moins en bonne voie. Le projet Concordance [3] (enfin, pour l'instant, il s'appelle Harmony, mais la prochaine version, probablement 0.20, sera l'occasion d'un changement de nom, en plus d'un split entre le backend, faisant appel à libusb, et le frontend, l'officiel étant en ligne de commande, bien qu'une appli en QT soit aussi sur les rails [4]) vise en effet à permettre de configurer ces artefacts librement (j'annonce : dans une certaine mesure)...



Bien plus léger que l'homologue propriétaire (~100Mio une fois installé... ouch... l'appli libre que je présente se compilant en deux coups de cuiller à pot, et n'ayant pour cela besoin que de libusb-dev), Concordance (enfin, Harmony... enfin, vous suivez, j'imagine) est cela dit encore très jeune... il faudra en effet pour l'instant recourir à un OS propriétaire pour mettre à jour le firmware (propriétaire... décidément, quelle marotte ! ) de la télécommande, si celui-ci est plus vieux que ce que le portail Logitech exige... la mailing-list du projet fait cependant état de nombreux progrès pour intégrer cette fonction, et il semble que la version CVS puisse mettre à jour le firmware de certaines télécommandes.

Malgré tout, une fois cette mise à jour effectuée, on peut se créer un compte sur le portail web, effectuer sa configuration (en choisissant les appareils par modèles, en arrangeant les actions à enchaîner, ... ), et laisser notre petite appli jouer l'intermédiaire entre ledit portail et la télécommande... sous Linux, cette fois.

Par exemple, lorsque le portail (ouvert, mettons, dans Konqueror) demande à ce que la télécommande connectée en USB lui prouve sa présence, il nous permet de télécharger un fichier "Connectivity.EZHex" qu'un gracieux (ou pas), en tant que root (j'ai dit ou pas ! ) :
./harmony -t Connectivity.EZHex
va utiliser pour "prouver" au portail qu'une télécommande est bien branchée...

Le portail va alors permettre de télécharger le fichier de configuration "Update.EZHex" (il ne s'agit que de la configuration, pas du firmware complet) qu'un, ni plus, ni moins, gracieux (toujours en tant que root) :
./harmony -C Update.EZHex
va envoyer dans la télécommande en quelque secondes...

... et voilà : une télécommande configurée comme un manchot. Certes, ça ne manque pas encore de rugosité, le concept implique des contraintes inhérentes, mais bon, chezmoiçamarche© (enfin, pas avec la dernière stable, qui apporte apparemment une régression pour la 555, mais ça tourne avec la 0.12... désolé de ne pas avoir eu le temps de tester le CVS).



Pour terminer avec quelques mots (encore ! ) sur le projet, en tant que tel...

Niveau support, les modèles inférieurs à la 890 sont censés être supportés, bien que tous n'aient pas encore été testés [5]. Le projet a cela dit l'air plutôt actif, et le support de TCP-over-USB, nécessaire pour les modèles supérieurs semble être étudié [6].

Pour ce qui est de la documentation constructeur, c'est encore et toujours problématique... Phil Dibowitz, le développeur à l'origine de Concordance, a eu beau essayer de contacter Logitech en offrant de développer un support pour Linux [7], il semble que le silence radio soit malheureusement de mise, les quelques tentatives de contact s'étant semble-t-il soldées par un "peut-être, mais finalement : rateau"...

Cependant, Kevin Timmerman, un développeur visant à créer une interface (propriétaire), pour OS redmondien, permettant ambitieusement de supplanter le travail du site web de Logitech, avait déjà effectué une bonne partie de l'ingénierie inversée... et à défaut d'ouvrir tout son code, semble avoir beaucoup aidé Phil Dibowitz à mettre au point son backend, tant et si bien que Concordance se veut multi-plateforme (Windows, Linux, et, pour la 0.20, probablement, MacOS).

Bref (euh... façon de parler...), il y a des choses comme ça qui facilitent tout de même bien la vie d'un manchot (on sous-estime trop souvent la difficulté de jongler avec moult télécommandes quand on a des ailes atrophiées, tenant plus du moignon que d'autre chose)... si la perspective de dépendre d'une base de données propriétaire pour régler une télécommande bling-bling à tendance classieuse ne vous arrête pas, enjouaillez Concordance [8] (enfin, Harmony, pour l'instant ;) ).



[1] http://www.logitech.com/index.cfm/remotes/universal_remotes/(...)
[2] http://members.harmonyremote.com
[3] http://www.phildev.net/harmony/
[4] http://www.kde-apps.org/content/show.php/Koncordance?content(...)
[5] http://www.phildev.net/harmony/supported_models.shtml
[6] http://www.linux.com/feature/121149
[7] http://www.phildev.net/phil/blog/index.php?s=harmony&submit=(...)
[8] http://sourceforge.net/project/showfiles.php?group_id=201579

> Lire le journal (12 commentaires, moyenne: 2,6).