Intrinsec était présent au SIDO (Salon de l’Internet des Objets), qui s’est déroulé à la Cité Internationale de Lyon les 6 et 7 avril (www.sido-event.com). Il s’agissait de la première édition d’un tel évènement qui comprenait différentes activités :

• Trois sessions de conférences en parallèle ;
• Des stands de différents acteurs du marché ;
• Des démonstrations de grands acteurs (EDF, Orange, Microsoft, etc.).

Intrinsec était représenté sur ce salon par Guillaume Lopes et Damien Picard.

Au regard du nombre de conférences et de présentations réalisées lors de ce salon, nous vous proposons d’en dresser un bilan en s’axant bien évidemment sur la sécurité de l’information.

Avant de débuter, petit rappel sur l’Internet des Objets.

Qu’est-ce que l’Internet des Objets ?

D’après le top 10 de l’OWASP Internet of Things : « Il s’agit d’un ensemble d’objets connectés possédant une connectivité à Internet et pouvant envoyer et recevoir des données ».

Concrètement, il s’agit d’objets pouvant recueillir, communiquer voire même traiter des informations environnantes (température, fréquence radio, électricité, etc.). Ces objets peuvent en général communiquer par différents biais :

• Wi-Fi ;
• Bluetooth ;
• Réseaux cellulaires (2G/3G/4G) ;
• Réseaux spécifiques aux objets connectés : Sigfox et LoRa.

Prenons l’exemple d’un réfrigérateur, capable de déterminer son contenu et de vous faire parvenir une alerte quand vous manquez d’œufs.

On voit donc déjà apparaître différents points où la sécurité entre en jeu :

• Dans l’objet en lui-même. Peut-on en prendre le contrôle ? À distance ?
• Dans le flux de données échangées entre l’objet et la plateforme de traitement associée. Peut-on l’intercepter, le lire, le modifier ?
• La plateforme qui traite les données. Quelles informations sont accessibles sur ce service ?

Par plateforme de traitement, nous entendons tout service web ou toute application avec lequel l’objet communique afin de réaliser un traitement sur les données (analyses statistique, stockage, etc.). En général, il s’agit d’une plateforme cloud.

Problématiques liées à l’Internet des Objets

En théorie, c’est merveilleux, tous les objets communiquent et nous informent sur notre environnement. Dans la pratique, il y a plus d’une dizaine d’OS différents, plus ou moins à jour, pour concevoir son objet, à multiplier par la pléthore de protocoles de communications existants et les différentes plateformes avec lesquelles les objets souhaitent communiquer, sans même se poser la question de l’architecture matérielle utilisée. Ce qui pose un premier problème : comment sécuriser sans avoir de standard ? On peut bien sûr saluer les efforts de l’IETF, l’ETSI (European Telecommunications Standards Institute) et quelques acteurs du marché pour la standardisation de cet environnement, mais ce ne sont pour l’instant que des « drafts » et ils ne sont pas encore largement répandus. Rappelons que la sécurité par l’obscurantisme n’est pas robuste.

Pour être attractifs, de nombreux objets misent sur une grande autonomie, et les fabricants doivent réduire les coûts en énergie des communications et des calculs. Pour ceux qui pensent que le chiffrement est trop coûteux en énergie, sachez qu’il existe des algorithmes adaptés à votre besoin, notamment AES-128 qui a par exemple été implémenté sur des cartes RFID. AES étant un algorithme de chiffrement symétrique il faut avoir au préalable échangé des clefs. On peut, pour ce faire, recourir à un matériel spécialisé et échanger des clefs comme prévu par le protocole DTLS (Datagram Transport Layer Security). Cette approche, bien que légèrement plus coûteuse et générant plus d’échanges de paquets, repose sur un protocole éprouvé. Un papier traitant plus en détail de la surconsommation engendrée a été publié.

Notons que l’emploi de mécanismes cryptographiques par des tiers de services (opérateurs LoRa/Sigfox, fournisseurs de services web, etc.) ne sécurise les données qu’entre le tiers et l’objet connecté. Ils ont donc accès aux données en clair. A fortiori un attaquant ayant réussi à compromettre leurs infrastructures y aura donc tout autant accès. Une sécurité de bout-en-bout, c’est à dire entre l’objet et l’utilisateur final, peut donc être nécessaire pour minimiser les impacts d’une telle compromission, voire indispensable en cas de données critiques. Il faut aussi souligner que l’évocation de mécanismes cryptographiques et l’utilisation de multiples clefs dans certaines documentations mériterait plus de détails afin d’asseoir la sécurité du produit. Comment sont gérées les clefs ? Peut-on les renouveler ? Comment sont-elles utilisées, où interviennent-elles ?

Une autre problématique évoquée de nombreuses fois est de savoir comment gérer la découverte d’une vulnérabilité sur un objet. Gartner prévoit entre 25 et 50 milliards d’objets connectés d’ici 2020, l’IDATE (Institut de l’audiovisuel et des télécommunications en Europe) en prévoit même 80 milliards. La plupart avec des capacités de calcul et de communication faibles. Imaginons un instant l’effet de la découverte d’une faille affectant ne serait-ce que 1% des objets connectés. Comment mettre à jour 250 millions d’objets ayant de faibles capacités de communication ? Comment revenir à un fonctionnement normal en cas d’exploitation de la faille ? Quelle puissance obtient-on avec un botnet de 250 millions d’objets connectés ? Peut-on interrompre la connexion et que l’objet reste utilisable, ou peut-on rouler avec une voiture connectée comme une voiture normale ?

Venons-en maintenant à ce que nous appelons la plateforme de traitement. Il arrive fréquemment que cette dernière soit assimilée au cloud. Mettons les choses au clair, le cloud c’est un business model. Certains clouds offrent de la sécurité et des services de centre opérationnel de sécurité (SOC). Mais en aucun cas on ne peut prétendre « les données sont envoyées dans un cloud, elles sont donc sécurisées ». Il faut même faire extrêmement attention à la sécurité de cette plateforme, fusse-t-elle un cloud ou une application, cette dernière ayant potentiellement accès à tous les objets qui lui sont connectés.

Enfin, on peut se poser la question de l’uniformisation des analyses de risque quand le constructeur d’un objet estime que la prise de contrôle de son objet n’est pas critique, car peu probable et n’ayant finalement que peu d’impact direct sur les données de son objet, mais qu’un éditeur tiers ou un utilisateur l’estime comme critique, car cela permettrait la compromission de son SI ? Qui doit sécuriser quoi ? En cas de compromission, qui est tenu pour responsable ?

État de la sécurité

Il faut également être conscient que si nous nous posons toutes ces questions, nous ne sommes sûrement pas les seuls et que plusieurs personnes plus ou moins bien intentionnées se sont déjà posé ces questions. D’ailleurs, on a déjà pu voir dans la presse qu’il était possible d’ouvrir à distance les portières d’une voiture connectée ou des portes équipées de verrous connectés. Ce ne sont ici que des « travaux » qui ont été signalés aux éditeurs ou organisés par eux-mêmes et sur lesquels ils ont accepté de communiquer.

Conclusion

L’Internet des Objets en l’état actuel, et si rien n’est fait pour en améliorer la sécurité, risque d’augmenter grandement la surface d’attaque d’un SI. La question qui peut être posée est : comment évaluer la sécurité d’un système avec 25 milliards de cibles potentielles où ne serait-ce que 1% d’objets vulnérables peut mener à la catastrophe ? L’approche du test d’intrusion en « best effort », même si elle ne garantira jamais l’absence de vulnérabilité, permettrait peut-être d’en éliminer un certain nombre avant la mise sur le marché.