LORAWAN : déploiement d’une infrastructure de test – Partie 1/2

Les opérateurs de télécommunications ont commencé à déployer des réseaux ainsi qu’à fournir des offres d’abonnements pour une galaxie d’objets connectés utilisant la technologie LoRaWAN. Celle-ci leur permet de communiquer par ondes radio sur de grandes distances afin de réaliser de la remontée d’informations. Selon son succès, notre environnement devrait progressivement s’enrichir de ces équipements « communicants » . Les quelques publications sur la sécurité des réseaux LoRaWAN ont donné lieu à des articles aux titres alarmistes qui ont suscité l’envie de savoir si un hacker pouvait effectivement pirater du trafic LoRaWAN à l’abri des ondes radio…

LoRaWAN est un protocole permettant la communication à bas débit dans des réseaux étendus au moyen de la technologie de modulation LoRa développée par la société SemTech. Celle-ci permet de communiquer sur de longues distances de l’ordre de la dizaine de kilomètres en utilisant peu d’énergie ; elle fait partie des choix réalisés dans le développement des réseaux IoT. Son développement commercial est suivi par différents opérateurs de télécommunications du marché.

La société Orange a ainsi annoncé : « LoRa sera déployé dès 2016, pour répondre à un besoin de connectivité des objets déjà très présent. […] Orange a démarré son projet IoT en 2011 […] Un réseau test à Grenoble nous a pleinement convaincus d’adopter la technologie LoRa […] D’ores et déjà, nous allons déployer rapidement le réseau LoRa sur 1 200 communes de 17 agglomérations françaises dès le 1er trimestre 2016. » [ORA].

La société Bouygues a quant à elle annoncé : « À l’issue d’une expérimentation menée à Grenoble, Bouygues Télécom a fait le lancement en juin 2015 du premier réseau français dédié aux objets connectés basé sur la technologie LoRa. Il l’a annoncé lors du CES (Consumer Electronics Show) de 2015. Membre fondateur de l’Alliance LoRa, Bouygues Télécom est le premier opérateur français à déployer commercialement cette technologie reconnue mondialement comme la plus aboutie dans le domaine de l’Internet of Things. » [BOUY].

Il existe déjà des publications sur la sécurité LoRaWAN. Cependant, les articles publiés sont restés théoriques tel [MRW]. D’autres présentations sont restées privées [REN] et ont fait l’objet d’une vulgarisation dans la presse généraliste [01net]. Le but de cet article est de présenter quelques résultats au travers du déploiement d’une infrastructure de test afin d’étudier la capture et le chiffrement du trafic LoRaWAN.

1. Architecture et chiffrement

LPWAN, LoRa et LoRaWAN
Dans le cadre des réseaux LPWAN (Low Power Wide Area Network), LoRa (LongRange) correspond à la couche liaison. Il s’agit d’une modulation radio utilisant des bandes radio régionales ISM : 868 Mhz en Europe. Le protocole LoRaWAN correspond quant à lui à la couche réseau. Différentes classes A,B et C offrent des fonctionnalités variées. Le cadre de cet article sera restreint aux classes B.

Un réseau LORAWAN comprend trois catégories d’éléments représentés dans la figure 1 :

  • Les nœuds : il s’agit des objets connectés disposant d’un émetteur récepteur LoRaWAN. Ils disposent de capteurs afin d’effectuer de la remontée d’informations et peuvent recevoir des messages pour déclencher des opérations. Ils sont déployés dans l’environnement après avoir été configurés et doivent être autonomes. Ils disposent d’un identifiant unique DevEUI de 64 bits. Les informations remontées sont associées à un numéro d’application unique AppEUI de 64 bits. Selon la méthode d’activation choisie, une clé AppKey ou deux clés NwkSKey et AppSKey devront être choisies. Elles ont une taille de 128 bits.
  • Les passerelles : elles sont déployées par les opérateurs ou par des associations souhaitant déployer un réseau IoT LoRaWAN. Placées de préférence en hauteur afin de maximiser la réception, elles sont chargées de recevoir les paquets LoRa et de transmettre ceux qui sont des paquets LoRaWAN valides vers les différents serveurs applicatifs. Pour y parvenir, elles sont connectées à ceux-ci au moyen de liens réseaux classiques : réseaux câblés ou mobiles. Elles sont identifiées par un identifiant de 8 octets.
  • Les serveurs applicatifs : ces équipements prennent en charge le traitement du protocole LoRaWAN :  activation des nœuds, déchiffrement des données et transmission vers les applications métiers.

Figure 1 : Architecture LoraWan.


1.1 Choix des clés, méthode d’activation et sécurité

Lors de la configuration des nœuds, il est nécessaire de choisir entre deux modes d’activation :

  • ABP (Activation By Personalization) : deux clés NwkSKey et AppSKey doivent être choisies ainsi qu’une adresse réseau DevAddr de 4 octets. Ce sont ces clés qui seront utilisées pour dériver un keystream utilisé lors des opérations de chiffrement. Elles sont configurées directement dans l’équipement avant son déploiement et dans l’interface d’administration des objets connectés du serveur d’applications.
  • OTAA (Over The Air Activation) : dans ce mode, une simple clé AppKey est nécessaire à la configuration du nœud. Elle doit être aussi configurée dans le serveur d’application. Lors du démarrage du nœud, cette clé sera utilisée au cours d’un premier échange de messages Join-Request et Join-Accept pour générer des clés de session NwkSKey et AppSKey qui seront ensuite utilisées pour chiffrer les données échangées ; ces clés de session sont conservées jusqu’à leur réinitialisation. Lors de cette étape, le nœud envoie un aléa de 16 bits qui sera utilisé pour dériver les clés de sessions. Un paquet Join-Accept sera renvoyé à destination du nœud, chiffré avec l’AppKey et contenant notamment l’adresse DevAddr attribuée automatiquement ainsi qu’un aléa de 24 bits utilisé pour dériver les clefs de sessions.

1.2 Chiffrement des données LoRaWAN

Comme mentionné dans [MWR], les clés NwkSKey et AppSKey ne sont pas utilisées pour chiffrer au moyen d’AES, mais pour en dériver une séquence de clés qui seront utilisées pour du chiffrement par bloc au moyen d’une opération Xor. Les paramètres qui permettent de déterminer l’étape de cette séquence sont l’adresse DevAddr du nœud et le champ sequenceCounter du message. Ces deux champs sont connus lors de l’interception de paquets. On pourra se référer au chapitre 4 de la spécification LoRaWAN [LORA] pour le format des différents messages.

Par ailleurs, le choix de la clé à utiliser est déterminé par un champ Fport présent dans les requêtes d’envoi de données. Le port 0 est réservé aux messages à destination du Network Server qui seront déchiffrés en utilisant NwkSKey ; les autres ports sont laissés aux applications qui utiliseront la clé AppSKey.

2. Installation d’une infrastructure LoRaWAN

Le schéma suivant présente les composants a installer :

Figure 2 : Composants de notre architecture LoRaWAN.


Le choix du matériel s’est porté sur les éléments suivants :

  • Un concentrateur iC880A-USB [Gate] pour la passerelle : basé sur la référence SX1257 de Semtech, il permet la réception de paquets LoRa sur les différents canaux disponibles et leur démodulation en paquets LoRaWAN.
  • Un StarterKit IM880B [Node] : basé sur la référence SX1272, ces deux nœuds de développement permettent l’utilisation d’un firmware LoRa ou LoRaWAN ; il est par ailleurs possible de reconfigurer leur DevEUI, les sources de l’implémentation sont disponibles, ce qui permet leur inspection ainsi que leur réutilisation dans le développement d’outils.

2.1 Installation d’une passerelle

2.1.1 Compilation et installation du packet_forwarder

La fonction de passerelle entre les nœuds et les serveurs applicatifs est assurée par le packet_forwarder. Celui-ci qui communique d’une part avec le concentrateur en USB pour l’échange des paquets LoRaWAN, d’autre part en UDP avec le serveur applicatif.

L’implémentation Semtech [STH] ne supportant pas l’USB, on utilise l’implémentation proposée par TheThingsNetwork [TTN]. Il s’agit d’une initiative déployant une infrastructure LoRaWAN libre dans différents pays d’Europe : Pays-Bas, Suisse…

Afin de construire le packet forwarder, il sera nécessaire préalablement de compiler et installer la bibliothèque [mpss]. Elle permet d’interagir en I2C avec un périphérique FTDI/USB. Elle sera nécessaire à la compilation du packet_forwarder et de la libloragw [LIBLG].

Lors de la compilation de lora_gateway, il est nécessaire de modifier la configuration afin de spécifier la plateforme à utiliser. La configuration par défaut de celle-ci lui permet de fonctionner avec une plateforme matérielle Kerlink en SPI. Dans le cas de l’ic880A, il faudra modifier les champs CFG_SPI de native à ftdi et PLATFORM de kerlink à lorank dans le fichier library.cfg avant de procéder à la compilation pour pouvoir utiliser la communication FTDI.

Les fichiers de configuration chargés sont d’abord global_conf.json puis local_conf.json dont les options écraseront les précédentes. Il est important de vérifier la valeur du champ gateway_ID qui sera utilisé pour surveiller des files [MQTT]. Il s’agit d’un protocole de messagerie utilisé entre les différents composants du serveur applicatif et pris en charge par le serveur mosquitto.

2.1.2 Test du concentrateur LoRaWAN

En branchant le concentrateur, un nouveau périphérique FTDI devrait être détecté. Il sera alors possible de vérifier son fonctionnement avec l’utilitaire util_tx_test avant de pouvoir utiliser le packet_forwarder.

Le packet_forwarder a pour rôle de recevoir les paquets à partir du concentrateur LoRa. Ils sont ensuite transmis par UDP vers l’infrastructure LoRaWAN : Network et Application server qui prendront en charge la configuration des nœuds ainsi que le déchiffrement des paquets. Si le serveur applicatif est installé sur une machine différente, il sera nécessaire de reconfigurer le packet_forwarder en modifiant les champs server_address, serv_port_up et serv_port_down dans le fichier de configuration global_conf.json.

2.2 Installation du serveur applicatif

Afin de fournir les services basiques LoRaWAN d’activation et de déchiffrement, il est nécessaire d’installer un serveur applicatif. Une solution libre existe qui fournit les services de base des réseaux de classe B:LoRaServer [APPS].

Il se compose de trois éléments distincts dont l’installation ne présente pas de difficulté particulière : lora-gateway-bridge, loraserver et lora-app-server. Chaque logiciel nécessite un fichier de configuration dans /lib/systemd/system pour pouvoir démarrer automatiquement en tant que service ainsi qu’une configuration minimale dans /etc/default. Différents fichiers de configuration sont fournis en annexe sur le [GITHUB].

  • Lora-gateway-bridge : cet élément reçoit les paquets UDP transmis par le packet_forwarder. Ces paquets sont alors stockés dans une file MQTT.
  • Loraserver : à partir des files MQTT, le loraserver prend en charge les paquets LoRaWAN afin de répondre aux demandes d’activation et de déchiffrer les données reçues pour les nœuds dont les clés de session ont été configurées. Il est nécessaire d’installer une base de données postgresql qui permet la persistance des données notamment pour les clés de session utilisées.
  • Lora-app-server : cette interface permet la création et configuration de nœuds pris en charge par le loraserver.

Si jamais le packet_forwarder fonctionne sur une machine différente, il est nécessaire de s’assurer que le champ UDP_BIND est correctement configuré dans le fichier de configuration du serveur lora-gateway-bridge.

Une fois ces éléments installés et démarrés, il est possible de se connecter à l’interface de gestion du serveur applicatif en pointant un navigateur vers l’adresse https://loraserver:8080/.

Figure 3 : Interface d’administration du serveur applicatif.


Sébastien ROY

La seconde partie de cet article sera publiée prochainement sur le blog, restez connectés 😉

Retrouvez cet article (et bien d’autres) dans MISC Hors-Série n°15, disponible sur la boutique et sur la plateforme de lecture en ligne Connect !

Laisser un commentaire