Bonjour chers amoureux de l'Internet des objets. Notes de continuation Fournisseur IoT.
La première partie > || >
Deuxième partie > || >
Troisième partie > || >
La quatrième partieAujourd'hui, il est temps de parler de sécurité chez LoRaWAN. Il existe de nombreuses rumeurs et légendes. Nous allons essayer de comprendre comment cela fonctionne et quels sont les risques.
Pour passer au sujet de la sécurité, vous devrez faire une petite introduction et parler de l'initialisation initiale du module radio sur le réseau. Ce processus dans LoRaWAN est appelé activation.
Par souci de concision, je vais énumérer ci-dessous les termes dont nous avons besoin. Si vous êtes un peu confus, vous pouvez revenir ici et vérifier. Vous devez probablement revenir, car les abréviations de nombreux termes sont très similaires. De plus, dans cette description, je donnerai des analogies afin que vous compreniez à peu près à quoi tel ou tel terme peut être comparé. Il n'est pas toujours possible de sélectionner des analogies exactes, veuillez donc ne pas juger cette colonne trop strictement.
Ainsi, l'activation dans LoRaWAN peut se faire par voie aérienne (OTAA), ou par préréglage (ABP).
OTAA (activation en direct)
En cas d'activation par air, trois paramètres doivent être réglés sur notre module radio. Son identifiant unique (DevEUI), son identifiant de serveur (AppEUI) et sa clé de serveur (AppKey).
Côté serveur, l'identifiant du module radio, l'identifiant du serveur et la clé doivent également être enregistrés. C'est-à-dire le serveur doit d'abord connaître le périphérique qui tentera de le rejoindre. Si nous connaissons les identifiants et les clés du serveur, mais que notre DevEUI n'est pas enregistré dans sa base de données, la connexion échouera.
Lors de la mise sous tension initiale, la radio envoie le paquet join_request en ondes à l'une des trois fréquences de jonction prédéfinies. Avec ce forfait, il demande s'il existe un réseau à proximité qui le «reconnaîtra». Voici la composition du package join_request. Comme vous pouvez le voir, il contient les très DevEUI et AppEUI, ainsi que DevNonce.
DevNonce est une variable aléatoire. Le serveur le stocke en mémoire pendant un certain temps et si join_request arrive avec le même DevNonce que l'un des précédents, le serveur ignorera cette demande. Il s'agit de se protéger contre une attaque répétée lorsqu'un attaquant peut écrire une demande d'activation puis la répéter depuis son appareil. Soit dit en passant, toutes les normes IoT ne peuvent pas se vanter d'une protection contre cette attaque.
AppKey n'est pas directement utilisé dans ce message, mais à travers lui, la somme de contrôle MIC à la fin de la trame est considérée.
Nous aurons besoin de cette clé un peu plus loin, dans le message de réponse du serveur join_accept.
Join_request est transmise non chiffrée.
Join_accept sera reçu si le serveur connaît AppEUI et DevEUI, ainsi qu'il n'y a pas de correspondance dans le champ DevNonce et qu'il n'y a aucun problème avec le MIC. Sinon, il n'y aura pas de réponse. Si toutes les vérifications sont réussies, le serveur génère un message de réponse join_accept. Sa composition est montrée dans l'image ci-dessous.
En fait, deux clés de session sont générées - le serveur réseau (NwkSKey) et le serveur d'applications (AppSKey). Ces clés ainsi que d'autres informations sont cryptées par AppKey et envoyées au module radio. De plus, tous les messages se produisent avec un double chiffrement avec des clés de session (à l'exception des paquets avec des commandes MAC, ils ne sont pas chiffrés avec la clé du serveur d'applications). NwkSKey ne participe pas au chiffrement de paquets uniquement avec des données (sans commandes), mais une somme de contrôle est considérée à travers elle.
NwkSkey et AppSKey sont uniques à chaque module radio individuel.
Deux clés sont utilisées pour une protection supplémentaire des informations. Chaque fois qu'un paquet du module radio arrive dans notre système, il sera partiellement chiffré pour le serveur réseau et partiellement pour le serveur d'applications. C'est-à-dire le serveur réseau ne pourra décrypter que les messages qui lui sont adressés (divers messages de service). Le serveur d'applications ne verra que le composant utile des paquets (en fait, les données transmises). Cela est nécessaire car le serveur réseau avec une probabilité de 99% sera chez le fournisseur. Mais le serveur d'applications peut très bien être hébergé par le client. Le double chiffrement rend difficile pour le fournisseur de découvrir le contenu du paquet.
En plus des deux clés, il y a une autre chose importante à join_accept sur OTAA - la liste de fréquences étendue (CFList). Permettez-moi de vous rappeler qu'au départ, un module radio ne connaît que trois fréquences auxquelles il peut fonctionner. Après l'activation, des fréquences supplémentaires sont enregistrées pour qu'il puisse communiquer.
C'est très pratique si on ne sait pas exactement dans quel réseau l'appareil fonctionnera. Nous pouvons convenir que dans tous les réseaux, 3 fréquences (+ RX2) coïncideront toujours, et les cinq autres sont à la discrétion du fournisseur.
De plus, pour l'avenir, pour travailler avec un grand nombre d'appareils CFList peut être utilisé pour le clustering
C'est lorsque vous divisez le réseau en grappes et qu'au sein des grappes, il y a une planification des fréquences. Disons que notre module radio connaît les trois fréquences F1, F2 et F3. Il s'active à l'une des fréquences et s'il se trouve dans le cluster1, il reçoit alors une table de fréquences supplémentaire sous la forme de F4-1, F5-1 et F6-1. Pour le cluster 2, il obtiendra des F4-2, F5-2, F6-2 complètement différents. En même temps, nous pouvons configurer tous les modules radio de la même manière et ne pas vraiment penser lequel tombera dans quel cluster. Et dans les grappes voisines, la probabilité de collisions diminuera fortement.
ABP (Activation par personnalisation)
Une procédure simplifiée lorsque les clés de session sont immédiatement câblées dans le module radio et sont initialement enregistrées côté serveur. Pratique dans la mesure où vous n'avez pas besoin d'activer, le module radio est immédiatement prêt à l'emploi. Rien de plus pratique, car la sécurité dans ce cas est moyenne. De plus, vous ne pouvez pas extraire les fréquences du serveur. Je n'ai jamais vu de cas d'utilisation réelle. Nous n'en tiendrons pas compte et tout ce qui suit concerne l'OTAA.
Et la sécurité?
Donc, en substance, nous avons la charge de chiffrement principale sur les clés de session du serveur réseau et du serveur d'applications.
Considérez-les un peu plus attentivement.
La principale plainte des critiques de la norme LoRaWAN est que lorsque l'appareil est activé sur le réseau, nous avons deux clés, qui peuvent ensuite rester inchangées pendant des mois. Plus précisément, ils peuvent ne pas changer pendant des années jusqu'à ce que l'appareil soit réactivé. Dans des conditions normales, nous avons activé et oublié le module radio, donc une durée de vie clé de trois à quatre ans est une perspective très réaliste. En fait, de l'installation à laisser la batterie à zéro.
Quelle est la fiabilité de nos clés?
La spécification indique qu'ils sont conformes à la mystérieuse RFC4493.
Qu'est ce que c'est Il s'agit d'un algorithme de chiffrement, mieux connu sous le nom d'AES-CMAC.
Ne rampons pas dans les décors de la cryptographie et limitons-nous à une compréhension commune de l'image. Il est présenté dans la figure ci-dessous.
Le principe d'AES-CMAC est approximativement le suivant: le message chiffré est divisé en blocs de 128 bits. Chaque bloc est chiffré séparément avec une clé AES. De plus, lors du chiffrement du deuxième bloc, en plus de la clé, le résultat de chiffrement du premier est utilisé. Et lors du cryptage du troisième - le résultat du second et (indirectement) du premier. Une telle chaîne de complications.
Quelle est la fiabilité de ce principe?
Très fiable. L'algorithme est sorti il y a plus de dix ans. Depuis lors, il a été attaqué par de nombreuses attaques différentes, et finalement, en théorie, elles ont prouvé qu'il peut être piraté. Le problème est qu'un grand échantillon de paquets, plusieurs milliers, sera nécessaire pour le casser. Ensuite, il est possible de comprendre ce qui se trouve à l'intérieur des blocs cryptés.
Un attaquant disposant des connaissances nécessaires peut-il obtenir cet exemple si nous parlons d'intercepter des paquets LoRaWAN? Estimons. Laissez les colis partir une fois par heure. Dans un mois, 720 paquets iront du module radio. Pas assez.
Pour une menace réelle, nous avons besoin d'un patient très patient qui rédigera des colis pendant des mois. Et ce n'est pas un fait qu'il peut encore casser l'algorithme et obtenir les clés précieuses. N'oubliez pas qu'une telle patience devra être démontrée pour chaque module radio séparément. Et rappelez-vous que l'envoi de paquets une fois par heure est TRÈS souvent. Dans la pratique, les intervalles sont beaucoup plus longs - six heures, voire une journée.
Mais même cette opportunité fantomatique est désormais fermée après la publication de la spécification 1.1, où les commandes de réactivation et de connexion au serveur sont implémentées. Parlons en quelque sorte de cette spécification. Pour l'instant, je me souviens de ma pensée de l'article précédent: lorsque le standard est ouvert et qu'il a une communauté, tous ses trous sont visibles. Pendant la mise à niveau, les développeurs savent exactement quoi regarder en premier.
En conséquence, nous comprenons que la menace pour la sécurité est plutôt illusoire. Quelque part dans la théorie profonde, le piratage peut être fait, mais dans la pratique, il n'est pratiquement pas réaliste. Maintenant, multipliez par la valeur des informations reçues. Notre attaquant va-t-il commencer à écrire des paquets pendant des mois pour trouver le compteur? Peu probable.
LoRaWAN répond à ce rapport qualité-prix raisonnable. Nous comprenons que la protection peut être améliorée. Mais c'est la puissance de calcul de la fin, c'est une charge supplémentaire sur la batterie, il est possible d'augmenter la taille des paquets ou de réduire la charge utile.
Pour moi, c’est plus qu’une tâche de télémétrie.
Dans les commentaires, je serai heureux d'entendre mes adversaires et partisans. N'oubliez pas que le sujet de la sécurité nécessite toujours une discussion et ne doit jamais reposer sur l'opinion d'une seule personne.