Salut, Habr.
Je voudrais à nouveau parler de la façon dont le niveau de base (lire: minimum nécessaire) de sécurité des données dans les réseaux sans fil utilisés dans les appareils IoT est fourni, en utilisant le LoRaWAN comme exemple.
Pourquoi LoRaWAN? Premièrement, parce que c'est une norme bien décrite et bien développée qui devrait être guidée comme référence si vous développez une sorte de votre propre protocole sans fil. Deuxièmement, parce que c'est une solution IoT très native et typique; Vous pouvez, bien sûr, désassembler la sécurité en Wi-Fi ou LTE, mais pour la plupart des développeurs, ce sera une analyse futile: il est peu probable que vous ayez besoin d'écrire votre propre implémentation Wi-Fi. Troisièmement, ce sont les appareils IoT de faible puissance dans lesquels les développeurs enregistrent chaque octet qui s'avèrent souvent être les plus fuyants - ici LoRaWAN donne une bonne idée de la façon d'économiser des octets, et de ne pas être attaqué. Quatrièmement, enfin, car au cours des derniers jours, plusieurs de nos clients ont demandé à leur en dire plus sur la protection des données dans LoRaWAN, et avec cet article, je tue deux oiseaux avec une pierre.
Messagerie LoRaWAN entre le serveur et l'appareilBien que le schéma de messagerie dans LoRaWAN dans l'image semble assez simple - cette simplicité est trompeuse: elle a beaucoup de travail à faire, et pas un seul pixel n'est superflu. Vous comprendrez maintenant pourquoi.
Nous analyserons en utilisant LoRaWAN 1.0.2 comme exemple et danserons contre les menaces possibles - car un bon développeur ne devrait pas toujours penser à la façon dont son système est protégé, mais à la façon dont il peut être brisé. Sinon, quelqu'un d'autre y réfléchira pour lui.
Alors, quelles sont les principales menaces du réseau sans fil - et comment vous en protéger?
Interception des données utilisateur
La menace la plus simple est une interception régulière des données: Étant donné que les ondes radio se propagent de manière incontrôlable, alors absolument tout le monde peut prendre un récepteur réglé sur la plage et le type de modulation souhaités, et écouter tout ce que vous transmettez.
Le moyen le plus simple de se protéger contre cela est le chiffrement des données.
Dans LoRaWAN, les données utilisateur sont chiffrées à l'aide de l'algorithme AES-128 avec une longueur de clé de 128 bits (16 octets), respectivement. AES est un algorithme fiable, cependant, sur des microcontrôleurs minimalement modernes qui n'ont même pas de bloc de chiffrement matériel, son utilisation n'entraîne pas de surcharge importante: sur un Cortex-M3 avec une fréquence de 48 MHz, un bloc de 16 octets est chiffré à environ 100 μs à partir de zéro.
Répétition des données
Dans certains cas, un attaquant n'a pas besoin de savoir exactement ce que vous transmettez. Par exemple, si votre capteur a une fenêtre fermée qui transmet une chose, et une fenêtre ouverte transmet autre chose, alors vous pouvez en enregistrer une sans entrer dans les détails de son contenu, étouffer le capteur, et pour que le système ne soupçonne pas que quelque chose n'allait pas en raison du manque de paquets du capteur - diffuser le message enregistré précédemment.
Dans LoRaWAN, un compteur est ajouté à chaque paquet . Si un paquet arrive sur le serveur de réseau avec un compteur égal ou inférieur au précédent, ce paquet est simplement rejeté. Avec deux octets par mètre et une vitesse de transmission de messages typique du système IoT, cela durera très longtemps - par exemple, même une station météorologique domestique qui transmet la température chaque minute ne la dépassera qu'après un mois et demi (LoRaWAN autorise un compteur de 4 octets).
Il y a cependant un problème évident - après un débordement, un paquet portant le numéro 0 proviendra de l'appareil, ce qui, évidemment, sera inférieur à tout autre numéro, mais le serveur réseau devrait le percevoir correctement et recommencer le comptage des paquets. De plus, l'appareil peut réinitialiser le compteur en redémarrant simplement.
Ceci est réalisé de deux manières:
- Avant d'envoyer un tel package, l'appareil doit subir la procédure d'enregistrement sur le réseau (dans le réseau LoRaWAN, cette procédure est appelée Join)
- le serveur permet l'arrivée du prochain paquet avec le numéro 0, tandis que le compte à rebours recommence
Les deux schémas sont utilisés dans LoRaWAN selon la façon dont l'appareil est activé - OTAA ou ABP (nous en parlerons ci-dessous). La première option est utilisée pour OTAA, et l'appareil reçoit également de nouvelles clés de cryptage - donc même un attaquant qui a passé un mois et demi sous votre station météo ne pourra pas transmettre de paquets enregistrés précédemment afin que le système l'accepte.
Pour ABP, dans lequel il n'y a pas de procédure d'enregistrement sur le réseau, la deuxième option est utilisée - cependant, si la période de dépassement de compteur dépasse considérablement la durée de vie estimée de l'appareil, et elle peut être désactivée. En cas de redémarrage accidentel après l'envoi de chaque paquet, un tel dispositif final stocke la valeur du compteur dans une mémoire non volatile.
Le deuxième schéma, bien sûr, est moins sûr, mais dans la pratique, il est autorisé - un attaquant ne doit enregistrer aucun paquet dedans, mais spécifiquement zéro. Si vous le souhaitez, vous pouvez rendre son contenu différent de tous les autres packages - par exemple, transmettre non pas des données, mais des informations sur le type et les paramètres de l'appareil; alors son interception et sa répétition ne donneront rien de raisonnable.
ContrefaçonCependant, la question se pose immédiatement - et si le compteur est truqué? Vous pouvez le mettre dans la partie cryptée du paquet, mais la quantité réelle de données utilisateur diminuera alors de deux octets. Vous pouvez chiffrer non seulement les données utilisateur, mais ensuite, premièrement, vous devez vous adapter à la taille de bloc de 16 octets, et deuxièmement, la charge sur le serveur réseau augmentera, ce qui devra d'abord la déchiffrer pour toutes les actions sur le package (dans le schéma, lorsque seules les données utilisateur sont cryptées, si le package est ignoré formellement, alors rien ne doit être décrypté).
Il est évident que cela n'a pas d'importance pour nous que l'attaquant connaisse ou non le numéro de paquet - dans le système de réenregistrement réseau (OTAA), cette connaissance ne l'aidera pas du tout, et dans ABP, il attendra très longtemps au bord de la mer pour la météo, c'est-à-dire la prochaine arrivée du paquet avec le numéro N-1.
Par conséquent, il suffit de ne pas le laisser changer ce nombre.
Pour ce faire, l'ensemble du package dans LoRaWAN est signé avec une signature cryptographique - AES-CMAC, cette signature dans la norme est appelée MIC, Message Integrity Code. Il vérifie que l'
ensemble du package , y compris tous les en-têtes et les données, a atteint le serveur inchangé.
Autrement dit, après avoir accepté le prochain paquet, nous pouvons rapidement regarder dans son compteur (adresse de l'expéditeur, etc.), et s'il est le nôtre et correct, alors déjà vérifier la signature (en dépensant des ressources supplémentaires dessus), et si la signature est également correcte - décrypter les données et transmettre plus loin.
Suivi des données immuablesMalheureusement pour nous, il ne suffit pas d'empêcher un attaquant de comprendre les données ou au moins de les répéter - dans certains cas, il lui suffira de comprendre qu'elles ne changent pas. Un exemple de manuel est celui des compteurs d'eau à domicile: si vous voulez simplement savoir si les propriétaires sont à la maison, peu importe le nombre exact de litres, il est important pour vous de savoir
si cette valeur augmente .
De toute évidence, le cryptage des données est une procédure réversible (elles peuvent être décryptées), ce qui signifie que les mêmes données cryptées avec la même clé ont toujours la même apparence. Lorsque vous recevez des paquets d'un compteur d'eau, dont les lectures ne changent pas, vous pouvez,
sans déchiffrer le paquet , comprendre qu'ils ne changent pas.
Pour faire face à cela est assez simple - soit les données ou la clé doivent changer. Pour modifier les données, vous pouvez leur ajouter du sel - quelques octets aléatoires qui sont simplement jetés après le déchiffrement. Malheureusement, 16 octets d'un paquet sont déjà clairsemés, donc dans le cas général, nous ne voulons pas en dépenser 2 à 4 octets pour des ordures réelles.
LoRaWAN utilise un schéma plus délicat . Rappelez-vous que nous avons un compteur de paquets? Ainsi, ce compteur particulier ainsi que des informations sur l'appareil et le paquet (adresse courte de l'appareil sur le réseau LoRaWAN, sens de transfert des données, compteur de 16 octets) sont cryptés à l'aide de l'algorithme AES, et le résultat XOR est avec le paquet de données utilisateur.
Par conséquent, les octets de charge utile ne sont pas gaspillés et chaque message est différent, que la charge ait changé ou non.
PS Il existe une autre option, un peu plus simple: utiliser le compteur de messages comme les N derniers octets de la clé. Dans ce cas, la clé sera nouvelle à chaque fois, mais parce que Puisque le serveur connaît la valeur du compteur de messages (il se trouve dans la partie non chiffrée du message), il pourra le restaurer. Moins - si votre package se compose de plusieurs blocs de 16 octets, et qu'ils ont les mêmes données, alors après le cryptage, ils resteront les mêmes.
L'attaquant a appris la clé de chiffrementC'est une situation très réelle - l'IoT se caractérise par l'utilisation d'un grand nombre d'appareils, sur lesquels vous ne pouvez généralement pas avoir un contrôle fiable sur l'accès aux étrangers (et si vous êtes également un opérateur de réseau, vos clients sont par définition des étrangers les uns pour les autres).
Par conséquent, si tous vos appareils ont la même clé de chiffrement, le propriétaire de l'un d'entre eux peut écouter le trafic de tout autre appareil (en règle générale, s'il a la possibilité de modifier le micrologiciel, alors pour une telle opération, vous ne connaissez peut-être même pas la clé explicitement - laissez le nouveau firmware le prend au même endroit que l'ancien, et nous donne juste les données des autres).
LoRaWAN implémente deux schémas d'utilisation des clés, individuels pour chaque appareil:
- Over The Air Activation, OTAA - les clés sont générées par le serveur réseau chaque fois qu'un appareil y est enregistré
- Activation par personnalisation - les clés sont définies par le fabricant et stockées sur l'appareil, sans jamais changer
Il existe au moins deux clés au total: AppSKey, qui crypte les données utilisateur, et NwkSKey, qui signe le message.
De toute évidence, le schéma OTAA est plus pratique et fiable - les clés peuvent changer aussi souvent que vous le souhaitez, elles sont garanties d'être uniques et ne sont connues de personne, à l'exception du serveur réseau. Dans ABP, les clés ne changent jamais, l'unicité dépend de la conscience du fabricant de l'appareil (par exemple, nous générons ces clés à partir de l'ID unique du microcontrôleur, donc la probabilité de leur coïncidence sur les deux appareils est négligeable), et elles doivent être stockées explicitement quelque part, donc lors de la connexion de l'appareil au réseau les enregistrer sur le serveur.
Cependant, la procédure d'obtention des clés dans OTAA est une histoire distincte qui, si elle est mise en œuvre de manière inexacte, peut donner lieu à plusieurs autres types d'attaques.
Interception des clés générées
Évidemment, si de nouvelles clés sont générées à chaque fois lors de l'inscription sur le réseau, elles doivent alors être synchronisées entre l'appareil et le serveur, ce qui signifie qu'un attaquant peut les intercepter, rompant ainsi toute la protection.
Par conséquent
, les appareils LoRaWAN ont une troisième clé - AppKey, étroitement connectée à l'appareil et utilisée à un seul instant: lors de l'enregistrement sur le réseau. Avec lui, un échange de clés de session entre l'appareil et le serveur est signé.
Idéalement, l'AppKey devrait être unique pour chaque appareil, mais dans de nombreux cas, l'utilisation de la même AppKey est autorisée - car elle n'est nécessaire qu'une seule fois, cela peut être reconnu comme valide.
AppKey avant de connecter l'appareil est entré dans ses paramètres sur le serveur réseau.
Ainsi, l'appareil génère une demande d'enregistrement (JoinRequest), non pas en le chiffrant (il ne contient aucune information sensible), mais en le signant avec la clé AppKey. Le serveur réseau, après avoir reçu ce paquet et vérifié l'adresse de l'expéditeur (s'il s'agit bien de notre appareil), puis la signature, répond avec le paquet JoinAccept, dans lequel il transfère les paramètres réseau - eh bien, il confirme en fait l'enregistrement.
D'où viennent les clés AppSKey et NwkSKey?
Ceci est le résultat du cryptage AES-128 avec la clé AppKey d'une combinaison d'un numéro AppNonce aléatoire, d'un numéro de clé (1 ou 2), d'un ID réseau et d'un autre numéro DevNonce aléatoire envoyé par le serveur dans la réponse:
NwkSKey = aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce) AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce)
Étant donné que le périphérique et le serveur après avoir échangé des paquets d'enregistrement connaissent tous ces paramètres, ils généreront les mêmes clés. Ainsi, à aucun moment, aucune clé ne sera transmise par radio par elle-même, mais en même temps, l'appareil et le serveur recevront des clés de chiffrement et des signatures de paquets uniques.
Interception d'un flux de données sur lui-même
Mais ce n'est pas tout!
Oui, l'événement d'enregistrement sur le réseau est généralement peu fréquent, mais imaginez qu'un attaquant a pu l'initier et l'intercepter.
Ensuite, s'il envoie simplement le paquet JoinRequest qu'il a enregistré, sans rien y changer, le serveur y répondra avec le paquet JoinAccept, générant de nouvelles clés. Après cela, le périphérique attaqué arrête simplement de communiquer avec le serveur, car il n'a pas lancé JoinRequest et ne voit aucune raison de mettre à jour les clés. Autrement dit, la même attaque est répétée - mais déjà sur la procédure d'enregistrement sur le réseau.
Un attaquant ne pourra pas truquer les données, car pour cela, vous devez connaître les clés, et pour les obtenir, vous devez connaître l'AppKey, qu'il ne connaît pas. Mais pour mettre l'appareil hors tension - il le peut.
Pour éviter cela, lors de l'enregistrement, l'appareil envoie un nombre aléatoire de DevNonce au serveur (regardez, c'est dans les packages ci-dessus). Outre le fait que les clés sont générées sur cette base, il sert un autre objectif - le
serveur LoRaWAN stocke l'archive DevNonce . Si l'appareil reçoit une demande d'enregistrement répétée avec le DevNonce déjà utilisé, le serveur l'ignorera simplement.
À son tour, l'appareil est obligé de générer un nouveau DevNonce à chaque enregistrement (c'est-à-dire que le circuit avec le relais de paquets conventionnels - «n'a pas reçu de réponse, a craché le même paquet à la radio une deuxième fois» - ne fonctionne pas ici, JoinRequest est recréé à chaque fois).
Conclusion
Bien qu'il se soit avéré beaucoup de texte et peu d'images, même ce n'est pas un schéma complet d'attaques possibles contre la radio uniquement (les questions sur pourquoi, par exemple, les paramètres doivent être cryptés sur l'appareil, et nous avons laissé la clé avec une clé individuelle pour chaque appareil hors des parenthèses, il ne s'agit plus de la radio). Par exemple, dans LoRaWAN 1.1, les schémas de protection sont devenus encore plus compliqués.
Néanmoins, il s'agit d'un ensemble gentleman de tout protocole radio qui prétend avoir une protection minimale digne des informations et en même temps est conçu pour fonctionner sur des appareils de faible puissance dans les réseaux à faible vitesse. De plus, il s'agit d'un très bon exemple de mise en œuvre non seulement d'un protocole sécurisé, mais d'un protocole écrit pour les appareils de faible puissance et minimisant la consommation de temps d'antenne et de puissance de calcul dans la mesure du possible sans dommage significatif pour la sécurité.
Et si vous concevez votre propre protocole pour l'IoT, le LoRaWAN bien spécifié, combiné à une compréhension des méthodes de base pour mener des attaques, offre une excellente occasion d'apprendre à organiser correctement cette protection.