David Madore's WebLog: Android, Wifi, certificats et autres âneries

Index of all entries / Index de toutes les entréesXML (RSS 1.0) • Recent comments / Commentaires récents

Entry #2046 [older|newer] / Entrée #2046 [précédente|suivante]:

(mardi)

Android, Wifi, certificats et autres âneries

Je continue mes râleries sur Android 4, parce que râler est la chose que je sais le mieux faire au monde : je ne veux cependant pas donner l'impression que tout est mauvais — il y a du bon et du mauvais, c'est juste que c'est plus satisfaisant pour les nerfs de se plaindre ce qui ne marche pas que de constater ce qui marche. Et en l'occurrence je parle de quelque chose qui ne marchait pas du tout sous Android 2 et qui maintenant marchouille mal.

Je commence par énoncer deux faits :

Fait nº1 : Je n'ai pas envie de verrouiller mon téléphone, que ce soit par un code PIN, par un dessin de déverrouillage, par un mot de passe, ou quoi que ce soit. Ceci tient à deux raisons : d'une part j'ai un compte mobile prépayé, donc si mon téléphone se fait voler, tout mon crédit m'est de toute façon perdu (certes je peux vouloir emmerder le voleur, mais pour ça j'essaierais plutôt de trouver un moyen de désactiver ou retrouver mon téléphone à distance) ; d'autre part, s'il m'arrive un accident, je trouve utile que quelqu'un de bien intentionné puisse récupérer mon téléphone et s'en servir pour appeler mes proches pour les prévenir, et pour ça il faut qu'il n'y ait aucun code de verrouillage. (Ce serait encore mieux, bien sûr, s'il y avait une configuration ou une application pour permettre d'appeler simplement certains numéros prédéfinis, mais faute de ça…)

Fait nº2 : À l'ENST Télécom ParisTech nous avons un Wifi interne qui est sécurisé par 802.1x, c'est-à-dire une usine à gaz qui fait qu'au lieu d'avoir simplement un mot de passe (ou une phrase de passe…) partagé spécifique au Wifi, c'est le mot de passe de nos comptes informatiques qui sert à s'authentifier. Ceci soulève immédiatement le problème suivant : mais du coup, comment évite-t-on que n'importe qui puisse extraire de mon téléphone le mot de passe en question, en créant simplement un Wifi (« troyen ») ayant le même nom public celui de l'ENST, auquel mon téléphone chercherait à se connecter, et auquel il révélerait donc mon mot de passe ? (Et de fait, je pense qu'on doit pouvoir extraire pas mal d'informations croustillantes en recréant des réseaux Wifi bien connus et en récupérant les tentatives de connexion vers eux. Je blâme déjà Android sur un point : il n'y a pas moyen d'enregistrer un réseau Wifi dans le téléphone en lui demandant de ne pas s'y connecter automatiquement dès qu'il le rencontre.)

Un élément de réponse est qu'on peut utiliser un mécanisme d'authentification où le client n'envoie pas simplement le mot de passe au serveur mais répond à un défi de celui-ci : ceci évite au moins qu'un faux serveur puisse récupérer directement le mot de passe — il ne pourra que faire une attaque « man-in-the-middle » en direct. Mais bon, ça ne change pas grand-chose au problème. La vraie réponse, c'est que le serveur (point d'accès Wifi) est censé fournir un certificat X.509 au client pour montrer qu'il est bien qui il prétend être et qu'il est raisonnable de lui confier le mot de passe (ou même la réponse à un défi sur ce mot de passe) : du coup, pas de problème, mais uniquement à condition que le client vérifie bien ce certificat et sache qu'il doit l'accepter.

D'où la nécessité de faire accepter à Android le certificat du Wifi de Télécom si je veux m'y connecter. Noter bien que ce certificat n'a rien de secret : c'est une clé publique, et d'ailleurs le certificat en question est publiquement accessible ici.

Bon, je passe sur la première crotte de ragondin qui est qu'il y a je ne sais combien de formats de certificats et que chaque format a lui-même je ne sais combien d'extensions possibles juste pour rendre les choses plus confuses. En l'occurrence, il semble qu'Android voulait un certificat au format DER avec l'extension .crt, et qu'on convertit un .pem en ça en faisant openssl x509 -outform DER -in wifi_certs.pem -out wifi_certs.crt (ce qui n'a pas été facile à trouver). Heureusement que je suis cryptographe, parce que je me demande comment le profane est censé comprendre tout ça. Mais j'en viens au point central de ma râlerie.

Android 4 a rajouté la possibilité d'ajouter un certificat externe (depuis la carte SD du téléphone), qui n'existait pas du tout sous la version 2. Très bien. J'applaudis.

Mais Android 4 a décidé qu'à partir du moment où on ajoute un certificat cryptographique, c'est une donnée hautement confidentielle, et que vous devez la stocker sous forme chiffrée (dans ce qu'il appelle le credential storage). Et pour ça, vous devez configurer un mot de passe (ou équivalent) qui servira à chiffrer ce stockage : et ce mot de passe sera nécessaire pour déverrouiller votre téléphone. C'est complètement crétin, parce que le certificat en question, il est complètement public comme je l'ai souligné ; et c'est d'autant plus crétin que le truc vraiment secret, mon mot de passe, lui, il est stocké en clair par Android (dans le fichier /data/misc/wifi/wpa_supplicant.conf) : bref, Android veut m'obliger à chiffrer quelque chose qui n'a rien de secret et ne me propose pas de chiffrer quelque chose qui l'est.

Et concrètement, il semble que les deux exigences soient incompatibles : ne pas verrouiller le téléphone, et pouvoir accéder au Wifi de Télécom sans que mon téléphone communique gentiment mon mot de passe à n'importe quel Wifi qui aurait le hasard ou la malice de s'appeler comme celui de mon bureau. Visagepaume !

Pour ne pas qu'on m'accuse de râler dans mon blog sans faire remonter les problèmes au bon endroit, mon bug-report est ici.

↑Entry #2046 [older|newer] / ↑Entrée #2046 [précédente|suivante]

Recent entries / Entrées récentesIndex of all entries / Index de toutes les entrées