Le problème : faire confiance sans pouvoir vérifier
Lorsque vous installez une application de babyphone, vous lui donnez accès à un lieu très intime : la chambre de votre bébé. L’application écoute, et parfois elle surveille aussi par vidéo. Pourtant, les parents ne peuvent souvent pas savoir ce qui se passe en arrière-plan : les flux passent-ils par des serveurs tiers, des données d’utilisation sont-elles collectées, qui peut techniquement y accéder ?
La réponse honnête : avec beaucoup d’applications, vous ne le savez pas. Le code est fermé et l’architecture décrite reste une simple affirmation. Au final, on vous demande de croire le fournisseur sur parole.
Code fermé, failles ouvertes
Ces dernières années, les signalements de babyphones piratés ont été nombreux. Des inconnus pouvaient écouter, orienter les caméras ou parler par les haut-parleurs. La plupart du temps, il ne s’agissait pas d’attaques sophistiquées, mais de graves défaillances : connexions non chiffrées, mots de passe par défaut, authentification absente.
Avec les logiciels propriétaires, les personnes extérieures ne découvrent souvent ces faiblesses qu’après un incident. Les chercheurs en sécurité, les développeurs indépendants et les parents ne peuvent examiner le produit fini que de l’extérieur. Pour un appareil installé dans la chambre d’un bébé, ce modèle est insuffisant.
La transparence comme principe de sécurité
La sécurité informatique repose sur une règle ancienne et utile : le principe de Kerckhoffs. La sécurité ne doit pas dépendre du secret de la conception. Un système doit rester sûr même lorsque l’on sait comment il est construit.
Du code documenté publiquement ne rend pas un logiciel sûr à lui seul. Mais il permet de vérifier les affirmations. Les personnes qui connaissent le sujet peuvent examiner les flux de données, la dérivation des clés et les règles, au lieu de se fier au discours marketing.
L’approche de Timmy : un socle de sécurité séparé
Dans Timmy, je distingue désormais très clairement les éléments qui sont réellement essentiels à la sécurité. Tous les éléments de l’interface ne déterminent pas si le produit mérite votre confiance. Les éléments décisifs sont la logique côté serveur, les contrats de signalisation, la cryptographie d’appairage et la question de savoir quelles données atteignent un serveur.
C’est pourquoi le socle de sécurité se trouve désormais dans le dépôt public baby-monitor-timmy-core. Le code complet de l’application n’est pas public pour le moment. Les composants essentiels à la sécurité sont séparés de l’interface et de la logique produit afin de pouvoir être documentés et examinés indépendamment.
Concrètement, qu’est-ce que cela signifie ?
- Des limites claires : les composants de sécurité sont séparés de l’interface et de la logique produit.
- Des flux de données vérifiables : l’appairage, la signalisation et les interfaces côté serveur peuvent être documentés séparément.
- Aucun traceur caché : les chemins critiques ne contiennent que ce qui y a techniquement sa place.
- Une maintenance durable : un socle séparé est plus facile à examiner qu’un monolithe non structuré.
Conclusion : les parents méritent de la transparence
Lorsqu’une application a accès à la chambre d’un bébé, elle doit répondre clairement aux questions essentielles : quelles données sont créées ? Où vont-elles ? Qui peut les lire ? Les parents méritent davantage qu’un badge de confidentialité en bas de page.
Baby Monitor Timmy doit montrer qu’un bon produit peut aller de pair avec une sécurité vérifiable. Pour moi, cela ne veut pas dire rendre public chaque recoin de l’application. Cela signifie ouvrir les parties qui déterminent l’appairage, la signalisation, l’accès au serveur et les flux de données.