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

Submitted by mmorandi on 30 August, 2016 - 14:52

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
Licence : Verbatim
Durée : 50 min 15
Pour visionner la vidéo
Pour télécharger la présentation

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 passant par les micro-logiciels.

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.

Transcription

Je m'appelle Paul Kocialkowski. Je suis développeur Replicant1 et je vais vous parler un petit peu d’appareils mobiles, de vie privée, 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 GPU2 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 GSM3. 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 l'é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 si 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ées dans les années 80. Il s'agit de pouvoir utiliser le logiciel ou la technologie, en fait 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 designs,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 puces à 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 silicon (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, mais, 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'Arduino4 est un exemple connu de carte 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.

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 toute façon 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 GTA04 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 créé 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 et d'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 à peu près 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 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 voie 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, eh bien 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.

Ça c'est la gauche d'auteur, c'est très bien, et ça nous permet donc d'avoir du logiciel libre dans ces cas-là. Mais, pour le coup, la qualité du code qui est ainsi produit est souvent très médiocre et personne n'a vraiment envie d'utiliser ça. Du coup, 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 accès 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, ce qui 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 RSA5. 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ébugger. 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ébugger. 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ébugger, 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ébugger, 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.

Et alors, ce logiciel, on en trouve donc dans pas mal de composants. J’ai mentionné un petit peu tous les processeurs qu’il y avait, tout à l’heure. Donc on les retrouve, tous ces processeurs, mais il y a aussi des logiciels qui s’exécutent dans les contrôleurs, les périphériques. Donc même la batterie d’un ordinateur portable, il y a microcontrôleur dedans, donc un processeur avec un logiciel qui s’exécute dessus, dans la batterie même, même pas dans l'ordinateur, c’est vraiment dans la batterie. Et ça, il y en a dans des tas et des tas de contrôleurs et de périphériques. Chaque clef USB a un microcontrôleur à l’intérieur. Chaque carte SD a un microcontrôleur à l’intérieur. Tout ça c’est du logiciel qui s’exécute et qu’on aimerait bien pouvoir libérer.

Et donc ces logiciels, on va pouvoir les catégoriser en différents types. Le premier ce sont les micrologiciels. Donc ce sont, en fait, des logiciels qui sont très simples, très petits, qui exécutent une tâche très particulière. Typiquement dans le cas de la batterie, il va s’agir de contrôler la charge de la batterie et ça ne fera rien d'autre que ça. Donc c'est un logiciel qui a une tâche très particulière, on appelle ça un micrologiciel. Ce n'est pas très complexe et ce n'est pas très gros en termes de taille binaire.

Ensuite on a les logiciels de démarrage, donc ce sont les logiciels qui vont permettre de faire démarrer la machine, tout ce qu'on a, en fait, avant le système d'exploitation. C’est ce qu’on a appelé le BIOS, que maintenant on appelle l'UEFI, toutes ces choses-là qui font simplement démarrer la machine, c’est aussi du logiciel évidemment.

Ensuite on a quelque chose qu’on appelle les environnements logiciels de confiance, sur lesquels je reviendrai. Ce sont des choses qui s’exécutent en parallèle du système d’exploitation. Donc c’est plus gros, pour le coup, qu’un micrologiciel ou un logiciel de démarrage. C'est un petit système d'exploitation qui va s'exécuter à part, en parallèle du système d’exploitation qu’on exécute.

Et puis enfin il y a le gros système d'exploitation qu'on connaît. Typiquement : GNU/Linux, Android, tout ça.

Si on regarde, en fait, dans la plupart des cas, on s'intéresse à la libération du système d'exploitation, mais il ne faut pas oublier qu'il y a aussi beaucoup d’autres logiciels qui s'exécutent à plein d'endroits sur tous les ordinateurs, les appareils mobiles.

Pour détailler un petit peu la situation par rapport aux micrologiciels : ceux-ci s'exécutent sur les contrôleurs, les périphériques et les processeurs auxiliaires parce qu'encore une fois ils exécutent une tâche très particulière. Le logiciel libre les prend assez mal en charge, c’est-à-dire qu’il n’y a que quelques matériels très spécifiques pour lesquels on a des micrologiciels libres. C’est le cas de l'Arduino, encore une fois, qui est un exemple assez connu, le BusPirate, FX2LA, donc ce sont des choses, des outils en fait de débuggage qui exécutent un micrologiciel libre. C'est encore une fois des choses très spécifiques.

Une nouveauté de ces dernières années c’est dans les périphériques Wi-Fi, notamment avec le ath9k.htc, donc le logiciel qui s'exécute sur la puce Wi-Fi elle-même est libre et a été libéré par le fabricant. Donc ça c'est vraiment une grosse avancée, parce que ce n'était pas le cas jusque-là. Il y avait quelques exemples, donc ces deux-là, qui avaient été libérés par la communauté et qui fonctionnaient plus ou moins bien. Là, dans le cas du ath9k.htc c'est vraiment le fabricant qui a mis à disposition la version officielle du micrologiciel, donc on sait qu'elle marche et elle marche même plutôt bien.

Pour en revenir aux appareils mobiles, la plupart des micrologiciels qui sont exécutés sont propriétaires, mais ils sont rarement vérifiés. Donc on pourrait, avec beaucoup de travail, espérer les libérer un jour.

Ces micrologiciels sont soit préinstallés dans une mémoire proche, donc soit du processeur auxiliaire en question, du contrôleur, du périphérique, soit ils sont envoyés par le système d’exploitation au moment du démarrage. C'est pour ça que plusieurs systèmes d'exploitation vont distribuer ces micrologiciels avec le système. Et, dans les appareils mobiles, on trouve des micrologiciels dans plein de choses en fait. Les exemples les plus visibles c'est Wi-Fi, Bluetooth, GPS. Mais dans tous les processeurs de traitements multimédia, les caméras, là-dedans il y a des micrologiciels qui s’exécutent. Donc en général, pour les appareils mobiles, ces micrologiciels-là sont propriétaires.

Maintenant j'en viens au processeur de communication, qu’on appelle aussi le modem, qui est un exemple assez particulier. C'est un processeur très puissant, qui exécute un vrai système d’exploitation complet, dans le sens où il y a effectivement un noyau, des applications, et plein de choses. C'est très gros, c'est très puissant. Dans certains cas ce sont des processeurs qui sont comparables au processeur principal en termes de capacités. Tout ça c’est relié à des interfaces radiofréquences qui vont permettre de communiquer avec le réseau téléphonique.

Et pour le modem, les systèmes d'exploitation qui s'exécutent là-dessus sont tous propriétaires pour les appareils modernes et ce n'est pas toujours possible de remplacer le système, justement à cause de ce problème de vérification du logiciel, donc avec des signatures. Et encore une fois, dans beaucoup de cas, on sait qu'on ne pourrait même pas écrire un logiciel libre pour le modem.

Pour autant il y a une pile GSM libre qui existe, c'est le projet OsmocomBB, et qui prend, en fait, en charge de vieux appareils, donc c'est assez limité. Ce sont vraiment des vieux téléphones, donc ce sont des Motorola C123, ce genre de choses. Donc ce sont des choses qui n’ont pas d’écran tactile, ce sont des tout petits écrans avec des gros pavés, enfin les premiers téléphones mobiles qu’on connaissait. Donc pour ça il y a donc cette pile GSM libre, qui existe, qui s’exécute sur le modem lui-même. Mais, encore une fois, il y a des problèmes qui se posent. Là, c'est notamment au niveau de la certification, parce que ce sont des logiciels qui vont interagir avec un réseau public et, du coup, ils doivent répondre à certaines normes et ils doivent donc être certifiés. Et du point de vue du logiciel libre ce n’est pas forcément simple ou compatible de faire certifier un logiciel que tout le monde peut modifier. Mais ce n'est pas impossible non plus, je veux dire. Il y a des exemples où ça a été fait. C'est plus un effort supplémentaire à fournir.

Mais, si on y regarde de près, c’est quand même un énorme problème pour la liberté et la vie privée, parce que ce composant-là, donc le modem, il a finalement accès au matériel. Parce que le modem, il faut quand même qu’il ait accès au son : si vous voulez pouvoir appeler quelqu'un il faut qu’il envoie votre voix au réseau téléphonique. Donc potentiellement il a accès au microphone. Et puis, parfois, il a également accès au GPS, il a également accès à la caméra, il a également accès aux données de l’utilisateur, il a également accès à la RAM. Dans certains cas, c’est simplement comme ça que le design matériel a été fait et on ne peut rien y faire, en fait. Le téléphone a été conçu comme ça et voilà !

Donc ils ont une très forte capacité à espionner l'utilisateur. Ils ont accès à beaucoup de données et, potentiellement, il peut même compromettre le processeur principal s’il a accès à la RAM principale ou à la mémoire de stockage principale. Il peut simplement réécrire des parties du système d'exploitation. Du coup c'est compromis et on ne peut plus rien y faire !

C'est pour ça qu'on s'intéresse à une solution de contournement qu'on appelle isolation du modem. Il s'agit, en fait, de vérifier sur les schémas électriques que le modem a accès uniquement aux périphériques dont il a besoin. C'est-à-dire qu’il a accès à son antenne, qu’il a accès à la voix quand on l’autorise, qu’il a accès au microphone quand on l’autorise et que, dans tous les autres cas, il n'a accès à rien d'autre et il ne peut rien faire d’autre. C’est-à-dire qu’il ne peut pas accéder à la mémoire, il ne peut pas accéder à la RAM, toutes ces choses-là.

La question c’est comment, du coup, on vérifie en pratique que c’est le cas ? En fait on ne peut pas vraiment. Parce que, même si on a accès aux schémas du téléphone, rien ne nous assure que ces schémas correspondent effectivement aux vraies cartes. Le fabricant peut très bien mettre à disposition des schémas, enlever les parties qui relient le modem, je ne sais pas, à la mémoire de stockage et, simplement, on ne pourra pas aller vérifier sur la carte parce que c’est beaucoup trop petit et qu’il faut des moyens de vérification qui sont très élaborés. Donc, finalement, on ne pourra pas prouver que l'isolation du modem est bonne. Par contre, quand on a des indices que l’isolation du modem est mauvaise, on pourra dire « on sait que c’est mauvais et du coup va essayer d’éviter ce modèle-là, par exemple. »

Il y a aussi certains cas où le modem est intégré au processeur principal. Là on peut se douter qu’il a accès à tout ce à quoi tout le processeur principal a accès, y compris la mémoire de stockage, tout ça. Donc très mauvais !

Pour le coup, si on pouvait effectivement avoir du matériel libre, on pourrait s'assurer que le modem n'est connecté à rien d’autre que ce qu’on veut, puisqu’il suffirait de créer une nouvelle version de la carte avec les schémas qu’on a nous-mêmes vérifiés et là on serait sûrs, encore une fois, aux questions de confiance près que j'évoquais tout à l'heure.

Après, il s’agit encore d’une solution de contournement, dans le sens où il y a d’autres moyens d’espionner l’utilisateur. Typiquement, quand on envoie de la voix au réseau téléphonique, le réseau téléphonique lui-même peut tout à fait enregistrer la voix, enregistrer les messages qu’on envoie, toutes ces choses-là. Donc la seule capacité d’écoute et d’espionnage n’est pas sur le téléphone ; il y a aussi le réseau téléphonique lui-même qui a une grosse capacité d’espionnage, mais ça on n'y peut rien ! Et le mieux qu'on peut faire, c'est simplement faire voter des lois pour qu'il y ait des contrôles et des choses fiables qui nous garantissent qu'il n'y a pas ce genre de pratique chez les opérateurs. Aujourd'hui ce n'est pas vraiment le cas !

Et encore une fois, si je reviens aux questions de liberté, en fait l'isolation du modem c'est intéressant du point de vue de la vie privée et de la sécurité, mais ça ne nous avance à rien du point de vue de la liberté. On n'a pas plus de connaissances sur le fonctionnement du modem, on ne l'a pas plus remplacé par du logiciel libre. Donc c’est une solution pragmatique et qui, encore une fois, n’est pas fiable puisqu'on ne peut pas vérifier de manière sûre que l'isolation est bonne.

J'en viens maintenant au processeur principal : le processeur principal exécute différentes couches de logiciels. La première ce sont les logiciels de démarrage qui permettent d'initialiser tout le matériel et de charger le système d'exploitation, mais il va aussi charger l'environnement logiciel de confiance sur lequel je reviendrai un petit peu après, et le système d'exploitation lui-même, on va le découper en plusieurs couches.

La première c'est le noyau, le noyau Linux qui gère les interactions avec le matériel.

On a ensuite les couches d'abstraction matérielle qui sont des petits logiciels qui vont, en fait, interagir avec le noyau pour faire fonctionner le matériel. Il faut savoir que, dans la plupart des appareils mobiles, le noyau lui-même fait assez peu de choses du point de vue du matériel, ce sont surtout ces couches d’abstraction matérielle qui vont interagir avec le matériel directement. Le noyau va surtout assurer une couche de transport, en fait, entre les deux. On a ensuite des frameworks qui sont des couches d'abstraction pour les applications, qui vont permettre d'accéder au matériel sans connaître les spécificités de chaque téléphone, et ensuite on a donc les applications elles-mêmes. Tout ça c'est une question, encore une fois, d'abstraction, de permettre aux développeurs d'écrire des applications sans viser un modèle en particulier mais juste en disant « je veux accéder à la caméra » et puis les couches d'abstraction matérielle se débrouillent pour trouver les détails de comment on accède à la caméra et comment on fait ce genre de choses.

Un point sur les logiciels de démarrage. Tout commence par ce qu'on appelle la Boot ROM qui est, dans les appareils mobiles, un bout de logiciel qui est préinstallé à l'intérieur même de la puce qui contient le processeur qu'on appelle le système monochip. C'est installé dans une mémoire non ré-inscriptible, donc on peut l'assimiler à du matériel, encore une fois. Ce n'est pas quelque chose qu'on peut modifier, c'est du matériel et on n'y peut rien, c'est comme ça et ça restera comme ça.

Maintenant cette Boot ROM, elle peut, ou pas, effectuer des vérifications de signatures, donc ce que j'ai mentionné un petit peu plus tôt. Elle peut vérifier les étapes suivantes avec une clef qu'on ne pourra pas modifier et, dans ce cas-là, on ne pourra simplement pas exécuter du logiciel libre dans les couches suivantes.

Ce comportement-là est vraiment très spécifique à la plate-forme. Il y a certaines plates-formes qui vont effectuer ces vérifications de signature, d'autres qui ne vont pas les vérifier. Voilà des exemples de bonnes plates-formes qui n’effectuent pas ces vérifications et qui permettent donc d'exécuter des logiciels de démarrage libres. Plusieurs exemples : U-Boot, qui est vraiment le logiciel libre de démarrage de référence pour le matériel embarqué, y compris les appareils mobiles. On a aussi Coreboot qui, traditionnellement, était plutôt orienté vers les ordinateurs x86, donc les ordinateurs de bureau, les laptops, qui, maintenant, prend en charge aussi des plates-formes mobiles et qu'on trouve dans plusieurs appareils, notamment la tablette Pixel C de Google démarre avec Coreboot. Cependant elle utilise une plate-forme qui vérifie les signatures. Donc, même si c'est Coreboot, c’est une version de Coreboot qui est signée, qu'on ne peut pas modifier. C'est dommage !

Et donc, si on regarde dans le cas des appareils mobiles, il y a très peu d'appareils mobiles qui sont vendus avec des logiciels de démarrage libres et non signés. Il y a quelques exemples très rares. Dans d'autres cas on pourra libérer les logiciels de démarrage, et encore dans d'autres cas, les logiciels de démarrage seront signés, on ne pourra simplement pas les remplacer et on ne peut rien y faire.

J'en arrive à cet environnement logiciel de confiance. De quoi il s'agit ? Ça part d'un constat qui est que le système d'exploitation est imparfait parce que l'utilisateur installe plein d'applications dessus et il y a beaucoup de possibilités, pour ce système d’exploitation, d’être compromis : si on installe n'importe quoi et qu'il y a un malware qui arrive, un rootkit, ce genre de choses. Donc on va partir du principe que le système d'exploitation est imparfait mais que, pourtant, on a besoin d’effectuer des opérations sensibles au niveau de la vie privée et de la sécurité, donc typiquement taper, je ne sais pas, un code pour se connecter à sa banque ou ce genre de choses. Pour effectuer ces opérations sensibles on va, en fait, utiliser un environnement de logiciels de confiance, c'est-à-dire un petit système qui s'exécute de manière indépendante du système d'exploitation principal. Pour ça, on a besoin d'une certaine coopération avec la puce. C'est ce qu'on appelle TrustZone dans le cas des appareils mobiles ARM. C'est, en fait, un espace d’exécution séparé au niveau du processeur, auquel le système d'exploitation principal ne peut pas avoir accès et qui est mis en place au niveau du logiciel de démarrage.

Cet environnement de confiance s'exécute dans un mode privilégié, qui a accès à plus de matériel et qui peut, en fait, bloquer l'accès au matériel pour le système principal. Et, en fait, le système principal va communiquer avec, grâce à une instruction spécifique, qui s'appelle Secure Monitor Call, et qui va lui permettre de communiquer, donc de mettre en place typiquement ces contextes sécurisés quand on veut taper un code. Il va dire à l'environnement logiciel de confiance « il faut taper un code pour la banque » et c'est l'environnement logiciel de confiance qui va réceptionner le code et qui va faire ce qu'il faut avec. Et comme ça, en fait, le système d'exploitation principal, s'il est compromis, ne verra simplement pas passer le code et donc il n'y a pas de risque de perdre ses données.

Tout ça, ça suppose qu'une fois que l'environnement logiciel de confiance est mis en place, il ne peut pas être modifié, il ne peut pas être remplacé.

Donc tout ça, ça semble bien pour la sécurité, c’est un design qui marche. Donc ce n'est pas quelque chose qui est bon ou mauvais en soi, mais c'est quand même quelque chose de très privilégié, qui a accès a beaucoup de choses et donc il y a de fortes implications pour la vie privée et la sécurité.

Il y a des implémentations libres qui existent pour ces environnements logiciels de confiance, mais tout ça dépend du logiciel de démarrage. Parce que si le logiciel de démarrage met en place cet environnement de confiance et si on ne peut pas modifier le logiciel de démarrage, c’est-à-dire s'il est propriétaire, eh bien on va avoir un environnement logiciel de confiance propriétaire, qu'on ne pourra pas changer plus tard dans l'exécution et donc on aura un composant propriétaire très privilégié qui s'exécute et qui fait on ne sait quoi. Donc c'est un vrai problème.

Il y a des exemples d'appareils qui permettent de mettre en place des environnements logiciels de confiance libres. C’est le cas de l’USB armory qui utilise une puce i.MX53. C’est aussi le cas des nouvelles puces Rockchip. Celles-là, si on a un logiciel de démarrage libre, on peut charger un environnement de confiance libre.

Il se trouve qu’en pratique, quand sur les appareils mobiles on a des chargeurs de démarrage signés et propriétaires, on a aussi des environnements de confiance signés et propriétaires, donc un gros problème pour la liberté et la vie privée.

J’en reviens au système d’exploitation dans le détail. Effectivement, il est crucial pour la vie privée et la sécurité parce que le système d’exploitation a accès, quand même, à tous les contrôleurs et les périphériques d’entrée/sortie, à toutes les données, à toutes les communications de l’utilisateur. Il peut même, parfois, donner des accès privilégiés au modem ce qui était le cas, ce qui est toujours le cas d’ailleurs, sur les appareils Samsung. C’est un article que j’ai écrit sur le Samsung Galaxy back-door et qui montre que le logiciel qui s’exécute sur le système d’exploitation et qui communique avec le modem, lui donne accès à l’ensemble du système de fichiers du système d’exploitation. Donc toutes les données sont accessibles depuis le modem.

C’est aussi au premier plan du logiciel libre parce que c’est avec ça qu’interagit l’utilisateur. C’est donc ça que l’utilisateur va avant tout avoir envie de modifier et de comprendre. Et, quand on veut faire de nouvelles versions du logiciel, c’est ça qu’on va vouloir mettre à jour, c’est avant tout le système d’exploitation. Finalement, mettre à jour son chargeur de démarrage, enfin son logiciel de démarrage, ça intéresse moins de monde. J’ai parlé de ces différentes couches du système d’exploitation. Donc on a le noyau, qui est Linux dans la plupart des cas, qui est libre. Il y a ces versions modifiées créées par les fabricants pour les spécificités de leur matériel. On a ensuite ces couches d’abstraction matérielle qui sont privatrices en majorité.

Au niveau des frameworks, il n’y pas beaucoup d’intelligence dans les frameworks, c’est surtout de l’abstraction. C’est libre, pour la plupart des systèmes à peu près libres qu’on connaît, donc Android, FirefoxOS, Ubuntu Touch, tout ça. Tout ça, ça utilise des frameworks libres. Et pour les applications, il y a beaucoup d’applications libres qui existent, et un dépôt d’applications pour Android libre c’est F-Droid et il y a des milliers d’applications dedans, donc ce n’est pas mal !

Si on revient sur ces couches d’abstraction matérielle, généralement les aspects qui sont propriétaires c’est l’accélération graphique et la 3D, donc le GPU. Souvent le GPS aussi. Donc ça, on a beaucoup de mal à le faire avec du logiciel libre pour les appareils mobiles.

Selon les plateformes, on peut aussi avoir des problèmes avec caméra et audio. Ce n’est, encore une fois, pas toujours simple à libérer. Mais il y a des projets qui s’attaquent à ces tâches un peu compliquées. Pour les GPU on a Freedreno, Nouveau et Lima qui s’attaquent, chacun, à différents types de GPU.

Mais, quand on a des couches privatrices, on peut se poser la question « est-ce qu’elles sont vraiment nécessaires ? » Si, par exemple, ça gère l’audio, on a quand même envie d’avoir de l’audio, donc c’est compliqué de s’en passer. Par contre, pour d’autres choses comme la 3D, on peut imaginer utiliser un appareil mobile sans 3D, ça ne pose pas trop de problèmes.

Ensuite, quand il y a des composants propriétaires, ils s’exécutent avec un certain nombre de privilèges, donc là aussi, ils peuvent avoir accès aux données et aux communications de l'utilisateur. Et ils détiennent aussi le savoir du fonctionnement du matériel. Donc si on cherche à comprendre comment fonctionne son matériel et que le logiciel est propriétaire, eh bien on est bloqué.

Pour dresser un petit bilan : la situation est très clairement imparfaite. Les appareils mobiles peuvent être, par beaucoup d’aspects, compromis. Donc les données, les communications peuvent être espionnées dans la plupart des cas. Maintenant, il faut pouvoir évaluer les enjeux qu’on a personnellement, il faut pouvoir évaluer les niveaux de confiance qu’on attend de ces appareils-là. Très clairement, si on a un besoin de sécurité et de vie privée très fort, il vaut mieux ne pas s’en servir du tout. Il est clair que ces appareils-là ont un potentiel d’espionnage énorme, donc il faut savoir s’en séparer quand on a besoin d’un certain niveau de sécurité.

Pour le moment il y a assez peu de choses qu’on peut faire à très court terme, parce qu’il y a très peu de développeurs qui travaillent sur ces sujets-là. C’est pour ça qu’on a un besoin très fort de développeurs et finalement à court et moyen termes il y a quand même quelques choses qu’on peut faire. On peut essayer de libérer le système du processeur principal, parce que finalement il y a déjà des composants libres, donc le noyau, quelques couches d’abstraction matérielle, les frameworks et les applications, donc c’est là qu’il y a le moins de travail. Et on peut essayer de choisir ces bonnes plateformes sur lesquelles on va pouvoir exécuter un logiciel de démarrage libre, un environnement de confiance libre, ce genre de choses.

Et on va enfin s’intéresser à l’aspect isolation du modem pour s’assurer qu’il n’a pas accès aux données et aux communications quand on ne l’autorise pas.

Enfin, si on veut être vraiment sûr, eh bien l’idéal ce serait de produire des appareils mobiles nous-mêmes, c’est-à-dire que la communauté produise des appareils mobiles pour pouvoir s’assurer de tous ces aspects.

Dans l’idée de créer un système libre, le projet Replicant est un système entièrement libre pour les appareils mobiles. Il s’agit d’utiliser Android et d’enlever tous les composants propriétaires pour en faire une distribution entièrement composée de logiciels libres et qui respecte la GNU FSDG6 qui sont les recommandations pour les distributions d’un système libre du projet GNU.

Le projet Replicant met également un accent sur la vie privée et la sécurité, avec des fonctionnalités dans ce sens-là. Mais il s’agit avant tout d’avoir un système qui est fonctionnel et utilisable. Ce n’est pas juste une sorte d’expérimentation théorique qui ne produit rien d’utilisable. Il s’agit vraiment de créer un système qu’on peut utiliser en vrai.

Et il s’agit aussi de produire de l’information et de la documentation sur tous les aspects que je viens de mentionner et sur le système lui-même, pour que ce ne soit pas compliqué ou pas trop compliqué de l’installer, de l’utiliser.

Actuellement il y a très peu de développeurs : je suis essentiellement le seul développeur actif. Il y a aussi un collègue allemand qui vient de se joindre au projet et qui commence à contribuer, donc c’est bien, mais on n'est toujours que deux. Ce n’est pas énorme ! Donc peu de contributions externes de gens qui ne sont vraiment pas directement en lien avec le projet. Quelques pages de sécurité, mais c’est assez faible. Il y en a de plus en plus, mais ça reste quand même faible.

À l’heure actuelle il y a douze appareils qui sont pris en charge : ce sont essentiellement des appareils Samsung Galaxy et Nexus de Google. Il manque pas mal de fonctionnalités qui ne fonctionnent simplement pas avec du logiciel libre donc ce que j’ai mentionné : GPS, 3D, accélération graphique, ce genre de choses.

C’est basé sur CyanogenMod 10.1 qui est une base Android 4.2, donc c’est assez vieux, si on regarde. Le projet est soutenu financièrement par des dons, et actuellement la dernière version qui est sortie c’est 4.2.004.

Donc ça c’est l’ensemble des appareils pris en charge par Replicant. Donc il y en a une majorité qui sont encore maintenus, quelques-uns qui sont vieux et qu’on a arrêté de prendre en charge aussi parce qu’ils sont très mauvais pour la vie privée et la sécurité. Et un appareil qui n’est pas encore complété.

Il y a des questions qui se posent pour le futur : est-ce qu’on peut avoir confiance dans CyanogemMod, donc la version d’Android qu’on utilise comme base pour Replicant, puisque les contributeurs à ce système ont fondé une entreprise qui en fait un dérivé semi-libre/semi-propriétaire ? Et, on va dire, il y a des investissements un peu louches dans cette entreprise, essentiellement Microsoft qui a investi pas mal d’argent dans cette entreprise. Donc on peut se poser la question de « est-ce que leur motivation sera encore proche de celle du logiciel libre, ou plus vraiment ? » Donc il y a une question de confiance.

On aimerait aussi prendre en charge de nouvelles versions d’Android parce que 4.2 c’est assez vieux. On aimerait prendre en charge plus d’appareils, évidemment.

Maintenant, les applications de base du système qui étaient écrites par Google dans le cadre de l’Android Open Source Project, qui est la version nue et libre d’Android, mais qui ne fonctionne pas sur les appareils, en fait, que Google met à disposition, il y avait dans cette version-là, des applications de base du système, des choses bêtes : appareil photos, galerie, navigateur Web, ce genre de choses, qui étaient libres et que Google maintenait. Et, en fait, Google a progressivement remplacé ça par des versions propriétaires et a arrêté de mettre à jour ces versions libres. Du coup on se retrouve avec des applications qui ont mal vieilli, qui ne sont plus maintenues, qui ont des bugs, et c’est un vrai problème.

Pour le futur, donc une version plus récente, améliorer la documentation sur plein d’aspects, faire des améliorations en plus pour la vie privée et la sécurité et donc, encore une fois, prendre en charge de meilleurs appareils. Je vais sauter le détail de la documentation.

Pour l’instant les appareils qui sont pris en charge, ceux-là on sait qu’ils ont une mauvaise isolation du modem, donc ce n’est pas terrible. Tous ceux-là ont des chargeurs de démarrage privateurs et signés, donc ça pose des gros problèmes pour la liberté. Du coup on aimerait bien prendre en charge des meilleurs appareils, soit avec des designs matériels libres ou au moins qui sont documentés. Voire des appareils sans modem, par exemple des tablettes qui ont simplement du Wi-Fi. Ou au moins des appareils qui ont des protocoles qu’on connaît et pour lesquels on peut écrire des logiciels libres, histoire d’avoir plus de matériel qui fonctionne.

Des appareils intéressants il y en a quelques-uns. La communauté OpenPhoenix s’est essentiellement regroupée autour de quelques entreprises allemandes qui créent des téléphones en très petites quantités, qui coûtent très cher parce qu’il faut des gros volumes pour avoir des prix bas, et ces entreprises n’ont pas de gros volumes. Donc si ça vous intéresse c’est toujours bien d’avoir plus d’intérêt pour ces projets-là, histoire qu’ils puissent produire en plus grande quantité et que ça coûte moins cher et que ça soit plus accessible.

Il y a certains appareils chinois qui sont peu coûteux, des tablettes de plusieurs puces en fait AllwInner et Rockchip et différentes puces, qui sont intéressantes pour le logiciel libre parce qu’il y a des grosses communautés derrière et des gens qui travaillent pour libérer ces choses-là.

Dans les appareils produits en masse, il y a l’Optimus Black de LG et le Kindle Fire première génération d’Amazon qui permettent d’exécuter un chargeur de démarrage libre, ce qui est intéressant. Et en fait, j’aimerais prendre ces appareils-là en charge par Replicant le plus rapidement possible.

Il y a aussi d’autres formats d’appareils qui peuvent être intéressants, comme ce qu’on appelle les Single Board Computers, donc simplement des petites cartes qui sont de petits ordinateurs et qui ont, en fait, un matériel très semblable aux appareils mobiles. On pourrait aussi exécuter Replicant là-dessus. Voilà.

Si vous souhaitez en apprendre plus à propos de Replicant on a un site web7, un blog8, un wiki9. On a une communauté grandissante, avec des forums, liste de discussion. On a aussi un canal un canal IRC, donc replicant chez freenode, si vous voulez venir bavarder un peu. Maintenant, clairement le projet a besoin de plus qu’un ou deux ou quelques développeurs. C’est une tâche de grande ampleur, il y a beaucoup de travail à faire donc toutes les contributions sont les bienvenues, qu’il s’agisse de contributions techniques ou financières, ou autres. Et effectivement, les dons sont bienvenus, parce qu’acheter des appareils ça coûte cher et avec mon petit budget d’étudiant, j’ai parfois du mal à acheter douze téléphones. Voilà, c’est bloqué. Il ne veut pas passer la slide. Merci pour votre écoute et si vous avez des questions, ça sera avec plaisir.

Applaudissements

Stéphane Bortzmeyer : Pour que les questions soient acceptées, il faut nous appeler au téléphone avec un téléphone Replicant.

Public :Bonjour. Déjà bravo pour ta présentation. Tu as évité complètement tout ce qui était jargon et c’était vraiment super. Bravo ! Ensuite une deuxième question. Tu as évoqué le sujet par rapport à l’environnement sécurisé qui est un peu une espèce de contradiction qu’on trouve entre la liberté et la sécurité, et je trouve qu’il y a exactement la même au niveau, effectivement, du chargement du boot, enfin le logiciel de chargement de boot. Comment on peut faire pour avoir un boot sécurisé et libre ?

Paul :Très bonne question. En fait il se trouve que je donne une présentation là-dessus, lundi, au track sécurité des RMLL, mais je crois que c’est complet, du coup c’est compliqué, mais il y aura sans doute une vidéo. Il y a pas mal de choses qu’on peut faire pour avoir, en fait, ce côté sécurité : donc vérifier les logiciels qu’on exécute, mais tout en gardant l’aspect logiciel libre. Et quelque chose de très intéressant qui a été fait c’est le modèle de sécurité des Chrome Books donc les machines de Google qui permettent d’avoir un boot où chaque étape est vérifiée, chaque étape est sûre et c’est tout du logiciel libre, dans le cas de certains Chrome Books, parce qu’il y a des composants propriétaires pour certains matériels, typiquement Intel. Mais c’est une solution. Alors je vais pas détailler la technique maintenant, mais il y a moyen de faire ça, c’est possible. Ce n’est pas forcément une contradiction. La vue de l’industrie, la vue qu’en a l’industrie pose ça comme une contradiction, mais il y a des moyens de faire ça en respectant la liberté et en assurant une certaine sécurité. D’autres questions peut-être ? Si c'est tout : Merci ! Merci encore !

Applaudissements