Installer scdaemon sur un Pi déconnecté du réseau

Dans un article précédent décrivant la partie génération de clefs PGP et transfert sur YubiKey, j’avais évoqué qu’il était envisageable de réaliser le processus complet sur un ordinateur exclusivement réservé pour cet usage. Je me suis donc procuré un Raspberry Pi Zéro, afin de vérifier la validité de cette hypothèse.

Mes premiers tests ont néanmoins été quelque peu retardés, car il est nécessaire d’adjoindre au Pi un hub USB disposant d’une alimentation dédiée, afin de pouvoir connecter, et surtout utiliser les différents périphériques : clavier, YubiKey et support de sauvegarde.

Le principal point bloquant par rapport à la génération des clefs PGP testée la première fois, se situe du côté de l’absence dans le système du composant scdaemon. Sans lui, impossible de dialoguer avec la YubiKey et d’exporter les clefs. Passons donc aux étapes permettant son installation.

Dans un premier temps, et après avoir récupéré la dernière version de Raspbian, en étant particulièrement attentif à la vérification de l’image récupérée par comparaison des sommes de hachage, il faut également récupérer le paquet scdaemon. Une page du wiki debian nous indique par ailleurs, que la bonne architecture à choisir pour le Raspberry Pi Zéro est armel ou armhf, à priori.

Sur le site web du projet raspbian, je parviens par ailleurs à trouver la liste des paquets de la distribution disponible. Dans ce fichier, une recherche de la chaîne « Package: scdaemon », nous permet de déterminer le chemin (propriété filename) où trouver le paquet recherché dans l’arborescence du même site, à savoir ici :

pool/main/g/gnupg2/scdaemon_2.1.18-8~deb9u2_armhf.deb

Nous pouvons alors nous rendre sur la page suivante afin d’explorer les différents versions du paquet à notre disposition: https://archive.raspbian.org/raspbian/pool/main/g/gnupg2/. Une fois le paquet récupéré et le système installé sur la carte SD, on pourra alors monter le système de fichier présent sur la carte et déposer le .deb quelque part dans l’arborescence (par exemple, dans /home). On en profite également pour comparer la somme de hachage du paquet avec celle présente dans le fichier « Packages ». Il ne nous reste plus qu’à démarrer le système depuis le Pi et à exécuter la commande dpkg -i <paquet>.deb pour installer scdaemon.

À ce stade, nous disposons désormais d’un ordinateur ayant tous les pré-requis nécessaires à la génération et à l’exportation des clefs PGP sur la YubiKey. J’ai rencontré quelques difficultés lors des premières tentatives d’export vers la YubiKey, car cette dernière, bien que détectée, ne semblait pas disponible. Il semble que deux processus scdaemon étaient démarrés et j’ai donc pu résoudre mon problème avec un simple « killall scdaemon ». Autre point l’export devait être réalisé en mode root, l’option -E de sudo devient alors incontournable pour transmettre la variable d’environnement « GNUPGHOME ». Pas grand-chose à ajouter de plus, si ce n’est qu’il faut faire preuve de patience pour les opérations de génération des clefs, qui mettent plusieurs minutes à s’exécuter sur un Pi zéro.

Logs Android via adb

Avec le téléphone connecté en USB et le débogage activé, il est possible d’avoir accès aux logs du système en temps réel avec la commande adb logcat, à laquelle on pourra passer le paramètre -v color afin de disposer d’une coloration des logs par sévérité.

adb logcat -v color

Pour filtrer les résultats et n’afficher que les logs de certains services, on ajoutera la liste des services désirés en suivante la forme <nom-du-service>:<niveau-de-verbosité>. Ce qui nous donne par exemple, pour n’afficher que les logs des services NFC :

adb logcat -v color "NfcService:V NativeNfcTag:V *:S"

Ou encore, pour afficher toutes les erreurs :

adb logcat *:E

Qui nous donne :

10-21 22:26:53.699 25006 25006 E android.hardware.nfc@1.0-impl: hw_get_module nfc_nci failed: -2
10-21 22:26:53.699 25006 25006 E android.hardware.nfc@1.0-impl: Passthrough failed to load legacy HAL.
10-21 22:26:53.700 25006 25006 E android.hardware.nfc@1.0-service: Could not get passthrough implementation for android.hardware.nfc@1.0::INfc/default.

Ce qui laisse à penser que le NFC n’est pas prêt de fonctionner correctement avec ma YubiKey sur ma custom rom.

Pour toutes les autres options de la commande logcat, direction la documentation !

TWRP récent pour Xperia Z1

J’ai voulu tester dernièrement une rom custom Android 9 pour mon Z1 vieillissant. Problème, la version de TWRP, programme installé sur mon téléphone de test était trop vieille pour pouvoir prendre en charge l’installation d’une rom aussi récente. Autre obstacle, TWRP n’a pas été mis à jour depuis fin 2016 pour mon appareil.

Je me suis donc tourné vers une version non officielle, résultat d’un portage de la version 3.2.3-0 pour le Z1. Version trouvée sur xdadevelopers. Une fois installée, j’ai donc pu procéder au déploiement d’une version beta de Android 9 sur mon appareil, portée par CarbonROM.

Je n’ai pas testé très longtemps. La ROM semblait stable, mais avec quelques problèmes bloquants, notamment du côté de l’appareil photo et de la connexion WiFi. Et toujours pas moyen d’utiliser des clés PGP sur une YubiKey via le NFC.

Clone parfait d’une puce RFID

Cela faisait un petit moment que j’avais envie de m’intéresser au monde des puces RFID. Après quelques recherches, j’ai fait le choix d’un lecteur RFID chinois de type ACS / ACR122U, qui a l’avantage de son prix abordable en comparaison de certains autres lecteurs. Pour cette première entrée en matière, je me suis donné pour objectif la création d’un clone de mon badge d’immeuble. Voici les étapes qui ont permis d’y arriver.

Préparation du système

Sous ArchLinux, il est nécessaire d’installer quelques paquets pour la gestion du NFC, à savoir :

  • libnfc : Platform independent Near Field Communication (NFC) library
  • mfoc : MiFare Classic Universal toolKit
sudo pacman -S libnfc mfoc

Vérifications

Maintenant que les programmes nécessaires sont installés, nous pouvons connecter le lecteur à notre ordinateur, poser une puce RFID sur celui-ci et vérifier que tout est détecté.

$ nfc-list
nfc-list uses libnfc 1.7.1
NFC device: ACS / ACR122U PICC Interface opened
1 ISO14443A passive target(s) found:
ISO/IEC 14443A (106 kbps) target:
ATQA (SENS_RES): 00  04
UID (NFCID1): 5a  7a  3f  10
SAK (SEL_RES): 08

Comme nous pouvons le voir dans le retour de la commande, le lecteur et la puce sont bien reconnus.

Extraction du contenu de la puce source

Passons maintenant à l’extraction des données de la puce source à proprement parler. La création d’un dump de la puce dans un fichier s’effectue avec la commande suivante :

mfoc -P 500 -O badge-entree.dmp

Modification de l’UID de la puce cible

Afin de créer une copie parfaite, il convient de modifier l’UID de la puce cible. Attention, pour effectuer une opération de ce type, il est bien sûr nécessaire de disposer de puce RFID inscriptible dans leur totalité. On parle notamment de puce dont le bloc 0 est modifiable.

nfc-mfsetuid 5a7a3f10

Première tentative de clonage de la puce

A ce stade, les informations que j’ai pu trouver en divers endroits sur le web préconise d’exécuter une nouvelle fois la commande ci-dessus, mais cette fois sur la puce cible afin d’obtenir un fichier badge-vierge.dmp. Il est ensuite question de procéder à l’écriture des données sur la puce vierge de la façon suivante :

nfc-mfclassic w a badge-entree.dmp badge-vierge.dmp

En particulier, pour copier également le contenu du bloc 0, on remplacera l’option w par W, ce qui aura pour effet d’écrire l’intégralité des 64 blocs sur la puce, toujours si celle-ci le permet.

Pour ma part, j’ai noté que je n’ai pas réussi à modifier l’UID de ma carte cible avec la commande nfc-mfclassic, bien que le bloc 0 de la puce rfid soit modifiable. Je me suis donc tourné vers la commande présentée plus haut afin de remplacer spécifiquement l’UID de ma puce cible par celui de ma puce RFID source.

Par ailleurs, la commande ci-dessus ne m’a pas  permis pas de créer une puce identique. Les clés ne sont pas modifiés et comparer le hash des dump permet de vérifier leur différence. La clé par défaut reste utilisée sur la puce chinoise. Un petit tour du côté de l’entrée de mon immeuble et la petite lumière rouge clignotante me confirme que les puces crées ne sont pas correctes.

Création du clone

Cette première tentative s’étant révélée infructueuse, j’ai donc tenté la création du clone de la manière suivante :

nfc-mfclassic W a u badge-entree.dmp

En exécutant mfoc sur la puce ainsi créée, le résultat n’est plus immédiat, ce qui est plutôt encourageant car cela prouve que la clé par défaut n’est plus utilisée.

Vérification avec les sommes de contrôle:

$ sha256sum badge-entree.dmp
0ca740e1a69a5eb379c96e232b6c39ed70daf8072912e2950e73f91876d3ec35  
badge-entree.dmp
$ sha256sum badge-cible.dmp
0ca740e1a69a5eb379c96e232b6c39ed70daf8072912e2950e73f91876d3ec35  badge-cible.dmp

Dernier point, pour afficher le contenu d’un fichier hexadécimal dans le terminal, on pourra utiliser la commande hexdump (ou xxd, bien pratique également).

Conclusion

Avec le matériel et les logiciels adéquats, il est possible en quelques minutes de créer une copie parfaite d’une puce RFID, tel qu’un badge d’entrée d’immeuble. Étant donné que certaines puces RFID se présentent sous la forme de porte-clés, nous pouvons alors envisager une manière plus pratique d’ouvrir, par exemple, la porte d’accès de son entreprise. Il serait également intéressant de pouvoir fournir le contenu extrait de la puce à l’aide de son téléphone portable; l’idéal serait alors une identification automatique du lecteur pour un choix automatique de la puce RFID à émuler.

De la médecine générale

Comme certains lecteurs l’auront noté, je pratique un sport peu connu et assez peu médiatisé, le roller de vitesse (Inline Speed Skating en anglais), depuis maintenant 4 ans. La saison 2017/2018 m’ayant offert de participer aux championnats de France de roller indoor, il va de soi que cette opportunité ne vient pas sans une bonne dose d’entraînement hebdomadaire et de régularité.

J’ai été confronté lors de ma deuxième année de pratique à des « problèmes » de genou, caractérisés tout d’abord par quelques douleurs. Douleurs, que j’ai choisi, à l’époque, d’ignorer. Comme beaucoup, je suis allé consulter mon médecin généraliste, qui m’a immédiatement prescrit des anti-inflammatoires en pommade, avec comme diagnostic : inflammation des cartilages. Je pouvais donc continuer à patiner, utilisant le médicament fournit quand survenait la douleur. Évidemment, la douleur n’a pas disparu et est même devenue plus fréquente. A la visite suivante, j’ai eu le droit aux anti-inflammatoires en gélule, pour un effet garanti. J’ai donc continué à patiner.

Bien plus tard dans l’année, la douleur a refait son apparition et j’ai fait mon retour dans le cabinet du médecin. À nouveau prescription d’anti-inflammatoire et d’un examen IRM en plus. Je me rappellerai toujours la réponse du médecin à ma question de réduire ma fréquence d’entraînement, en paraphrasant, en voici la teneur : « Non, continuer comme d’habitude. En cas de douleur, utiliser la crème avant, et après l’entraînement ». Je suis allé passer mon examen IRM, pas de lésions. Néanmoins, la réponse du médecin m’avait profondément dérangé.

Continuer la lecture de « De la médecine générale »