Replicant : appareils mobiles, logiciels libres et vie privée - Paul Kocialkowski - PSESHSF 2016

Titre : Replicant : appareils mobiles, logiciels libres et vie privée

Intervenant : Paul Kocialkowski

Lieu : PSESHSF - Pas Sage En Seine Hacker Space festival

Date : Juillet 2016

Durée : 50 min 15

Pour visionner la vidéo

Pour télécharger la présentation

Statut : Transcription MO

Description

Cet exposé présentera Replicant dans le cadre de l'initiative visant à libérer les appareils mobiles.

En premier lieu, les problèmes majeurs liés à la liberté sur ces appareils seront abordés. Il s'agira de détailler la situation pour chaque composant et à chaque niveau, en proposant ainsi un aperçu complet. Ainsi, de nombreuses considérations sur différents aspects seront présentées, allant de la liberté du matériel jusqu'au système d'exploitation, en passer par les micrologiciels.

Après avoir dressé un bilan de la situation, les remédiations possibles à plus ou moins court terme seront présentées. C'est dans ce cadre que s'inscrit le projet Replicant, distribution entièrement libre d'Android pour plusieurs appareils, un système mobile libre mettant l'accent sur la liberté et la vie privée/sécurité.

L'état du projet ainsi que les différents challenges et objectifs futurs seront ainsi présentés.

00'

Je m'appelle Paul Kocialkowski. Je suis développeur Replicant et je vais vous parler un petit peu d’appareils mobiles, et de vie privée et de sécurité et de logiciels libres.

Tout d'abord je vais vous présenter ce que sont ces appareils mobiles du point de vue de leurs composants, mais aussi des problématiques que tout cela implique du point de vue de la liberté, de la vie privée et de la sécurité.

Pour commencer, un appareil mobile c'est avant tout composé d'un processeur. Mais en fait il n'y en a pas qu'un seul, il y a plusieurs processeurs à l'intérieur. On a un processeur principal qui exécute le système d'exploitation qu'on connaît, mais on a aussi des processeurs auxiliaires de calcul qui vont traiter différentes tâches. C'est par exemple le cas du GPU qui va traiter les tâches liées au graphique ou d'autres processeurs, par exemple d'accélération pour le décodage ou l'encodage multimédia. Et on trouve enfin un processeur de communication, qu'on appelle aussi le modem, et qui va permettre de communiquer avec le réseau téléphonique, le réseau GSM. En fait on en trouve plusieurs. On peut aussi catégoriser les processeurs pour le Wi-fi ou le Bluetooth de cette manière. Et on trouve également des contrôleurs et des périphériques.

Ces contrôleurs et ces périphériques vont servir à gérer tout ce qui est en fait les entrées-sorties, donc 'écran tactile, tous les capteurs qu'on va trouver, l'écran même du téléphone, tout un tas de choses en fait.

Et finalement, ces composants-là sont implémentés de plusieurs manières différentes. On a tout d'abord un aspect matériel qu'on va traduire sous la forme d'un design matériel puisque le matériel c'est quelque chose de physique et le design c'est sa représentation immatérielle qui caractérise, en fait, le fonctionnement du composant. Donc on va parler vraiment de design matériel, et on a le côté logiciel qui s’exécute sur ce matériel.

Si on regarde un petit peu la situation actuelle au niveau de ces composants, on trouve que le nombre de composants programmés, donc le nombre de composants qui vont exécuter du logiciel n'a fait qu'augmenter au fur et à mesure du temps. Et qu'en fait le traitement des informations et des données a été de plus en plus délocalisé dans, en particulier, les processeurs auxiliaires.

On constate également que tous ces composants ont de plus en plus accès à nos communications personnelles, en particulier pour les appareils mobiles : on s'en sert pour téléphoner, pour communiquer avec tout le monde et on stocke énormément de données auxquelles ces composants ont également accès. Ça sera des données plus ou moins personnelles, mais il y en a une grande quantité.

Ça pose donc un certain nombre de problématiques. Tout d’abord on peut se demander est-ce qu'on peut avoir confiance en cette technologie puisque finalement on lui donne quand même beaucoup d’informations à propos de nous ? Est-ce qu'on peut avoir confiance ? Et pour avoir confiance, il faut contrôler cette technologie, il faut contrôler ces appareils. Est-ce qu'on peut vraiment les contrôler ? Et puis on peut aussi s'intéresser à leur fonctionnement ? On a envie de comprendre comment ces appareils fonctionnent et on a envie de préserver ce savoir, qu'il ne soit pas juste la propriété de certaines entreprises, mais que ce savoir soit un bien commun et qu'il soit possible pour tout le monde de comprendre comment fonctionne son appareil mobile ou son ordinateur en général, parce que, après tout, ça peut en intéresser certains parmi nous.

Tout ça, en fait, c’est pondéré par le degré de complexité de ces puces. Si ces puces sont très puissantes et qu'elles ont une capacité de calcul très élevée, on peut supposer que les problèmes de confiance et de contrôle vont être amplifiés. Si la puce est capable de faire beaucoup de choses avec nos données, on a beaucoup plus de risques concernant nos données elles-mêmes.

Pour garantir ces questions de contrôle et ces questions de confiance, on a ces libertés fondamentales que Richard Stallman a énoncé dans les années 80. Il s'agit de pouvoir utiliser le logiciel ou la technologie, de manière plus générale, pour tous les usages, de pouvoir l'étudier, le modifier, mais également de redistribuer cette technologie, donc sous forme immatérielle, il s'agit des design ,encore une fois, et de pouvoir les redistribuer, modifiés ou non. Effectivement ces libertés s'appliquent aux deux aspects qui composent les appareils mobiles, mais c'est vrai pour l'informatique en général, c’est-à-dire à la fois le design matériel et le logiciel.

Je vais maintenant caractériser un petit peu cet aspect du design matériel qui est, je l'avouerai, pas très souvent explicité.

On trouve, à ce niveau-là, deux technologies bien distinctes. La première ce sont les circuits imprimés. Ce sont donc les cartes sur lesquelles on va poser tous les différents composants et les relier entre eux avec différents autres composants, actifs ou passifs, des résistances, des condensateurs, des diodes, tout ce que vous voulez.

Et puis on a les circuits intégrés qui sont vraiment les puces dans lesquelles il y a la logique elle-même, où le vrai traitement est effectué. On en a de deux types. On va avoir des puces analogiques ou numériques. Et donc les puces analogiques vont utiliser des tensions continues. Les puces numériques vont utiliser des tensions discrètes, qui vont représenter des 1 et des 0 et une sous-catégorie de puces numériques ce seront les processeurs qu'on peut programmer. C’est-à-dire on peut leur donner des instructions et ils vont adapter leur fonctionnement en fonction de ces instructions, c’est-à-dire qu'ils n'ont pas, en fait, un fonctionnement fixe. C'est bien comme ça qu'on définit un processeur et qu'on définit ce que c'est que du logiciel : c'est une série d'instructions pour dire au circuit ce qu'il doit faire.

Si on s'intéresse à la question de libérer le matériel, de quoi il s'agit ? Eh bien si on reprend les libertés fondamentales que j'ai énoncées, il s'agit de pouvoir modifier le matériel. Pour ça on a besoin d'accéder à ce qu'on appelle le code source, donc la recette qui caractérise le fonctionnement de ce matériel. Pour le matériel on va appeler ça le design matériel, ce qui est donc l'équivalent du code source pour le logiciel, et c'est ça qu'on va chercher à vouloir modifier. Et ce design matériel est représenté sous un format particulier, un format numérique, parce que le matériel aujourd'hui est créé par des ordinateurs, plus personne ne crée de puce à la main en dessinant les calques qu'il faut pour créer les transistors. Tout ça est au format numérique, donc il y a des questions de formats de fichiers qui se posent, également de chaînes d'outils. Est-ce que les formats qu'on utilise pour représenter ce matériel sont compréhensibles, est-ce qu'il y a de la documentation sur la manière dont ce design est représenté ? Et est-ce que les outils qui permettent de le modifier mais aussi de recréer de nouvelles puces, sont des outils libres ou pas ? Donc ce sont là aussi des questions qui se posent.

Et enfin si on s'intéresse au matériel, il y a une vraie question de coût et de dimension qu'on ne retrouve pas avec l'aspect logiciel. C'est-à-dire que si on essaie de produire une nouvelle carte, un circuit imprimé typiquement, on a besoin d'une certaine infrastructure. Il faut des machines assez complexes qui sont capables de créer des pistes de circuits imprimés, les mettre toutes ensemble et créer une nouvelle carte. Ça, ça demande donc une grosse infrastructure et généralement ça coûte cher et on ne peut pas vraiment faire ça tout seul chez soi.

Et finalement, si on s'intéresse aux circuits intégrés, donc aux puces en silicone (silicium, NdT) elles-mêmes, là les coûts sont complètement astronomiques. Il faut des usines entières qui coûtent des milliards d'euros à construire. Donc finalement on a vraiment une question de confiance si on souhaite réaliser nous-mêmes nos circuits, parce qu'on ne va pas vraiment pouvoir les réaliser nous-mêmes ! On va devoir faire appel à un tiers qui contrôle les machines et la grosse usine pour fabriquer ces choses-là. Et donc, là aussi, on a une question de confiance. On n'a plus le contrôle sur toute la chaîne de production, mais on doit déléguer à un tiers. Donc potentiellement un tiers qui pourra modifier le circuit sans nous le dire et on aura peu de moyens de vérifier.

Donc si on regarde la situation actuelle, on dirait que c'est possible à certains niveaux parce que, finalement, créer des circuits imprimés, donc juste les cartes elles-mêmes, il y a quand même beaucoup de fabricants qui le font, ce ne sont pas des coûts exorbitants, ça peut rester en dessous du millier d'euros, donc ça reste raisonnable, en tout cas pour certaines bourses.

On trouve au niveau des circuits intégrés beaucoup moins de possibilités pour les individus, cependant plusieurs initiatives de circuits intégrés libres. Donc il s'agit de leur design encore fois. Plusieurs telles initiatives existent, donc OpenSPARC, OpenRISC, LEON, LM32, lowRISC, tout ça ce sont en fait des designs de processeurs dont le design est disponible soit dans le domaine public ou soit sous une licence libre. Donc ça existe mais concrètement c'est très compliqué de créer soi-même des puces à partir de ces designsparce que ça coûte très cher.

On a la même chose pour les circuits imprimés. L'Arduino est un exemple connu avec un design de circuit imprimé libre. Il y en d'autres, des choses un peu plus complexes : l'USB armory, Novena, sont deux ordinateurs beaucoup plus puissants qu'un Arduino et qui ont également un design de circuit imprimé libre. Et on trouve souvent une certaine confusion par rapport à ce qu'on appelle le mouvement open hardware qui caractérise de manière assez floue plusieurs aspects, notamment la documentation du matériel. On va avoir tendance à qualifier d'open hardware des choses qui, en fait, ont simplement un matériel documenté dans le sens où les schémas sont mis à disposition mais les schémas ne sont pas une forme modifiable du design matériel. Donc finalement tout ce qui est open hardware, n'est pas forcément du matériel libre et la distinction est en fait assez floue.

09' 15

Je parle de ça de manière très générale, mais qu'est-ce qu'il en est pour les appareils mobiles ?

Si on regarde dans le détail pour les appareils mobiles, très clairement il n'y a pas d'appareils mobiles avec des circuits intégrés libres, de toutes façons on ne pourrait pas les produire et il y a très peu d'exemples d'appareils mobiles avec des circuits imprimés libres. J'en parlerai un peu petit plus tard. Il y a notamment le ???, ou le Neo900 plutôt, qui est un projet de téléphone fait par une entreprise allemande et pour lequel le design du circuit imprimé est libre. C'est peu près le seul exemple et c'est fait en très petites quantités par une petite entreprise allemande. Quoi qu'il en soit ce n'est jamais aussi simple que compiler un logiciel. Ça demande beaucoup d'argent, une infrastructure.

Maintenant pour parler un petit peu du logiciel, je vais parler donc de logiciel libre, de libérer le logiciel. Et en fait pourquoi le logiciel n'est pas libre à la base ?

Tout d'abord les fabricants, quand ils créent des appareils mobiles évidemment ils vendent un logiciel avec et ce logiciel, en général, il n'est pas libre. Pourquoi ? En fait les fabricants ont une certaine position vis-à-vis de ça. Tout d'abord, ils ont un intérêt économique de leur point de vue. Il s'agit pour eux essentiellement de ne pas faire fuiter les secrets qui caractérisent leur matériel. En vérité il n'y a pas vraiment de secrets, tout le monde fait un peu la même chose, mais il y a cette espèce de croyance dans l'industrie que tout ce qu'ils font est vraiment révolutionnaire et qu'il ne faut surtout pas que les compétiteurs y aient accès. Ce qui en pratique est faux. Tout le monde fait à peu près la même chose et tout le monde est en plus au courant de ce que fait l'autre. Mais cette croyance-là pousse très fortement les fabricants à ne pas libérer leurs logiciels parce qu'ils ne veulent pas que le savoir sur le fonctionnement de ces logiciels fuite. C'est une première chose.

Une deuxième chose ce sont les droits d'auteur sur les blocs. Aujourd’hui les puces qui sont vendues par certains fabricants sont, en fait, composées de plusieurs blocs qui viennent de différentes entreprises. Il se trouve que les logiciels qui s’exécutent sont la propriété du fabricant de chaque bloc. Si vous voulez, un fabricant qui vend une puce en entier, et qui vend du logiciel qui va avec, va en fait utiliser du logiciel qui vient de plein de différents constructeurs et pour cette entreprise ça devient très difficile de prendre la décision de libérer ce logiciel, simplement parce qu'elle n'en a pas les droits et qu'il faut qu'elle demande à chaque entreprise le droit et que ça, ça devient compliqué, il faut des avocats, tout ça. L'entreprise ne peut pas prendre la décision seule, donc en général c'est un gros frein pour libérer le logiciel.

Il y a aussi des questions de brevets, évidemment. C'est très courant dans l’industrie informatique de violer les brevets et chaque entreprise essaie de faire en sorte que ça ne se voie pas. Et du coup, mettre à disposition le code source c'est une manière très efficace de se rendre compte que telle entreprise viole tel brevet. Donc, pour les entreprises, c'est aussi une sorte de garantie pour ne plus avoir de problèmes de tout garder secret et surtout ça ne se voit pas.

Ensuite la question de la gauche d'auteur. Il se trouve que certaines entreprises, quand elles font des puces, utilisent des logiciels libres parce que c’est plus pratique ou parce que la prise en charge du matériel est déjà assez avancée et qu'il suffit de modifier quelques petites choses pour que ça fonctionne avec la nouvelle version. Et en fait quand ces logiciels libres sont sous gauche d'auteur, c'est-à-dire que les versions modifiées doivent être publiées sous la forme d'un logiciel libre, eh bien on va se retrouver avec ces fabricants qui sont obligés de publier les sources modifiées qu'ils utilisent. Donc c'est quelque chose de très courant par exemple pour les appareils Android. Les noyaux utilisés c'est le noyau Linux et les versions modifiées du noyau Linux, enfin ces versions-là sont mises à disposition en tant que logiciel libre par les fabricants qui les utilisent, donc y compris le code source et tout ce qui va avec.

Donc ça c'est la gauche d'auteur, c'est très bien et ça nous permet d'avoir du logiciel libre dans ces cas-là. Mais, pour le coup, la qualité du code qui est ainsi produit est vraiment très médiocre et personne n'a vraiment envie d'utiliser ça. Ces choses-là on s'en sert plutôt comme code de référence. C’est-à-dire qu'à l’intérieur de ce code il y a la connaissance du fonctionnement du matériel. Donc on va pouvoir lire ce code pour écrire du code propre qui fera la même chose et qui pourra être intégré au noyau officiel. Donc souvent c'est plutôt cette approche-là qui est retenue.

Sinon, quand il n'y a pas de gauche d'auteur et quand le fabricant ne souhaite pas mettre à disposition les logiciels sous la forme de logiciels libres, eh bien on doit faire un travail d’ingénierie inverse qui consiste, en fait, à essayer de comprendre ce que fait un logiciel propriétaire pour écrire un logiciel libre équivalent, qui fera la même chose. Et finalement, faire ça, ça demande énormément de temps et de ressources, c'est très compliqué. Ce n'est pas toujours possible techniquement et il y a beaucoup de limitations qui sont récurrentes et qui freinent ou qui bloquent complètement ce travail. Comme ça prend du temps, on peut se poser la question de l’intérêt à long terme de ce genre d'approche puisque, si par exemple on prend le cas des appareils mobiles et qu'il y a une nouvelle version de l’appareil qui sort tous les six mois, est-ce que ça vaut le coup de passer deux ans à essayer de comprendre comment un modèle fonctionne, alors que deux ans après ce modèle-là sera obsolète et plus personne n'aura envie de s'en servir ? Donc il y a une vraie question d’intérêt à long terme et d'obsolescence ici.

Et donc pour revenir un petit peu à ces limitations récurrentes à l'ingénierie inverse, la première c'est l’absence de documentation du matériel ou de schémas. C'est très compliqué d'écrire des logiciels de bas niveau, donc des drivers, ce genre de choses pour du matériel si on n'a pas de documentation technique ou si on n'a pas aux schémas du matériel. Il y a des choses qu'on ne peut pas inventer. Et typiquement on ne peut pas tout deviner juste en regardant le logiciel propriétaire.

Ensuite il faut une certaine connaissance technique parce qu'il y a certains aspects des appareils qui demandent des connaissances très spécifiques. Par exemple les GPS, il faut être très bon en physique, il y a de la relativité qui intervient. II y a des tas de phénomènes qu'il faut connaître et qu'il faut maîtriser si on veut avoir une chance de comprendre quoi que ce soit et d'écrire une implémentation libre.

Il faut aussi parfois des outils adaptés, c'est-à-dire des outils de manière très physique pour arriver à, je ne sais pas, extraire le logiciel propriétaire par exemple, il faut parfois des outils pour aller chercher dans la mémoire qu'il faut, au bon endroit. Donc ça peut être un frein aussi. Il y a aussi des contraintes légales liées à l'ingénierie inverse, finalement. On n'a pas le droit partout de faire ce travail-là, c’est-à-dire de comprendre comment fonctionne un logiciel propriétaire. Aux États-Unis, en général, c'est interdit. Il y a la majorité des techniques employées pour ça qui sont interdites.

En Europe la situation est plus favorable. C'est-à-dire qu'on a le droit d'utiliser ces techniques d'ingénierie inverse pour, en fait, faire de la compatibilité avec du logiciel libre. C'est souvent ce qu'on fait la plupart du temps. Mais il y a quand même des cadres légaux assez restreints et ce n'est pas aussi clair. C'est assez compliqué. Souvent c'est mieux d'avoir un conseil juridique quand on commence de genre de choses, ce qui, encore une fois, est un frein parce que devoir payer un avocat pour écrire du code, ce n'est quand même pas idéal.

Maintenant sur les limitations techniques, ce n'est pas toujours possible de remplacer le logiciel qu'on souhaite remplacer, soit parce que la mémoire dans laquelle il est inscrit est en lecture seule et donc c'est technologiquement impossible de le remplacer. Donc on est piégé, on a un logiciel propriétaire ad vitam æternam sur ce composant : on ne pourra pas le remplacer. À ce moment-là on pourra plus ou moins le qualifier de matériel en fait. Vu qu'il n'est pas remplaçable est-ce que c'est encore du logiciel ? Pas vraiment ! Si on considère que le logiciel ce sont des instructions qu'on peut modifier, si on n'est pas capable de les réinscrire ce n'est plus vraiment du logiciel : c'est un comportement complexe mais statique d'un composant.

Et parfois, si on veut remplacer ce logiciel, il faut accéder à certaines interfaces pour réécrire ce logiciel, qui ne sont pas évidentes. Parfois ces interfaces sont secrètes. Parfois ces interfaces sont peu ou pas documentées et très souvent, quand on s'intéresse en particulier aux logiciels très bas niveau, donc les chargeurs de démarrage par exemple, il faut avoir des accès externes à la machine, c'est-à-dire ouvrir l’appareil, souder des câbles au bon endroit pour pouvoir accéder à la mémoire et pour pouvoir remplacer le logiciel. Tout ça c'est très compliqué, mais ce n'est pas du tout !

Une fois qu'on a réussi à écrire son propre logiciel dans la mémoire, il faut que la puce nous autorise à l'exécuter et ce n'est pas toujours le cas ! Il y a certaines puces qui vont faire des vérifications de signatures. Donc ce sont des signatures au sens un petit peu comme… Oui, en fait, ce sont des clefs asymétriques, style RSA. Et en fait, si le logiciel qu'on installe n'est pas signé avec la clef du fabricant, le composant va refuser de l'exécuter tout simplement Et la clef du fabricant, évidemment c'est le fabricant qui la garde, nous on n'y a pas accès. Donc si on essaie d'installer notre logiciel et qu'on ne l'a pas signé avec la bonne clef, eh bien le composant va simplement refuser de l'exécuter. Donc impossible d'exécuter du logiciel libre dans ce cas-là.

Une fois qu'on a quand même réussi à installer notre logiciel, que le composant l'autorise à s'exécuter, il faut encore pouvoir le débuguer. Parce que quand on écrit une implémentation libre, ça ne marche pas du premier coup, il faut faire ça petit à petit et donc on a besoin d'avoir des retours du matériel, savoir qu'est-ce qui marche, qu'est-ce qui ne marche pas, donc on a besoin de moyens de débuguer. Et si on n'a pas ça, on est complètement dans le noir. On installe notre logiciel, on sait que peut-être il tourne, mais on n'a aucun retour et on n'avance pas. Donc il faut ces moyens de débuguer qui ne sont pas toujours possibles.

Et enfin, si on arrive finalement à écrire un logiciel libre fonctionnel qu'on peut installer, qui est autorisé, qu'on a pu débuguer, il faut encore que l'utilisateur puisse l'installer. Parce que c'est bien que le développeur ait libéré sa machine, mais si c'est le seul à pouvoir le faire et si l'utilisateur a besoin d’acheter des machines qui coûtent cher, des outils particuliers ou d’ouvrir son ordinateur, de souder des câbles, et de faire des choses très techniques, ça a, en fait, peu de portée. Il y a très peu d'utilisateurs qui seront capables de faire ça.

Et quand on s'intéresse en particulier aux logiciels très bas niveau, il y a un vrai risque de rendre le tout inopérant. C'est-à-dire si on se trompe et qu'on installe la mauvaise version ou qu'on a mal suivi les instructions et qu'on installe quelque chose qui ne fonctionne pas, eh bien si c'est quelque chose qui est au très bas niveau, donc quelque chose qui va faire démarrer la machine par exemple, eh bien la machine ne démarrera plus et puis, quand la machine ne démarre plus, eh bien on ne peut plus en faire grand-chose ! Donc il y a ce risque-là.

Tout ça, ça crée de vraies limitations à la possibilité même de libérer le logiciel.

19' 53

Et alors, ce logiciel, on en trouve donc dans pas mal de composants.