L’idée est simple : si mon Mir:ror est connecté à l’ordinateur et qu’un fichier contenant mon rfid est présent dans mon répertoire, je veux pouvoir ouvrir ma session à l’aide d’une puce RFID (carte, badge, ztamp:s, laaaaapin…) à la place de saisir mon mot de passe.

Je ne vais pas m’attarder ici à décrire la manière dont est codé le module, je vous laisse le soin de lire les sources… Je vais me contenter d’expliquer son installation et son utilisation.

Mise en garde :

Pour plusieurs raisons dont la simplification du module et mes piètres talents de développeur, il va sans dire que ce petit programme ne doit pas être utilisé en environnement sécurisé. Par contre, pour la maison, c’est plutôt fun !

Nous touchons ici à une partie sensible du système : l’authentification. Les manipulations ci-dessous sont donc à réaliser avec prudence.

Compilation :

Pour pouvoir compiler pam_mir-ror, il nous faut installer un version récente de la librairie de développement pam (libpam-dev). J’ai utilisé la version 1.0.1 proposée par défaut sous Debian Lenny.

$ sudo aptitude install libpam-dev

L’archive contenant les sources est téléchargeable ci-dessous :

• pam_mir-ror.0.2.tar.gz

Une fois téléchargée, il faut la décompresser et tout simplement lancer la commande « make ».

$ tar -xvzf pam_mir-ror.0.2.tar.gz
$ cd pam_mir-ror.0.2
$ make

Si tout se passe bien, nous devrions obtenir deux binaires :

• read_mir-ror : Un petit outil permettant la lecture à partir du Mir:ror,
• pam_mir-ror.so : Le module pam.

read_mir-ror

Le petit outil read_mir-ror va nous permettre de tester le lecteur. Il suffit de l’exécuter et d’approcher une puce rfid.

$ sudo ./read_mirror
0000D0081A025303420200D2

La série de chiffres affichée n’est rien d’autre que l’ID de l’objet détecté.

Il est préférable d’utiliser read_mirror avec les droits root, au moins la première fois, pour l’accès au périphérique mir:ror. Par défaut, le mir:ror n’est accessible que par root. Les droits du handler sont changés à la première utilisation de la fonction de détection (inclue dans l’outil et le module). Il serait certainement plus propre de coder un petit outil qui serait automatiquement lancé par udev ou hotplug au branchement du Mir:ror, mais pour un module PAM, ce n’est pas très important.

Génération du fichier utilisateur

Le même outil (read_mir-ror), va nous permettre de générer le fichier .authtag contenant le rfid propre à chaque utilisateur :

Pour l’utilisateur courant :

$ sudo ./read_mirror > ~/.authtag
$ sudo chmod 400 ~/.authtag

Pour un autre utilisateur  (toto):

$ sudo ./read_mirror > /home/toto/.authtag
$ sudo chmod 400 /home/toto/.authtag

Il faut bien entendu présenter la puce au lecteur juste après la commande ./read_mirror.
Le fichier .authtag doit maintenant contenir le tag :

$ cat ~/.authtag
0000D0081A025303420200D2

Module PAM  :  pam_mir:ror.so

Pour qu’il soit utilisable par PAM, il faut que pam_mir:ror.so soit présent dans /lib/security (lib64/security pour une architecture 64 bits)

$ sudo cp pam_mir-ror.so /lib/security

ou pour un module 64 bits :

$ sudo cp pam_mir-ror.so /lib64/security

La dernière étape va être l’ajout du module à PAM. Pour cela, il nous faut éditer le fichier :
/etc/pam.d/common-auth pour y ajouter, avant les modules pam_unix.so ou pam_unix2.so :

auth             sufficient         pam_mir-ror.so

/etc/pam.d/common-auth

#
# /etc/pam.d/common-auth - authentication settings common to all services
...
auth    sufficient                      pam_mir-ror.so
# here are the per-package modules (the "Primary" block)
auth    [success=1 default=ignore]      pam_unix.so nullok_secure
# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth    required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config

Avant de rebooter frénétiquement la machine pour voir ce que ça peut donner avec gdm,  je conseille vivement de tester sur une console (crtl-alt-F1 par exemple)… Comme expliqué en début d’article, nous touchons ici à une partie sensible du système et c’est mieux de garder la main pour éviter des pirouettes telles qu’un redémarrage en single user ou à partir d’un liveCD pour réparer.

J’ai fait en sorte que le module loggue un minimum. En fonction du système, ces logs sont visibles dans /var/log/auth.log ou /var/log/syslog.

Dernière version des sources : pam_mir-ror.0.2.tar.gz

]]> http://www.jopa.fr/index.php/2009/07/16/linux-pam-et-mirror-une-authentification-rfid/feed/ 11 http://www.jopa.fr/index.php/2009/07/12/violet-mirror-acces-device-c/ http://www.jopa.fr/index.php/2009/07/12/violet-mirror-acces-device-c/#comments Sun, 12 Jul 2009 00:22:12 +0000 Jopa http://www.jopa.fr/?p=1415 Dans mon précédent article, je présentais mir:ror, le petit lecteur RFID commercialisé par la société Violet.  Après avoir survolé leur application « Mirware » et mis en évidence les limites de son utilisation, je vais mettre « les mains dans le cambouis » pour essayer de comprendre comment communiquer avec Mir:ror.  L’idée étant de pouvoir coder de petits outils capables de réagir à des tags RFID.

D’un point de vu système, Mir:ror est directement reconnu sous Linux et accessible via le handler de périphérique /dev/hidrawX (où X est le numéro de périphérique, normalement « 0″ si c’est le premier appareil du genre connecté).

La petite application « discover-device« , fournie avec Mirware, permet de le détecter automatiquement :

Attention tout de même aux droits, le périphérique n’est par défaut accessible que par root, il faudra lui changer les droits ou utiliser le script « installer.sh » pour le faire, avant de pouvoir l’exploiter avec un utilisateur standard.

Commençons par voir ce qu’il se passe avec un simple « cat » du fichier :

Des hiéroglyphes s’affichent lorsque nous approchons ou retirons un tag… C’est plutôt bon signe, et visiblement c’est binaire ! Nous devrions y voir plus clair avec un affichage en hexadécimal.  Hexdump est idéal pour ça !

La première ligne (0000 0000 0000 0000 0000 0000 0000 0000 *) nous indique que tant qu’il ne se passe rien, on lit des zéros… Où…Qu’on lit des zéros tant qu’il ne se passe rien ! (c’est plutôt normal).
Les deux lignes suivantes (0102 0000 d008 1a02 5303 4202 00d2 0000 – 0000 0000 0000 0000 0000 0000 0000 0000) s’affichent lorsqu’un tag est approché, les deux dernières ( 0202 0000 d008 1a02 5303 4202 00d2 0000 – 0000 0000 0000 0000 0000 0000 0000 0000 ) lorsqu’on éloigne le tag.

Après plusieurs tests, j’en déduis assez facilement que les deux premiers octets (0102 ou 0202) codent l’évènement. J’en ai repéré 4 types :

• 0×0102 : Tag rfid détecté,
• 0×0202 : Tag rfid retiré,
• 0×0501 : Le mir:ror est mis à l’envert,
• 0×0401 : Le mir:ror est remis à l’endroit.

Les 12 octets suivants semblent identifier la puce RFID.

A titre de test, écrivons rapidement un petit bout de code C, prenant le device en paramètre et affichant les évènements et le tag associé :

// Jopa - Petit test du Mir:ror : test_mirror.c
#include <stdio.h>
#include <stdlib.h>
 
int main(int argc, char *argv[]) {
  FILE *mirror;
  short unsigned int block;
  short unsigned int event;
  char tag[25];
  int i;
 
  //Vérification du paramètre (device)
  if (argc!=2) {
        printf ("Usage : %s mirror_device \n\n",argv[0]);
        exit(-1);
  }
 
  // Ouverture du fichier device
  mirror = fopen(argv[1],"rb");
  if (!mirror) {
        printf("Accès à  %s impossible !\n",argv[1]);
        exit(-1);
  }
 
  // Boucle en lecture
  while (1) {
     fread(&event,2,1,mirror);
     if (event!=0) {
        // Evenement detecté, lecture de l'ID
        for (i=0;i<6;i++) {
            fread(&block,2,1,mirror);
            sprintf(&tag[i*4],"%04X",block);
        }
 
 //Affichage en fonction de l'événement
        switch (event) {
            // Tag On
            case 0x102 :
                printf("%s : ON\n",tag);
                break;
 
             //Tag Off
             case 0x202 :
                 printf("%s : OFF\n",tag);
                 break;
 
             //Mirror envers
             case 0x501 :
                 printf("MIR:ROR ENVERS\n");
                 break;
 
             //Mirror endroit
             case 0x401 :
                   printf("MIR:ROR ENDROIT\n");
                    break;
 
             //Default
             default :
                   printf("Evénement inconnu\n");
        } //switch
      } //if (event
   } //while (1)
} // main()

En quelques lignes, nous ouvrons le périphérique dont le handler est passé en paramètre et bouclons sur sa lecture, 2 octets par 2 octets.
Quand autre chose que « 0″ est détecté, c’est forcément un changement d’état. Nous lisons ensuite l’identifiant de la puce RFID.
La dernière partie affiche un message en fonction de l’évènement détecté.

Il ne reste plus qu’à le compiler et le tester :
$ gcc test_mirror.c -o test_mirror
$ ./test_mirror

Pour compléter l’exemple, nous pouvons rajouter l’exécution d’un script associé au tag et à son approche ou son éloignement. Les scripts pourraient être stockés dans le répertoire de l’utilisateur et porter l’<id>-on.sh ou l’<id>-off.sh comme nom. Pour l’exemple :

• 0000D0081A025303420200D2-on.sh : Lancement de Firefox sur le blog de Jopa

#!/bin/sh
firefox http://www.jopa.fr

• 0000D0081A025303420200D2-off.sh : Lancement de Thunderbird

#!/bin/sh
thunderbird

$ chmod +x ~/0000D0081A025303420200D2-*.sh

Adaptons un peu le code en ajoutant une variable pour le nom du script et une commande « system » dans le « switch/case ».

   // Jopa - Test Mir:ror
 
#include <stdio.h>
#include <stdlib.h>
 
int main(int argc, char *argv[]) {
  FILE *mirror;
  short unsigned int block;
  short unsigned int event;
  char tag[25];
  // Ajout d'un variable script
  char script[256];
  int i;
 
  //Vérification du paramètre (device)
  if (argc!=2) {
        printf ("Usage : %s mirror_device \n\n",argv[0]);
        exit(-1);
  }
 
  // Ouverture du fichier device
  mirror = fopen(argv[1],"rb");
  if (!mirror) {
        printf("Accès à  %s impossible !\n",argv[1]);
        exit(-1);
  }
 
  // Boucle en lecture
  while (1) {
     fread(&event,2,1,mirror);
     if (event!=0) {
        // Evenement detecté, lecture de l'ID
        for (i=0;i<6;i++) {
            fread(&block,2,1,mirror);
            sprintf(&tag[i*4],"%04X",block);
        }
 
 //Affichage en fonction de l'événement
        switch (event) {
            // Tag On
            case 0x102 :
                printf("%s : ON\n",tag);
                //Construction du nom de script et exécution
                sprintf(script,"./%s-on.sh",tag);
                system(script);
                break;
 
             //Tag Off
             case 0x202 :
                 printf("%s : OFF\n",tag);
                 //Construction du nom de script et exécution
                 sprintf(script,"./%s-off.sh",tag);
                 system(script);
                 break;
 
             //Mirror envers
             case 0x501 :
                 printf("MIR:ROR ENVERS\n");
                 break;
 
             //Mirror endroit
             case 0x401 :
                   printf("MIR:ROR ENDROIT\n");
                    break;
 
             //Default
             default :
                   printf("Evénement inconnu");
        } //switch
      } //if (event
   } //while (1)
} // main()

Ceci n’est bien entendu qu’un exemple, écrit rapidement et pas forcément très propre. Mais il permet de mettre en évidence la simplicité avec laquelle il est possible d’accéder à des informations RFID et ouvre la porte sur des développements qui peuvent être rapidement prometteurs.

Question coût, le mir:ror se trouve un peu partout pour un 50ène d’euros. J’ai déniché le mien en solde pour moins de 30 € – Tu vois chérie, moi aussi le fais les soldes  !!! – Dans un joli coffret, sont rangés le lecteur usb, 3 « timbres » autocollants (Ztamp:s) et 2 petits lapins (Nano:Ztag), tous munis d’une puce RFID.

Le lecteur fonctionne biensûr avec les objets commercialisés par Violet, mais aussi avec n’importe quel tags RFID, pourvu qu’il  respecte la norme ISO 14443 A ou B – La carte de bus/métro de Toulouse fonctionne parfaitement par exemple.

En utilisation standard, moyennant l’installation d’un petit logiciel (Mirware) et la création d’un compte (gratuit) sur le site de Violet, nous pourrons enregistrer nos objets RFID et associer une action à leur approche ou leur éloignement du lecteur.

Après tout ce vocabulaire « Nabaztanique« , il faut bien que j’avoue que ce n’est pas pour son utilisation standard que j’ai craqué, mais pour  les  perspectives prometteuses  offertes en terme de bidouillage : Authentification pam, évènements domotiques (X10), clef de chiffrement, on peut imaginer énormément d’usages « non-officiels » … et c’est ça qui est bon !

Néanmoins, dans la suite du billet, je vais balayer une installation classique du « Mirware » sous Linux. Il faut bien commencer par là ! Cette manipulation ne présente pas de difficulté particulière, à part peut-être pour les architectures 64 bits. Dans un prochain article, je m’intéresserai au développements possibles autour du joujou !

Mirware mon beau Mirware…

J’ai réalisé ce test sur deux machines sous Ubuntu (9.04 « Jaunty jackalope » ), l’une en 32 bits, l’autre en 64. Mais Mirware devrait fonctionner sous n’importe quelle distribution, le tout étant de bien installer les librairies nécessaires.

Dans les pré-requis, il faut bien entendu une machine sous Linux, disposant d’une interface graphique et connectée à Internet. En effet, Mirware fonctionne grâce au serveur Violet.net, sur lequel seront enregistrés les tags et les actions qui leurs sont associées.  C’est un peu limitant, mais comment dire….c’est comme ça ! Domage !

L’application est disponible ici en version alpha… On regrettera l’absence des sources, mis à part pour la partie concernant la détection du périphérique, ce qui va sauver l’installation sur une distribution 64 bits.

Je parlais de librairies, il nous faudra satisfaire quelques dépendances à ce sujet et en installer 3 principales :

• Qt 4.4 avec le module webkit,
• QCA 2.0.1,
• SDL 1.2

(cf le README pour plus d’infos)

$ sudo apt-get install   libqt4-webkit   libqca2   libsdl1.2debian

Nous pouvons à présent télécharger et installer le Mirware :

$ wget -c http://broad.violet.net/mirror/mirware.tar.gz
$ tar -xvzf mirware.tar.gz
$ cd mirware-0.9.9-1724
$ sudo ./installer.sh

Le script installer.sh, présent dans l’archive de Mirware, va juste caler les droits pour la détection du périphérique :

installer.sh ( pour information uniquement)

#!/bin/bash
[ "$(id -u)" -eq 0 ] || { echo "This script needs root credentials" ; exit 1 ; }
chown root discover-device || { echo "Could not change owner of discover-device to root. Do you have root credentials ?" ; exit 1 ; }
chmod a+s discover-device || exit 1
touch detected_device
 
echo "All done ! You can now plug a mir:ror and launch mirware-launcher.sh !"

Il ne reste plus qu’à connecter le mir:ror et  lancer mirware :

$ ./mirware-launcher.sh

Une icône dans la barre de notification indique que tout se passe bien. En approchant un objet du capteur, une fenêtre de connexion devrait apparaître, suivie d’un interface permettant d’enregistrer l’objet et de lui associer des actions (applications).

32 bits…C’est bien…mais 64 ?

Si vous utilisez une distribution 64 bits, il vous faudra recompiler le petit programme de détection du mir:ror : discover-device et installer les librairies utilisées par Mirware dans leur version 32 bits. Sans les sources et en l’abscence de version 64 bits, pas le choix…

Concernant la compilation de discover-device, rien de bien sorcier, il faut juste ne pas oublier de lui redonner les bons droits…
$ sudo rm discover-device
$ gcc discover-device.c -o discover-device
$ sudo ./installer.sh

Pour les librairies 32 bits, après avoir pas mal joué de l’apt-get, je suis tombé sur un script qui simplifie bien les choses (merci Cappy). Getlibs prend en paramètre un binaire et télécharge les librairies dépendantes dans leurs versions 32 et 64 bits… Le pied !

$ wget -c http://frozenfox.freehostia.com/cappy/getlibs
$ ./getlibs mirware

Pour clore ce chapitre…

…sur une utilisation classique du mir:ror, je peux ajouter qu’une grande majorité des actions proposées par le serveur sont fonctionnelles sous Linux… L’ouverture d’un dossier, le chargement d’une url, l’accès à la messagerie, à un podcast ou une webradio, la lecture d’un texte en texttospeech et j’en passe…

J’ai tout de même noté un problème gênant sur l’application permettant le lancement de scripts;  En effet, cette dernière ne sait gérer que des scripts Windows/Dos batch (.bat) ou des AppleScripts(MacOsx). Ce n’est pas très gênant pour l’utilisation que je compte en faire et comme promis, je détaillerai, dans le prochain article comment s’affranchir des contraintes du serveur Violet.net pour passer de l’autre côté du mirroir.

]]> http://www.jopa.fr/index.php/2009/07/07/violet-mirror-linux/feed/ 9