FAQ sur la sécurité du protocole LoRaWAN

Sécurité LoRaWAN

LoRaWAN est un protocole réseau à longue portée et pourtant de faible puissance (Low Power, Wide Area - LPWA) conçu pour connecter sans fil des appareils alimentés par batterie à Internet local ou mondial et fournir des exigences clés pour l'Internet des objets (IoT - Internet des objets) telles que communication bidirectionnelle, sécurité des connexions, mobilité, etc.

La sécurité est une priorité absolue pour tout développement IoT. La spécification LoRaWAN définit deux niveaux de protection cryptographique:

• une clé de session réseau 128 bits unique partagée entre le terminal et le serveur réseau;
• clé de session d'application 128 bits unique (AppSKey - Application Session Key) commune de bout en bout au niveau de l'application.

Les algorithmes AES sont utilisés pour fournir l'authentification et l'intégrité des paquets dans un serveur réseau et pour le chiffrement de bout en bout au niveau du serveur d'applications. La fourniture de ces deux niveaux vous permet d'implémenter des réseaux partagés multi-locataires, où l'opérateur réseau n'a pas la possibilité de voir les données de charge utile des utilisateurs.

Les clés peuvent être activées via la personnalisation (ABP - Activated By Personalization) sur la ligne de production ou lors de la mise en service, ou peuvent être activées via un réseau (OTAA - Over-The-Air Activated) sur le terrain. La méthode d'activation OTAA permet à l'appareil de changer les clés selon les besoins.

FAQ sur la sécurité

Où sont décrits les mécanismes de sécurité du protocole LoRaWAN?

Tous les mécanismes de protection sont décrits dans les spécifications de la LoRa Alliance, qui peuvent être téléchargées à partir de leur site Web. Pour le moment, vous pouvez télécharger la version 1.0.x et ces réponses sont basées sur celle-ci. La version 1.1 est en cours de développement.

Comment la spécification LoRa Alliance sécurise-t-elle les réseaux LoRaWAN?

LoRaWAN prend en charge l'authentification d'origine, l'intégrité et la protection contre la relecture sur l'ensemble de la trame MAC (Media Access Control). Il permet également le chiffrement de bout en bout de la charge utile de l'application entre le terminal et sa réponse côté réseau (appelé serveur d'applications dans la version 1.1). LoRaWAN prend en charge un mode de fonctionnement qui vous permet de crypter les commandes MAC.

Toutes ces procédures reposent sur la norme de chiffrement avancé AES et utilisent des clés et des algorithmes cryptographiques à 128 bits.

Existe-t-il des différences entre les modes ABP et OTAA en termes de sécurité de l'information?

LoRaWAN utilise des clés racine statiques et des clés de session générées dynamiquement.
Les clés racine sont fournies uniquement dans les appareils OTAA. Ils sont utilisés pour obtenir des clés de session lorsque le terminal OTAA exécute la procédure de jointure. Un terminal en mode OTAA, lorsqu'il est installé sur le terrain, peut se connecter à n'importe quel réseau qui a une sortie vers un serveur clé (dans la version 1.1, Rejoindre un serveur) avec lequel le terminal est connecté. Les clés de session ainsi obtenues sont déjà utilisées par les terminaux pour protéger le trafic aérien.

Les appareils ABP n'utilisent pas de clés racine. Au lieu de cela, ils sont fournis avec un ensemble de clés de session pour un réseau présélectionné. Les clés de session restent inchangées pendant toute la durée de vie du périphérique ABP.

La possibilité de modifier les clés de session rend les appareils OTAA plus adaptés aux applications nécessitant un niveau de sécurité plus élevé.

Quelle est l'identité de LoRaWAN?

Chaque terminal est identifié par un numéro unique global 64 bits (EUI - Extended Unique Identifier), attribué soit par le fabricant, soit par le propriétaire du terminal. L'attribution de numéros EUI nécessite que le cédant ait un OUI unique (Organizationally Unique Identifier) ​​de l'autorité d'enregistrement IEEE.

Chaque serveur Join qui utilise l'authentification de terminal est également identifié par un EUI global 64 bits, attribué par le propriétaire ou l'opérateur de ce serveur.

Les réseaux LoRaWAN ouverts et les réseaux privés qui «communiquent» avec les LoRaWAN ouverts sont identifiés par un identifiant unique de 24 bits attribué par la LoRa Alliance.

Lorsque le terminal est correctement connecté au réseau, il reçoit l'adresse temporaire 32 bits attribuée par le réseau.

Puis-je attribuer des numéros à mes appareils ou réseaux de manière aléatoire?

Non. La question précédente décrit les règles d'affectation pour chaque type d'identifiant. Si vous ne suivez pas ces règles, il peut y avoir une coïncidence de nombres et un comportement imprévisible pendant le déploiement de votre réseau (similaire à ce qui pourrait se produire si vous utilisez les mêmes adresses MAC Ethernet sur différents appareils connectés au même LAN).

Tous les terminaux qui ne sont plus en production ont-ils la même clé cryptographique «par défaut»?

Non. LoRaWAN n'a pas le concept de «clé par défaut» ou de «mot de passe par défaut». Tous les terminaux ont des clés uniques, même en sortie de production. Ainsi, une seule clé compromise d'un périphérique terminal n'affectera en aucun cas les autres périphériques.

Quel type de clés cryptographiques sont utilisées?

Les points de terminaison OTAA ont des clés racine appelées AppKeys (Application Root Keys). Côté réseau, les clés AppKey se trouvent sur le serveur Join, qui peut être ou non un serveur réseau en même temps.

Les points de terminaison ABP ont deux clés de session AppSKey et NwkSKey (Network Session Key). Côté réseau, NwkSKey est situé sur le serveur réseau et AppSKey sur le serveur d'applications.

Les procédures utilisées pour fournir aux clés répertoriées tous les éléments de réseau requis (périphérique terminal, serveur Join, serveur réseau, serveur d'applications) n'entrent pas dans le cadre de la spécification LoRaWAN.

Quels algorithmes de cryptographie sont utilisés?

L'algorithme AES-CMAC décrit dans la RFC4493 est utilisé pour l'authentification d'origine et la protection de l'intégrité. L'algorithme AES-CCM décrit dans IEEE 802.15.4-2011 est utilisé pour le chiffrement.

Comment LoRaWAN vous empêche-t-il d'écouter?

Les données MAC sont cryptées entre le terminal et le réseau au moment de la transmission par voie hertzienne. De plus, la charge utile est cryptée entre le terminal et le serveur d'applications (ce que l'on appelle le cryptage de bout en bout). Cela garantit que seuls les objets autorisés contenant des clés de chiffrement peuvent accéder au contenu du paquet.

Comment LoRaWAN empêche-t-il l'usurpation de données?

L'intégrité et l'authentification des données MAC sont protégées par le champ paquet, qui contient le code MIC (Message Integrity Code) connu du terminal et du réseau. Cela garantit que seuls les objets autorisés qui contiennent des clés d'intégrité (c'est-à-dire le terminal et le serveur réseau) peuvent générer des messages valides.

Comment LoRaWAN décourage-t-il les retransmissions?

La protection de l'intégrité des données MAC utilise des compteurs de messages pour garantir que le destinataire n'accepte pas un message déjà reçu (c'est-à-dire potentiellement retransmis).

LoRaWAN prend-il en charge la protection de la charge utile des applications?

LoRaWAN assure le chiffrement de la charge utile des applications de bout en bout entre le terminal et le serveur d'applications. La protection de l'intégrité est assurée dans sa structure bond par bond: un bond en direct via la protection de l'intégrité LoRaWAN et un autre bond entre le serveur réseau et le serveur d'applications à l'aide de technologies de transmission sécurisées telles que HTTPS et VPN. Les applications nécessitant une protection de l'intégrité de bout en bout sont encouragées à faire de même avec leur charge utile.

Comment les interfaces backend sont-elles protégées?

Les interfaces dorsales sont impliquées dans la gestion et l'échange de données entre les serveurs réseau, les serveurs Join et les serveurs d'applications. Les technologies HTTPS et VPN sont recommandées pour protéger l'échange de données entre ces éléments d'infrastructure critiques, dans la même mesure qu'elle est mise en œuvre dans d'autres systèmes de télécommunications. Les interfaces dorsales n'entrent pas dans le cadre de la spécification LoRaWAN.

LoRaWAN prend-il en charge la protection matérielle?

L'amélioration de la sécurité des terminaux et des plates-formes de serveurs en termes de matériel (éléments de sécurité ou modules de sécurité) fait référence à des problèmes de mise en œuvre des équipements et n'est pas liée à l'interopérabilité des protocoles visant la qualité de la communication, notamment LoRaWAN. Cependant, l'utilisation de ces solutions techniques est compatible avec la spécification LoRaWAN et peut être mise en œuvre par le développeur conformément aux exigences de l'application.

Que dois-je faire si je découvre un risque pour la sécurité?

En général, un risque pour la sécurité peut survenir pour l'une des trois raisons, ou leurs combinaisons:

• spécification (par exemple, manque de protection contre les répétitions),
• l'implémentation (par exemple, extraire une clé d'un appareil),
• Déploiement (par exemple, le manque d'écrans de protection).

La première étape consiste à établir la cause. Si la raison se trouve dans la spécification, écrivez l'aide dans la LoRa Alliance pour l'envoyer. Pour toute question concernant la vente d'équipement, contactez le fabricant.
Et les problèmes de déploiement sont décidés par les opérateurs de réseau LoRaWAN.

Source