Maisons intelligentes : quels risques liés à la sécurité ?

Intelligentes, mais non sans faiblesses. Smart home via shutterstock.com

Les maisons intelligentes, l’une des déclinaisons de l’Internet des objets, offrent la promesse d’une meilleure efficacité énergétique et d’un contrôle sur la sécurité de la maison. Relier différents dispositifs peut permettre aux usagers la programmation facile de nombreux appareils dans la maison, comme les appareils ménagers, les caméras et les alarmes. Plusieurs systèmes peuvent fournir ce genre de service, Samsung SmartThings, Google Brillo/Weave, Apple HomeKit, Allseen Alljoyn et Amazon Alexa.

Mais il faut aussi prendre en compte les problèmes de sécurité. Les systèmes qui gèrent les maisons intelligentes risquent de laisser les utilisateurs désarmés face à de sérieuses menaces, comme l’incendie criminel, le vol et l’extorsion. La recherche actuelle sur les questions de sécurité s’est focalisée sur des dispositifs individuels et sur la façon dont ils se connectent les uns aux autres. Par exemple, le système MyQ garage est susceptible de se transformer en outil de surveillance, avertissant d’éventuels voleurs à l’ouverture et à la fermeture d’une porte de garage, et permettant sa réouverture à distance une fois les propriétaires partis. Quant au populaire protocole de communication ZigBee, il peut offrir à des agresseurs la possibilité de se connecter au réseau de sécurité de la maison.

Peu de travaux de recherche ont été menés sur ce qui se passe quand ces dispositifs sont intégrés dans un système coordonné. Nous nous sommes employés à déterminer exactement en quoi consistaient ces dangers, dans l’espoir de montrer aux concepteurs de plateformes les secteurs où ils devraient perfectionner leurs logiciels pour mieux protéger la sécurité des utilisateurs dans leurs futures maisons intelligentes.

Des produits SmartThings. Zon@ IT/YouTube, CC BY

Evaluer la sécurité des plateformes de maisons intelligentes

En premier lieu, nous avons examiné la plupart des plateformes citées plus haut afin de comprendre ce qui constitue la charpente de la programmation des maisons. Nous avons étudié les systèmes existants et les fonctionnalités offertes. Nous avons également examiné avec quels dispositifs ils pouvaient interagir, avec quelles applications, et combien de ces applications pouvaient être téléchargées sur leurs sites. Et, plus important, nous avons regardé leurs schémas de sécurité.

Nous avons décidé de nous concentrer sur la plateforme SmartThings parce qu’il s’agit d’un système relativement mature avec une offre de 521 applications dans son « app store », 521 applications qui permettent la mise en œuvre de 132 dispositifs de l’Internet des objets pour la maison. De plus, SmartThings présente nombre de ressemblances conceptuelles avec d’autres systèmes plus récents, ce qui élargit notre analyse et la rend plus pertinente. Par exemple, SmartThings et d’autres systèmes offrent une programmation par impulsion, qui permet à l’utilisateur de connecter les capteurs et programmer des évènements dans le but d’automatiser leur maison. C’est le genre de capacité qui permet l’allumage des lumières de l’entrée quand un détecteur perçoit l’arrivée d’une voiture. Elle offre aussi l’assurance que la porte du garage est bien fermée quand, le soir, l’on éteint la lumière de sa chambre à coucher.

Nous avons effectué des tests afin de détecter des failles potentielles de sécurité du système et de 499 applications SmartThings (appelées SmartApps) disponible dans leur boutique, pour chercher à évaluer la fréquence de ces failles de sécurité.

Trouver les principaux points faibles et s’y attaquer

Nous avons découvert deux sources principales de vulnérabilité : des prérogatives excessives et des messageries peu sûres.

Des applications trop privilégiées : Les SmartApps ont des prérogatives qui leur permettent d’effectuer des opérations spécifiques sur un dispositif, comme allumer et éteindre un four, ou ouvrir et fermer une porte. Le principe est le même que pour les applications de smartphones, qui demandent différentes permissions comme utiliser l’appareil photo ou géolocaliser le téléphone. Ces prérogatives ont été regroupées. Plutôt que d’avoir recours à des autorisations séparées pour ouvrir, puis fermer une porte, une seule et même application aurait le droit d’effectuer les deux opérations même s’il n’y a pas besoin de le faire.

Par exemple, imaginez une application qui puisse automatiquement verrouiller une porte particulière après 21 heures. Le système SmartThings permettrait aussi à cette application de pouvoir la déverrouiller. Un développeur d’applis ne peut pas programmer pour la seule fermeture de porte. Plus de la moitié – 55 % – des 499 SmartApps que nous avons étudiées avaient accès à plus de fonctions que ce dont elles avaient besoin.

Des systèmes de messagerie peu sûrs : Les SmartApps peuvent communiquer avec des dispositifs physiques via l’échange de messages, ressemblant à ceux qu’utilisent spontanément des personnes entre elles. Les dispositifs SmartThings envoient des messages qui peuvent contenir des informations sensibles comme un code PIN pour ouvrir une serrure particulière.

Nous avons découvert qu’aussi longtemps qu’une SmartApp possède ne serait-ce que le niveau le plus élémentaire permettant d’accéder à un dispositif (comme l’autorisation pour indiquer le niveau de la batterie), alors elle peut recevoir tous les messages générés par les dispositifs physiques, et pas seulement ceux qui concernent les fonctions autorisées. Ainsi, l’application destinée seulement à identifier le niveau de la batterie pour une serrure de porte peut aussi lire les messages qui contiennent le code PIN de son déverrouillage.

De plus, nous avons trouvé que les SmartApps sont capables d’« imiter » l’appareillage d’une maison intelligente, envoyant leurs propres messages qui ressemblent à ceux des dispositifs physiques de la maison. Une SmartApp malveillante peut lire la fiche d’identité du réseau commandant la mise en œuvre d’un dispositif et créer un message avec cette identité volée. L’appli qui permet de surveiller le niveau de la batterie peut même envoyer un message en cachette en se faisant passer pour la serrure de la porte, et indiquant faussement, par exemple, qu’elle a été ouverte.

SmartThings ne garantit pas que seuls les dispositifs physiques peuvent créer des messages avec une identité dédiée.

La preuve du concept concernant les attaques pour le réseau SmartThings.

S’attaquer aux défauts de conception

Pour passer des faiblesses potentielles aux véritables failles de sécurité, nous avons construit quatre attaques sous forme de preuves du concept pour démontrer comment les assaillants s’y prennent pour combiner et exploiter les défauts de conception que nous avons trouvés dans SmartThings.

Dans notre première attaque, nous avons construit une application censée contrôler les niveaux de batterie dans divers dispositifs sans fil de la maison, comme les détecteurs de mouvements, les détecteurs de fuite et les serrures de porte. Cependant, une fois installée par un utilisateur parfaitement innocent, cette application apparemment anodine se retrouvera programmée pour épier les autres messages envoyés par ces dispositifs, ouvrant la voie à une vulnérabilité majeure.

Quand l’usager autorisé crée un nouveau code PIN pour une serrure de porte, la serrure va reconnaître elle-même le code modifié en expédiant un message de configuration au réseau. Ce message contient le nouveau code, susceptible alors d’être décrypté par l’application malveillante, pourtant chargée uniquement de contrôler les niveaux des batteries. Elle pourra alors envoyer par SMS le code à son concepteur, donnant ainsi directement la clef d’une maison à un intrus éventuel.

Lors de notre deuxième attaque, nous avons pu espionner les communications prétendument sûres entre une SmartApp et son application Androïd compagnon. Ceci nous a permis d’usurper l’identité de l’application Androïd et d’envoyer des ordres à la SmartApp – par exemple qu’elle crée un nouveau code PIN nous offrant la possibilité d’entrer dans la maison.

Nos troisième et quatrième attaques ont consisté à écrire du code pour des SmartApps malveillantes permettant de profiter d’autres failles dans la sécurité. Une SmartApp bricolée a pu désactiver le « mode vacances », une fonction très utilisée pour faire croire à l’utilisation des lieux ; nous avons stoppé le système d’une maison intelligente d’ouverture et de fermeture des lumières et en se comportant comme si la maison était occupée. Une autre SmartApp créée a pu provoquer une fausse alerte incendie en prétendant être un détecteur de monoxyde de carbone.

Il y a de la place pour des améliorations

En prenant du recul, qu’est ce que cela signifie pour les maisons intelligentes en général ? Ces résultats sont-ils le reflet de l’industrie dans son ensemble ? Les maisons intelligentes ne seront-elles jamais sûres ? Il y a de grands profits à tirer des maisons intelligentes et en général de l’Internet des objets. Ils entraînent finalement une meilleure qualité de vie. Toutefois, compte tenu des faiblesses des systèmes actuels, il faut se montrer prudent.

Il s’agit là de technologies à l’état naissant et les utilisateurs doivent se demander s’ils se sentent à l’aise en offrant à des tiers – des applis ou des plates-formes de maisons intelligentes – un accès à distance à leurs dispositifs.

Par exemple, je ne verrais pas, pour ma part, d’objection à donner à des technologies de maisons intelligentes un accès à distance pour mes volets ou mes lampes de bureau. Mais je serais plus réticent à mettre ma sécurité en jeu avec un contrôle à distance de serrures de porte, d’alarmes incendie et de fours de cuisine car il s’agit de dispositifs de sécurité cruciaux. S’ils sont mal utilisés, ces systèmes peuvent donner lieu et même provoquer des dommages physiques. Cependant, je pourrais changer d’avis si les systèmes étaient mieux conçus pour réduire les risques de panne ou de compromission et pour mieux protéger la sécurité des utilisateurs.

Remerciements : ce travail de recherche a été mené en collaboration avec Jaeyeon Jung et Atul Prakash.

This article was originally published in English