La sécurité et les IoT, encore trop souvent se sont deux notions opposées. Une session animée par la société Sogeti l’a démontré, ce qui ne manqua de surprendre l’auditoire. 

L’exemple donné fut celui d’une serrure connectée. Nous avons donc le matériel, la serrure, une gateway, un back-end cloud et une application mobile, qui est là pour ouvrir / fermer la serrure. Notre serrure communique avec la gateway matérielle via Zigbee. La première erreur, que l’on voit assez souvent, quand on provisionne un nouvel objet dans la gateway, la clé d’authentification est par défaut la même partout. Même si le protocole de communication offre une sécurité relativement bonne, la clé par défaut ouvre une porte potentielle. L’autre solution est de sniffer la gateway pour trouver la configuration. La gateway est un module sans fil sur lequel les objets se connectent. Elle est connecté aux services centraux, typiquement un service cloud, possédant un serveur MQTT. La gateway possède un processeur (ou un SoC), un stockage Flash, un écran, la partie wifi, etc. C’est clairement un point faible si le hacker peut y accéder et l’ouvrir (sauf si le boitier possède un capteur d’ouverture).

Plusieurs attaques sont possibles. Il peut dessouder la mémoire et tenter de la lire et y injecter par exemple un nouveau code. Les données stockées ne sont pas toujours cryptées. Autre solution, on tente de hacker le processeur. Dans ce cas, il faut tout d’abord lire les références du composant pour trouver le schéma des broches. Plusieurs interfaces matérielles sont intéressantes telles que les JTAG et les SWD. Ce sont des ports de debug très utilisés quand on conçoit un IoT. Si on oublie de bloquer ces ports, on a là une faille potentielle que le hacker peut utiliser. 

Par contre, hacker le matériel nécessite un peu de matériel et bonne connaissance hardware. 

Quand on rajoute une nouvelle clé : il faut la déclarer dans la gateway qui communique les informations au service cloud / serveur MQTT. L’application mobile voit alors une nouvelle clé que l’utilisateur peut manipuler. En théorie, la chaine est sûre. Cependant, comme la gateway fournit un mot de passe par défaut qui est toujours le même, le hacker peut alors assez simplement s’infiltrer : il récupère les identifiants et surtout il peut accéder au MQTT / backend sans passer par l’application mobile surtout si hacker voit les URL de connexion entre la gateway et le back-end. Et cela signifie qu’il pourrait alors accéder au répertoire MQTT et manipuler les IoT.

Comme l’a bien rappelé l’intervenant : un seul composant vulnérable et c’est l’ensemble de la chaine qui peut se faire infiltrer. Même si chaque élément de la chaine propose un bon niveau de sécurité. La complexité de sécurité s’explique par une combinaison de matériels et de logiciels, et que la sécurité doit donc intervenir sur les deux. Or, ce ne sont pas forcément les mêmes équipes et compétences qui gèrent la sécurité.

Parmi les recommandations proposées : fermer les interfaces au niveau du processeur / SoC, le fabricant de la passerelle ne doit pas avoir un unique identifiant par défaut à chaque ajout d’un objet, bien compartimenter le MQTT. Il faut éviter de laisser en clair des données sur l’objet en lui-même et la passerelle. 

François Tonic