LORAWAN - Kasimashi/Systemes-embarques GitHub Wiki

LoRA

LoRaWAN (Low Range Wide Aera Network - Réseau Étendue Longue Portée) est un protocole de communication radio qui constitue l'architecture du système et qui vous permet d'avoir une transmission de données bas débit mais surtout longue portée pour tous vos objets connectés, et peu consommatrice d'énergie. (exemple : capteur IoT communicant).

LoRa est le nom donné à la technologie de modulation des ondes radios sur laquelle sont basés les réseaux longue portée et bas débit LoRaWAN. Cette technologie a été créée par des ingénieurs français de la start-up grenobloise Cycleo. L'entreprise, fondée en 2009, a été rachetée en 2012 pour 21 millions de dollars par le spécialiste américain des semi-conducteurs Semtech. Le réseau LoRaWAN est né de cette acquisition. "LoRaWAN est un protocole tandis que LoRa fait référence à la couche physique du réseau".

image

Caractéristique

  • Il émet en France sur la bande de fréquence 868 mégahertz. Le signal radio est émis sur une grande largeur spectrale, pour limiter au maximum le risque d'interférence avec des signaux parasites.
  • Un objet connecté en LoRaWAN peut envoyer un message à une borne située à une distance d'environ 1 kilomètre en zone urbaine et à 14 kilomètres dans une zone rurale plane.
  • Elle peut faire transiter entre 0,3 et 50 kilobits par seconde (le débit du réseau s'adapte à chaque objet pour ne pas grignoter trop de bande passante.

D'un point de vue hardware.

D’un point de vue pratique, chaque objet connecté et chaque passerelle sont équipés d’un module Radio Fréquences tel que celui représenté ci-contre.

image

Celui-ci intègre au moins trois éléments fondamentaux.

  • 1 : Il s’agit du microcontrôleur permettant de piloter le module RF (2).
  • 2 : le module RF contient à la fois le processeur de bande de base (Transceiver), le modulateur IQ ainsi que l’étage RF.
  • 3 : le connecteur SMA est destiné à recevoir l’antenne d’émission (de l’objet communicant vers la passerelle) et de réception (de la passerelle vers l’objet communicant).

LORAWAN

https://resources.lora-alliance.org/document/lorawan-specification-v1-0-2

Format des packets

image

  • Trame de couche physique : au niveau de la couche PHY

    • une trame LoRa commence par un préambule. Outre la fonction de synchronisation, le préambule définit le schéma de modulation des paquets, modulé avec le même facteur d'étalement que le reste du paquet. Typiquement, la durée du préambule est de 12,25 Ts.
    • Le préambule est suivi d'un en-tête PHY et d'un en-tête CRC qui, ensemble, ont une longueur de 20 bits et sont codés avec le débit de code le plus fiable de , tandis que le reste de la trame est codé avec le débit de code spécifié dans l'en-tête PHY. L'en-tête PHY contient également des informations telles que la longueur de la charge utile et si le CRC de 16 bits de la charge utile est présent dans la trame. Plus précisément, dans un réseau LoRa, seules les trames de liaison montante contiennent la charge utile CRC. La charge utile PHY contient une trame MAC

  • Trame de couche MAC : le paquet traité dans la couche MAC se compose de :

    • Une en-tête MAC (1bytes), L'en-tête MAC définit la version du protocole et le type de message, c'est-à-dire s'il s'agit d'une trame de données ou de gestion, si elle est transmise en liaison montante ou descendante, si elle doit être accusée de réception. L'en-tête MAC peut également indiquer qu'il s'agit d'un message spécifique au fournisseur.
    • Une charge utile MAC : Dans une procédure de jointure pour l'activation du nœud final, la charge utile MAC peut être remplacée par une demande de jointure ou des messages d'acceptation de jointure.
    • Un code d'intégrité de message (MIC). L'intégralité de la partie en-tête MAC et charge utile MAC est utilisée pour calculer la valeur MIC avec une clé de session réseau grâce à un AES CMAC (Nwk_SKey). La valeur MIC est utilisée pour empêcher la falsification des messages et authentifier le nœud final.

  • Paquet de couche application : la charge utile MAC gérée par la couche application se compose de :

    • D'un en-tête de trame (7-22bytes)
    • D'un port de trame (1 byte) et d'une charge utile de trame. La valeur Frame Port est déterminée en fonction du type d’application.
    • La valeur Frame Payload (N Bytes) est chiffrée avec une clé de session d’application (App_SKey). Ce cryptage est basé sur l'algorithme AES 128.

  • Le "Frame Header" contient les informations suivantes:

    • "Device Address" 4 bytes contient deux parties. Les 8 premiers bits identifient le réseau, les autres bits sont attribués dynamiquement lors de la connexion au réseau et identifient l'appareil dans un réseau.
    • "Frame Control" : 1 byte pour les informations de contrôle du réseau, par exemple s'il faut utiliser le débit de données spécifié par la passerelle pour la transmission en liaison montante, si ce message accuse réception du message précédent, si la passerelle dispose de plus de données pour le mote.
    • "Frame Counter" 2 bytes pour la numérotation séquentielle
    • "Frame Options" : 15 bytes pour les commandes utilisées pour modifier le débit de données, la puissance de transmission et la validation de la connexion, etc.

La sécurité en Lorawan

Il y a deux niveau de sécurités en ce qui concerne Lorawan

  • Une clef AES-128-CBC bits NwkSKey (Network Session Key) utilisé pour assurer l'intégrité des données et l'authenticité.
  • Une clef AES-128 bits AppSKey (Application Session Key) utilisé pour la confidentialité.

image

Etablir une communication en LoraWan

Deux façon pour établir une connexion en LoraWan :

  • Joindre un réseau dynamiquement (OTAA (Over-The-Air Activation))

    • La procédure de JOIN est faites entre le end-device et le network server.
    • DevAddr est assigné au device, émis par le Network Server
    • Les clées de sécurités sont négociés à chaques activation.

  • Hardcoded session (ABP (Activation by Personalization))

    • La procédure de JOIN n'est pas nécessaire
    • DevAddr et les clés de sécurités sont hardcodé dans le device.

Avant de commencer une communications les informations suivantes sont nécessaires : DevAddr, NwkSKey, AppSKey

Over-The-Air Activation (OTAA)

Le device et le réseau échange une clef 128 bits AppKey. Quand le device envoi la demande de JOIN, l'AppKey est utilisé pour créer un Message Integrity Code (MIC), le serveur ensuite vérifie le MIC avec l'AppKey. Si le check est valid, le serveur créer deux nouvelles clées 128 bits :

  • The App Session key (AppSkey)
  • The Network Session Key (NwkSkey). Ces clefs sont envoyés au device en utilisant l'AppKey comme clé d'encryptions. Quand les clefs sont reçu le device decrypte et installe les deux clés de sessions.
LoRaWAN 1.0.x

Dans LoRaWAN 1.0.x, la procédure de JOIN nécessite l'échange de deux messages MAC entre le EndDevice et le NetworkServer :

Avant l'activation, l'AppEUI, le DevEUI et l'AppKey doivent être stockés sur le endDevice. **L'AppKey **est une clé secrète AES-128 bits connue sous le nom de clé root (racine). La même AppKey doit être mise à disposition sur le Network Server sur lequel le périphérique final va s'enregistrer. Note : L'AppEUI et le DevEUI ne sont pas secrets et sont visibles par tous. L'AppKey n'est jamais envoyé sur le réseau.

Demande de JOIN

  • Join-Request- from end device to the Network Server

    • AppEUI: Application Identifier
    • DevEUI: Le DevEUI est un identifiant global de périphérique final dans l'espace d'adressage IEEE EUI64 qui identifie de manière unique 20 le périphérique final.
    • DevNonce: Nombre aléatoire généré par le end device

    L'intégrité du message (4 bits) est assurée par le message integrity code (MIC) : il est calculé ainsi grâce à un CMAC:

    $cmac=aes128cmac(AppKey,MHDR | AppEUI [ DevEUI | DevNonce)$

    $MIC = cmac[0..3]$

  • Join-accept- from Network Server to the end device.

    • AppNonce: Valeur aléatoire donnée par le network server
    • NetID: Network Identifier
    • DevAddr: End Device Address
    • RxDelay: Delais entre TX et RX
    • CFList: Channel Frequencies Optional List (Region specific)

    Les clefs dans le end device sont calculés ainsi :

    $NwkSKey = aes128encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce | pad16)$

    $AppSKey = aes128encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce | pad16)$

    La valeur du MIC pour le join request lui est calculé ainsi grâce à un CMAC : $cmac = aes128cmac(AppKey,MHDR | AppNonce | NetID | DevAddr | DLSettings | RxDelay | CFList)$

    $MIC = cmac[0..3]$

    Le message de join-accept est encryptée en AES ECB :

    $aes128decrypt(AppKey, AppNonce | NetID | DevAddr | DLSettings | RxDelay | CFList | MIC)$

Le schémas ci dessous montre la procédure de Over The Air Activation (OTAA).

sequenceDiagram
    EndDevice->>+NetworkServer: Join-Request (AppEUI,DevEUI,DevNonce)
    Note over EndDevice,NetworkServer: Not secured exchange
    loop Processes the Join-request
        NetworkServer-->>NetworkServer: session key generation (AppSKey,NwkSKey)
    end
    NetworkServer->>-EndDevice: Join-accept (AppNonce, NetID, DevAddr, RxDelay, CFList)
    Note over EndDevice,NetworkServer: Encrypted with AppKey
    loop Keeps NwkSKey
        NetworkServer->>ApplicationServer: AppSKey distribution
    end
    loop 
        EndDevice->>EndDevice: Session key generation (AppSKey, NwkSKey)
    end

Activation by Personalization (ABP)

Dans ce cas les clefs de sessions sont hard codé. Cette méthode est moins sécuritaire.

Référence

https://lora-alliance.org/about-lorawan/ https://eduscol.education.fr/sti/sites/eduscol.education.fr.sti/files/ressources/pedagogiques/10864/10864-caracterisation-interface-radio-lor-vf.pdf https://www.youtube.com/watch?v=j0ONEdkOm28