Sécuriser l'IoT du matériel à l'application : un blueprint couche par couche

Par Wouter van der Beek

Dans le monde connecté d'aujourd'hui, la sécurité IoT n'est plus optionnelle — c'est une exigence réglementaire. La législation récente exige que les appareils intègrent des « fonctionnalités de sécurité raisonnables », soulignant que le coût de sécurisation d'un appareil l'emporte largement sur le risque de le laisser exposé.

La sécurité s'architecte en couches. La fondation commence par le matériel, suivie par le réseau, et enfin l'application. Cet article se concentre sur la couche réseau Thread — un réseau IP mesh à faible coût et faible énergie — et la couche application OCF qui gouverne les interactions entre appareils.

Sécurité matérielle

Les microcontrôleurs contraints doivent se prémunir contre le firmware malveillant et l'espionnage matériel. Le matériel sécurisé impose une séquence de démarrage vérifiée, signe le firmware, et isole l'accès mémoire et périphériques. Seule une API de confiance, bien définie, peut atteindre le code critique, minimisant ainsi la surface d'attaque et créant une base robuste pour la sécurité des couches supérieures.

Sécurité réseau

Thread protège les données en transit avec une clé AES-CCM à l'échelle du réseau. Chaque paquet reçoit un tag d'authentification et est chiffré, assurant intégrité, confidentialité et authenticité. La clé est périodiquement rafraîchie via une dérivation basée sur compteur pour prévenir la compromission.

Quand un nouvel appareil rejoint, il doit acquérir la clé réseau de façon sécurisée — un processus appelé commissioning. Thread utilise l'échange de clé authentifié par mot de passe (PAKE), partie de DTLS, pour transformer un secret partagé de faible force en une clé forte. Cela permet au commissioner Thread (ex: un smartphone) de transmettre la clé réseau à l'appareil qui rejoint via un canal chiffré.

Sécurité application

Au niveau application, l'Open Connectivity Foundation (OCF) offre un flux complet de transfert de propriété et provisioning d'appareil. OCF émet des certificats d'appareil et maintient une base de données sécurisée, permettant l'authentification mutuelle via une infrastructure PKI.

Les instructions de provisioning sont délivrées sur des canaux chiffrés DTLS. Le flux commence par le transfert de propriété, passe par des transitions d'état, et accommode les changements de propriété en exigeant un reset matériel pour retourner à l'état initial.

OCF fournit aussi un contrôle d'accès basé sur les rôles et des descripteurs d'usage fabricant, ajoutant des safeguards supplémentaires contre les menaces au niveau réseau.

Implémenter OCF-over-Thread sur matériel contraint

Déployer OCF sur Thread sur microcontrôleurs bas coût est challengeant dû à l'espace code limité, mémoire et ressources CPU. La solution réside dans la réutilisation de code — partager un seul cœur cryptographique (mbedTLS) entre les deux stacks, car OCF et Thread s'appuient tous deux sur DTLS.

Les primitives cryptographiques bénéficient de l'accélération matérielle, réduisant dramatiquement le temps de commissioning et la consommation d'énergie. Gérer l'accès à ce matériel via mbedTLS est critique pour la performance et la sécurité.

Les groupes OCF et Thread publient tous deux des implémentations open-source, éliminant l'ambiguïté et assurant l'interopérabilité pour les développeurs.

Quand les couches application, réseau et matériel sont étroitement intégrées, le résultat est une plateforme IoT sécurisée best-in-class prête pour le déploiement aujourd'hui.

Auteurs : Wouter van der Beek, architecte IoT senior, Cisco Systems et président du Technical Working Group, Open Connectivity Foundation ; Bruno Johnson, CEO, Cascoda, membre de l'Open Connectivity Foundation.