LoRaWAN, acronyme de Long Range Wide Area Network, est un protocole de télécommunication LPWAN (Low Power Wide Area Network) par radio pour les objets connectés. Sa couche physique, LoRa, permet une communication à grande distance pour une faible consommation électrique et est donc adapté pour les systèmes embarqués sur batterie. LoRaWAN désigne la pile protocolaire qui fournit qualité de service et sécurité des transmissions par-dessus la couche physique LoRa.
Inventé par la startup Grenobloise Cycléo puis racheté par Semtech en 2009, LoRaWAN est aujourd’hui régulé par le comité LoRa Alliance, qui gère notamment la certification des appareils. Semtech commercialise les émetteurs/récepteurs LoRa ainsi que les passerelles pour la mise en place d’un réseau.

Le protocole se place en concurrence avec SigFox et NB-IoT sur le marché des capteurs industriels. De nombreux secteurs ont adoptés LoRaWAN pour son faible coût de déploiement de quelques euros par appareil et facilité d’utilisation.
On le retrouve dans l’internet des objets pour une application domestiques et divers capteurs de gestion des sols, surveillance animale et météorologique, relevé de compteurs urbains ou environnementaux, le suivi d’actifs et gestion de flotte, etc.

LoRa

LoRa est la couche physique du LoRaWAN, c’est un protocole de communication par radio qui utilise les bandes ISM: des plages de fréquences utilisables librement sans licence. Les bandes industrielles, scientifique et médicale (ISM) de radiofréquences sont définies par région (Europe, USA, Chine, Australie …). En Europe on retrouve plusieurs bandes ISM (433MHz, 868MHz, 2.4GHz, …) qui sont utilisées dans beaucoup d’applications domestiques (Bluetooth, WiFi, four à micro-onde) et cela ne va faire qu’augmenter avec l’internet des objets (SigFox, BLE, LoRa …).
Ces bandes sont contestées car l’économie d’une licence permet des solutions à faible coût pour des usages industriels ou domestiques, cela induit une cohabitation avec une multitude de protocoles dont un bruit et une dégradation de la qualité du signal.

LoRa Alliance à définit plusieurs plages utilisables suivant la région de déploiement du réseau, en Europe c’est la bande ISM 868MHz (EU868).
Pour réduire les effets du bruits dû à l’utilisation des bandes ISM, LoRa utilise la modulation Chirp Spread Spectrum (CSS). Initialement inventée pour les applications radar dans les années 1940, la modulation CSS est maintenant utilisée pour sa longue portée, résistance aux interférences et à l’effet Doppler ainsi qu’une basse consommation et faible débit, ce qui convient parfaitement pour les objets connectés.
Un saut de fréquence est opéré à chaque transmission: la prochaine fréquence utilisée pour transmettre est choisie pseudo-aléatoirement parmi les canaux paramétrés dans l’appareil.
Enfin, LoRa permet de gérer la relation débit/distance de transmission en changeant la bande passante et un facteur de diffusion (Spreading Factor – SF). Le SF varie entre 7 et 12 : un SF plus élevé augmente la distance au détriment du débit.

La modulation LoRa annonce une portée de 5km en zone urbaine et 15km en rurale ainsi qu’une longévité d’un appareil sur batterie se comptant en années (~10 ans). Le record de distance pour une transmission est actuellement de 832km.
LoRa peut être utilisé sans la pile protocolaire LoRaWAN pour une communication P2P entre machines. Dans ce cas libre au constructeur d’implémenter ses mécanismes de qualité de service et sécurité que fournit LoRaWAN au-dessus du LoRa.

LoRaWAN

LoRaWAN est l’un des protocoles développés en tant que couche supérieure du LoRa et maintenu par la LoRa Alliance. Il définit les couches entre celle physique (LoRa) et application (données). Il agit principalement comme protocole de routage des communications entre l’appareil LoRaWAN déployé et le serveur applicatif en garantissant sécurité et acheminement.

Couches réseau LoRaWAN

Par économie de batterie, LoRaWAN fait en sorte que les appareils n’écoutent activement que sur des fenêtres prédéfinies.
La transmission est toujours initiée depuis l’appareil qui écoute sur 2 courtes fenêtres de réception ensuite. La communication reste bidirectionnelle mais initiée par l’appareil.

La première version (1.0) parait début 2015 et est aujourd’hui en 1.0.4 (octobre 2020). Une version 1.1.x non-rétro compatible avec la 1.0.x est maintenue en parallèle depuis octobre 2017, elle inclut de nouvelles fonctionnalités et mécanismes de sécurité.

Architecture d’un réseau LoRaWAN

LoRaWAN est pensé pour qu’un constructeur n’ait à gérer que ses appareils disséminés sur le territoire et leur application qui traite les données remontées par ces appareils.
La collecte, acheminement et vérification des données peut être déléguée à un opérateur. L’opérateur s’occupe d’installer des passerelles pour maximiser la couverture réseau LoRa, gère des serveurs réseau (network server – NS dans la spécification LoRaWAN) pour traiter les communications, en vérifier l’authenticité et acheminer vers le bon serveur d’application (application server – AS).
Même si l’architecture a été pensée pour que le coeur de réseau (passerelles, serveur réseau) soit indépendant de l’application, un constructeur peut déployé ses passerelles et serveurs pour gérer son réseau LoRaWAN indépendamment.

Architecture d’un réseau LoRaWAN

Comme beaucoup d’objets connectés retrouvés dans l’IoT, le LoRaWAN utilise plusieurs protocoles. L’appareil déployé transmet en LoRa à toutes les passerelles à proximité.
La passerelle transmet le paquet LoRaWAN via un lien IP sur différents medium physique suivant son environnement (ethernet, fibre, wifi, 4G…). Semtech à développé son propre protocole basé sur UDP pour transmettre les paquets des passerelles au serveur réseau (Semtech packet forwarder). MQTT est également beaucoup utilisé pour sa qualité de service car basé sur TCP.
Le serveur réseau vérifie l’authenticité et intégrité du paquet via le MIC puis transmet les données contenues dans le paquet LoRaWAN au bon serveur d’application en se basant sur l’identifiant de l’appareil.

Paquet LoRaWAN

On retrouve 2 types de paquets LoRaWAN: les messages de données et d’appairage. Les JoinRequest et JoinAccept sont ceux d’appairage et le reste de données. Un message de données peut être montant (uplink – direction du server) ou descendant (downlink – direction de l’appareil).
Dans un message de données on retrouve l’identifiant de l’appareil (DevAddr), de quoi gérer le contrôle de flux (FCtrl), un compteur de paquets FCnt, les données chiffrées dans FRMPayload et une signature (MIC).

Format d’un paquet LoRaWAN

Sécurité

LoRaWAN utilise 2 clés de chiffrement symétrique AES partagées entre l’appareil et les serveurs :

NwkSKey assure intégrité et authenticité du paquet LoRaWAN jusqu’au serveur réseau via une signature AES CMAC retrouvée dans le champ MIC. Le MIC est calculé sur le MHDR, FHDR, FPort et FRMPayload. Cette clé est utilisée pour établir un canal sécurisé entre l’appareil et le serveur réseau.

Signature du paquet

La clé AppSKey chiffre les données pour constituer le champ FRMPayload à destination du serveur applicatif. Cela garantie la confidentialité en établissant un canal sécurisé entre l’appareil et le serveur applicatif de son constructeur car le serveur réseau n’est pas censé avoir accès à cette clé.

Chiffrement des données

La confidentialité est donc garantie de l’appareil jusqu’à l’application tandis que l’intégrité et authenticité le sont jusqu’au serveur réseau.
La gestion d’intégrité et d’authenticité sur le lien serveur réseau / serveur applicatif est laissée à l’opérateur et son client. Le MIC permet seulement de garantir que le serveur réseau communique bien avec le bon appareil avant d’exécuter les commandes MAC et de router les données à son serveur applicatif.

Anti-rejeu

Le compteur de paquets, FCnt, constitue un mécanisme d’anti-rejeu car celui-ci ne peut que s’incrémenté de paquets en paquets.
L’appareil et le serveur réseau gardent 2 compteurs synchronisés : un pour les communications montantes (uplink – FCntUp) et l’autre pour les descendantes (downlink – FCntDwn). Le compteur utilisé dans le champ FCnt dépend de la direction du paquet.

Puisque le FCnt est pris en compte dans le calcul du MIC, qui garantit l’authenticité du paquet, un attaquant ne peut pas forger de paquets avec un FCnt arbitraire et comme le FCnt ne peut qu’augmenter, un paquet précédent sera refusée par l’appareil et le serveur réseau.

Qualité de service

Chaque type de paquet (montant ou descendant) peut demander un accusé de réception (mode confirmed) ou non (unconfirmed). Le mode confirmed demande que le prochain paquet du récepteur d’un paquet confirmed ait le champ ACK (dans FCtrl) à 1.
Comme les ondes radio ne sont pas totalement fiables (interférences, brouillage ciblé, distance d’émission), un paquet peut être retransmis. Le paquet est retransmis telle qu’elle dans le cas d’un paquet montant (FCntUp n’est pas incrémenté) contrairement à un paquet descendant.

Activation

LoRaWAN est fait pour des systèmes embarqués disséminés dans la nature. Les constructeurs disposent de 2 façons d’approvisionner les clés cryptographiques et identifiants nécessaires à l’établissement d’une session.

  1. Activation By Personnalisation (ABP): Ne requiert pas de phase d’appairage pour établir une session. Les clés de session NwkSKey et AppSKey sont entrées manuellement avant déploiement du produit et ne changent jamais, son adresse DevAddr est également statique.
  2. Over The Air Activation (OTAA): Le constructeur rentre une clé maître, AppKey, qui va permettre de dériver des clés de session NwkSKey et AppSKey lors de la phase d’appairage. Un DevEUI et AppEUI permettent de reconnaître l’appareil lors de la phase d’appairage en place du DevAddr, qui sera attribué dynamiquement par le serveur réseau.

Appairage OTAA

  1. La phase d’appairage est initiée par l’appareil avec un JoinRequest signé avec AppKey auquel le serveur répond un JoinAccept (chiffré et signé avec AppKey) s’il accepte la connexion.
  2. Chacun des messages contient un nonce, un nombre qui ne doit être utilisé qu’une fois (un nombre aléatoire dans le cas du LoRaWAN). Ces nonces, DevNonce et AppNonce, sont utilisés pour dériver les clés de session NwkSKey et AppSKey par l’appareil et le serveur réseau à partir de la clé maître AppKey.
  3. Le serveur réseau transmet la AppSKey au serveur applicatif.
  4. L’appareil et le serveur réseau connaissent NwkSKey. L’appareil et le serveur applicatif connaissent AppSKey.
Etablissement d’une session OTAA

Conclusion

LoRaWAN est un protocole conçu pour l’IoT, autant par la couverture qu’offre sa couche physique LoRa (de 5 à 15km) que ses considérations d’économie d’énergie et faible complexité.
Le protocole prend en considération la sécurité puisque intègre plusieurs mécanismes dès sa première version même si plusieurs vulnérabilités ont été découvertes et seront discutées dans la seconde partie.

À lire également