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 »

Connexion SSH avec gpg-agent

Dans l’épisode précédent, je décrivais comment j’avais créé mes clefs et sous-clefs et la façon dont j’avais exporté les sous-clefs sur une YubiKey. Place à une mise en application du côté de la connexion SSH entre un poste client et un serveur. J’utilise déjà le processus d’authentification par clef SSH pour me connecter sur mes machines serveurs, distantes géographiquement ou pas, virtuelles ou non. Le principe est donc d’utiliser la clef d’authentification pour se connecter en SSH aux machines.

On gagne en praticité, car une seule clef va nous permettre de nous connecter à chacune de nos machines une fois celles-ci configurées. Cela passe néanmoins par une configuration de la machine cliente pour utiliser gpg-agent en lieu et place de ssh-agent, chose qui n’est pas forcément aisée. Je vais décrire la configuration que j’ai mise en place, résultat de plusieurs échecs successifs avant d’arriver à quelque chose de fonctionnel et en sachant que j’utilise Xorg et I3 pour la partie affichage et interface.

Configuration côté serveur

La première étape consiste à récupérer les informations de la clef nécessaires à la configuration du serveur. Après avoir inséré notre YubiKey, nous exécutons donc la commande suivante :

$ ssh-add -L
ssh-rsa BFFEB3NzaC ... pdqsdfwX6m1 cardno:000123456789

Nous pouvons alors copier les informations renvoyées par cette commande et les insérer dans le fichier authorized_keys de notre serveur.

Configuration côté client

Le but est maintenant de remplacer ssh-agent par gpg-agent. Nous commençons donc par configurer ce dernier en éditant le fichier .gnupg/gpg-agent.conf :

enable-ssh-support 
pinentry-program /usr/bin/pinentry-curses
max-cache-ttl 300
default-cache-ttl 300

Dans le fichier .pam_environment, nous ajoutons les lignes suivantes :

SSH_AGENT_PID   DEFAULT= 
SSH_AUTH_SOCK DEFAULT="${XDG_RUNTIME_DIR}/gnupg/S.gpg-agent.ssh"

Et enfin dans .zshrc :

export GPG_TTY=$(tty) 
gpg-connect-agent updatestartuptty /bye >> /dev/null

Il me semble que cette configuration est suffisante pour obtenir quelque chose de fonctionnel. Sur mon poste, j’ai quelques déclarations supplémentaires du côté des fichiers .profile, .zprofile qui font doublon pour la déclaration de la variable GPG_TTY. Il devrait être possible de les supprimer sans risques.

Test unique

Pour réaliser un test unique, après configuration de gpg-agent et avant d’effectuer toutes les modifications ci-dessus et de tester la persistance au redémarrage, j’ai utilisé les commandes ci-dessous pour tester la connexion au serveur avec la clef d’authentification et vérifier cette première étape.

sudo killall gpg-agentsudo killall ssh-agenteval $( gpg-agent --daemon --enable-ssh-support )

Nous pouvons alors essayer la connexion SSH vers notre serveur et retrouver la configuration utilisant ssh-agent après un simple redémarrage. L’utilisation de l’option -vvv étant particulièrement utile pour suivre les étapes de connexion et détecter d’éventuels problèmes.

ssh user@server -vvv

Conclusion

Avec cette configuration, je suis donc en mesure de me connecter à mes serveurs via SSH en utilisant ma clef d’authentification stockée sur ma YubiKey et le PIN associé à la clef. S’il est plutôt aisé de réaliser une première connexion réussie, la principale difficulté concerne la persistance de la configuration et le lancement correcte des composants à l’ouverture de la session; en particulier pour l’affichage de l’interface de saisi du PIN via pinentry-curses.

Sources

Using GnuPG (2.1) for SSH authentication
YubiKey for SSH, Login, 2FA, GPG and Git Signing

GnuPG, clefs, YubiKey : c’est parti

L’enchaînement  et le choix des commandes et des configurations qui vont suivre sont essentiellement extraites du blog de Simon Josefsson dans son article Offline GnuPG Master Key and Subkeys on Yubikey NEO Smartcard.

Après m’être documenté sur la génération de clefs, GnuPG et les possibilités  d’intégration au système, je me suis donc naturellement tourné vers la pratique et l’expérimentation. J’essaye ici d’en retracer les étapes, afin d’être en mesure de le reproduire au besoin.

Quelques points restent à améliorer et à solutionner, notamment l’absence dans les systèmes live testés (Kali Linux, Debian 9.5.0 et Parrot Security 4.2.2), du composant scdaemon permettant de communiquer avec la YubiKey et conduisant à l’échec de la commande gpg –card-edit.

Dernière petite note avant d’entrer dans le vif du sujet. Pourquoi une YubiKey (Neo) ? Tout simplement parce que j’avais fait l’acquisition de ce matériel il y a de cela quelques années, mais n’avais pas réussi à l’intégrer à mon utilisation quotidienne. Ce dispositif été donc tout indiqué pour servir de support de stockage à mes sous clefs.

Pour rappel, les opérations effectuées ci-dessous sont à réaliser sur une machine hors ligne et dans un système « Live ». Les plus soucieux de leur sécurité pourront aller jusqu’à utiliser un ordinateur dédié à cette tâche (un raspberry pi zéro peut-être ?).

Continuer la lecture de « GnuPG, clefs, YubiKey : c’est parti »