Sécurisation de l'IoT de la couche réseau à la couche application

Wouter van der Beek

La sécurité dans l'Internet des objets (IoT) est devenue une exigence critique, avec une législation récente rendant obligatoire des « caractéristiques de sécurité raisonnables ». .

La sécurité est construite en couches ; la première couche à sécuriser est la couche matérielle, la seconde est la couche réseau. Dans cet article, la couche réseau référencée est la couche réseau Thread :un réseau IoT maillé à faible coût et à faible consommation d'énergie.

Cependant, le réseau est un mélange de technologies IP sans fil et câblées, il y a donc également un besoin de sécurité au niveau des applications. Cela vient de la couche d'application OCF ; un domaine sécurisé où tous les appareils et clients peuvent communiquer en toute sécurité, par exemple, Wouter van der Beek, architecte senior IoT, Cisco Systems et président du groupe de travail technique, Open Connectivity Foundation et Bruno Johnson, PDG de Cascoda , membre de l'Open Connectivity Foundation.

Sécurité matérielle

Le microcontrôleur contraint nécessite des fonctionnalités pour le protéger des codes malveillants et de l'espionnage matériel qui compromettrait la sécurité. Le matériel sécurisé protège la séquence de démarrage du microcontrôleur en validant sa signature et protège la mémoire et l'accès aux périphériques pour isoler les parties critiques du code. Cela permet uniquement l'accès via une interface de programmation d'applications (API) bien définie et fiable. Ces fonctionnalités minimisent la surface d'attaque des appareils connectés, fournissant une base sécurisée pour le réseau et l'application.

Sécurité du réseau

La couche réseau doit s'assurer que les données envoyées par voie hertzienne ne peuvent pas être modifiées et que les appareils qui rejoignent le réseau sont légitimes. Afin de sécuriser les données par liaison radio, Thread utilise une clé à l'échelle du réseau qui utilise la cryptographie à clé symétrique connue sous le nom d'AES-CCM. AES-CCM ajoute un code de balise à chaque message et le crypte à l'aide de cette clé à l'échelle du réseau. Si le destinataire possède la clé, il peut déchiffrer, vérifier l'origine et vérifier que le message n'a pas été corrompu en transit. Enfin, la clé est périodiquement modifiée en fonction de la clé existante et d'un compteur de séquence spécifique au cas où elle serait compromise.

Cependant, lorsqu'un nouvel appareil doit rejoindre un réseau, il ne connaît pas la clé à l'échelle du réseau et doit donc l'obtenir. Ce processus est connu sous le nom de mise en service. Bien entendu, la clé ne peut pas être transmise sans cryptage, car elle pourrait être interceptée par un attaquant. Pour surmonter ce problème, la mise en service des threads utilise un processus connu sous le nom d'échange de clés authentifié par mot de passe (PAKE), qui fait partie de la norme Datagram Transport Layer Security (DTLS).

PAKE utilise un secret à faible résistance en conjonction avec la cryptographie asymétrique pour générer un secret à haute résistance entre les deux parties. Le secret à haute résistance est utilisé pour crypter la communication de la clé du commissaire Thread (par exemple, un smartphone connecté au réseau Thread) vers l'appareil de connexion.

Sécurité des applications

Pour garantir la sécurité de bout en bout au niveau de la couche applicative, OCF fournit des solutions pour transférer la propriété du fabricant à l'acheteur, ou d'un acheteur à l'autre. La première étape de l'intégration consiste à établir la propriété de l'appareil. À cette fin, OCF délivre des certificats et gère une base de données pour chaque appareil certifié. À ce stade, l'appareil est fourni avec ces informations d'identification pour établir des connexions sécurisées mutuellement authentifiées avec d'autres appareils dans le domaine sécurisé IoT, grâce à l'infrastructure à clé publique OCF (PKI).

Les instructions d'approvisionnement sont ensuite données via une connexion sécurisée, chiffrée par DTLS. Le processus commence par le transfert de propriété de l'appareil, puis le provisionnement de l'appareil, après un ensemble de transitions d'état. Il convient de noter qu'OCF tient compte du fait qu'au cours de son cycle de vie, un appareil peut changer de propriétaire. Par conséquent, OCF exige que les appareils implémentent une réinitialisation matérielle pour revenir à leur état d'initialisation.

En plus de ce processus d'intégration, les appareils OCF peuvent être configurés avec différents niveaux de sécurité. OCF propose une approche en couches :contrôle d'accès basé sur les rôles et descriptions d'utilisation du fabricant. Le premier traite de la sécurité des appareils, tandis que le second ajoute une couche supplémentaire de protection contre le réseau.

Implémentation à l'aide de matériel contraint

La mise en œuvre d'OCF-over-Thread sur du matériel contraint est un défi en raison de l'espace de code, de la mémoire et de la puissance de calcul très limités des microcontrôleurs à faible coût. De ce fait, il est nécessaire de profiter de la réutilisation du code. Les économies de code les plus importantes proviennent du partage de la bibliothèque de cryptographie principale et de mbedTLS, communs aux deux piles. Ceci est possible car OCF et Thread sont tous deux construits sur DTLS.

L'exécution des primitives de cryptographie de base pour DTLS nécessite l'accès à du matériel dédié pour l'accélération, ce qui est beaucoup plus efficace en temps et en énergie qu'un logiciel pur. Une telle accélération matérielle réduit le temps de mise en service du Thread de plusieurs ordres de grandeur - une augmentation significative de la vitesse de la tâche la plus intensive en calcul pour laquelle le microcontrôleur est responsable. Par conséquent, la gestion de l'accès à la fonctionnalité de cryptographie matérielle pour les deux piles via la bibliothèque mbedTLS est d'une importance cruciale.

OCF et Thread Group exécutent tous deux des projets open source pour leurs spécifications respectives. Ces implémentations concrètes éliminent l'ambiguïté pour les développeurs et forgent l'interopérabilité.

Les technologies qui peuvent fonctionner ensemble de l'application à la couche réseau forment une plate-forme IoT sécurisée de premier ordre qui peut être déployée aujourd'hui.

Les auteurs sont Wouter van der Beek, architecte IoT senior, président du groupe de travail technique et systèmes Cisco, Open Connectivity Foundation et Bruno Johnson, PDG de Cascoda, membre de l'Open Connectivity Foundation.