Mesh Networking et privacy by design ?

La semaine dernière sur Twitter et ce weekend ici même, nous alertions sur le fait que l'application mobile Firechat d'OpenGarden pourrait être dangereuse à utiliser dans certains contextes. En l'état, nous maintenons cet avertissement, mais il me semble important de préciser pas mal de points pour que cet avertissement soit bien compris. Il s'agit pour nous d'expliquer que contrairement à ce qu'une grande partie de la presse française a relayé, Firechat n'est actuellement pas une application pensée pour contourner la censure, pour la bonne et simple raison qu'elle n'a pas été développée avec cette problématique en ligne de mire. La protection de l'identité des utilisateurs n'a pas été dans la logique de son développement, Firechat n'est pas comme le souligne d'ailleurs OpenGarden, une application de comsec (communications sécurisées), elle doit plutôt être envisagée comme un réseau social local communiquant les contenus à Internet de manière publique.

Soulignons également que Firechat a pris en compte certaines remarques que nous lui avons objecté et la migration de l'infrastructure en cours vers le cloud d'Amazon a semble t-il été l'occasion de pas mal de corrections/ sécurisation.

Quelques gros mots un peu techniques

Il faut maintenant comprendre un peu de quoi nous parlons, et pour cela, parler un peu de technique. On va se rendre compte assez rapidement que le concept de "privacy by design", ce n'est pas la première fois qu'on vous le dit ici, sur un smartphone, c'est essentiellement un beau principe. Le chiffrement du transport des données que l'on reproche à OpenGarden de ne pas avoir intégré à Firechat n'est qu'une toute petite partie de de la "sécurisation" de cette application... Explications :

Le chiffrement des communications comporte quelques écueils car il ne vous aura pas échappé que Firechat est une application fonctionnant en mesh sur deux protocoles principaux distincts : le WiFi et le Bluetooth... et comme vous vous en doutez, le WPA2 en bluetooth, ça ne fonctionne pas vraiment. Le chiffrement doit prendre en compte un autre problème inhérent à la nature d'un réseau chaotique : la connexion n'est pas permanente, elle saute régulièrement, la session et le chiffrement aussi. Un projet de recherche sous l'égide de la Commission Européenne, Haggle, propose une avancée significative en matière de chiffrement en environnement chaotique.
Sur un réseau maillé, le routage est lui aussi chaotique, divers protocoles de routages mesh existent, mais peu se sont penchés sur l'authentification de paire à paire. J'entends par authentification de s'assurer de manière transparente que le point A communique avec le point B et non un tiers X. C'est là que ça se complique et c'est certainement pour répondre à ce problème qu'OpenGarden propose par défaut l'ouverture d'un compte pour utiliser son application... ce qui concorderait assez avec ses projets actuels d'ajouter des messages privés à Firechat. Mais tout de suite... on perd un peu de la magie du mesh.

Passons maintenant aux problématiques de sécurité en environnement hostile, mais qui dépassent de loin le cadre de l'application dont nous parlons :

Le chiffrement local des contenus sur votre appareil : le plus gros trou de sécurité, c'est votre téléphone et son système d'exploitation. Une société comme Micro Systemation se fera une joie de vendre ses petits jouets de forensic, et là, votre vous avez beau avoir un super iPhone, il reste une passoire face à ce jouet.

https://www.youtube.com/watch?v=EKo8HEJkCDM

Le chipset GSM capable d'émettre téléphone éteint est aussi un gros problème en zone de conflits... une véritable balise de signalisation pour bombardement.

Vous voulez manifester "secure" ? Ne prenez pas votre téléphone, les pigeons voyageurs sont plus "sécurisés" car eux ne se baladent pas avec votre carnet de contacts ou l'historique de vos communications.

Elargissons un peu...

Nous sommes en 2014, nous ne découvrons plus Internet et les problèmes inhérents à l'appréhension d'un espace public. Plus que jamais, les développeurs ont de lourdes responsabilités lorsqu'ils offrent au public une application. La sécurité des applications que nous utilisons sur Internet et leur faculté à faire face aux menaces auxquelles elles sont inéluctablement exposées s'est considérablement complexifiée. L'utilisation de code tiers (librairies, frameworks...) ont ajouté une couche supplémentaire de complexité aux architectures classiques. S'il peut paraître à priori une bonne idée de se focaliser sur l'application elle-même, on se rend compte que dans l'Internet réel, les menaces ne sont pas toujours celles auxquelles un développeur pensera naturellement.

La question de la confidentialité et de la protection des données personnelles des utilisateurs répond à une logique encore plus complexe car elle dépasse de loin le périmètre de l'application elle même, au centre de laquelle se trouve une variable très complexe, que j'ai coutume de nommer la variable PFH (pour Pu@%!* de Facteur Humain).

Quand on développe une application, on s'attend à ce que ses utilisateurs l'utilisent de la manière dont on souhaiterait qu'ils l'utilisent. On fait de belles documentations, on explique comment ça fonctionne, ce qu'il faut faire et ne pas faire. Mais un utilisateur, c'est un animal complexe. Chose hallucinante pour un développeur, l'utilisateur ne lit jamais les belles documentations qu'il a passé un temps fou à écrire. L'utilisateur fait tout, souvent n'importe quoi, et rarement ce qu'on lui dit de faire. Souvent, cette caractéristique de l'utilisateur, inhérente à la nature humaine, ne prête pas à conséquences. Il y a même pour le développeur un aspect jubilatoire à voir ce qu'un utilisateur va pouvoir faire avec son application et qu'il n'aurait jamais prévu.

Dans d'autres cas, malheureusement eux aussi assez fréquents, l'utilisateur a des usages un peu plus malheureux que ce pour lesquels un développeur les avait prédestinés dans sa documentation. Et en principe, dans ces cas là, les utilisateurs s'exposent à un risque, tout simplement parce qu'il n'a pas été évalué comme tel au développement de l'application.

Dans le contexte actuel de certains pays, une application, surtout mobile, a maintenant une responsabilité très lourde, celle de protéger les utilisateurs de leurs usages "contre nature". La variable PFH devrait être intégrée dans le cadre de tous les développements d'applications. Le cas que nous avons traité en parlant de Firechat suite à un gros battage médiatique, n'est qu'un cas parmi tant d'autres. Peut-être est il aujourd'hui temps pour chaque développeur de se poser de nouvelles questions lors de la conception d'une application pour aider les utilisateurs à se protéger d'eux mêmes.