Passer au contenu principal

Interface de tunnel LoRaWAN®

Interface de tunnel LRC vers serveur d'application​

Cette section décrit les rapports générés par le LRC vers un serveur d'application.

Contrat OpenAPI​

Un OpenAPI contrat est disponible pour cette API :

Aperçu​

Le but de ce rapport est de tunneliser un paquet Uplink reçu d'un capteur.

Un paquet Uplink est rapporté au serveur d'application s’il satisfait au moins une des conditions suivantes :

  • Le paquet Uplink contient un payload applicatif (FPort > 0) plus grand que la valeur DummyPayloadMaxSize configurée dans le profil du capteur

  • Si le capteur implémente LoRaWAN® 1.0 : le bit ACK est réglé dans le paquet Uplink

  • Si le capteur implémente LoRaWAN® 1.1 : le bit ACK est réglé dans le paquet Uplink et acquitte un AFCntDn

  • L'état de la Classe B du capteur a été basculé avec succès par le paquet Uplink (le bit Class B du champ FCtrl inclus dans le paquet Uplink a activé ou désactivé l'état Class B du capteur)

Si aucune des conditions ci-dessus n'est remplie, le paquet Uplink n'est pas rapporté au serveur d'application.

Le document XML ou JSON envoyé au serveur d'application inclut les métadonnées RF correspondant à un maximum de 10 passerelles recevant le mieux.

Chiffrement de Payload​

Le payload peut être fourni au serveur d'application soit chiffré, soit déchiffré.

Les règles suivantes s'appliquent à chaque type de capteur.

Activation de capteurChiffrement de Payload
Capteur ABP
Payloads chiffrés par radio		La AppSKey a été provisionnée dans ThingPark. Par conséquent, le payload est fourni déchiffré à l'AS.
Capteur ABP
Payloads chiffrés de bout en bout		La AppSKey n'a pas été provisionnée dans ThingPark. Par conséquent, le payload est fourni chiffré à l'AS. L'AS doit être provisionné avec la AppSKey pour déchiffrer le payload.
Capteur OTAA
Payloads chiffrés par radio		La AppKey a été provisionnée dans le serveur Join local de ThingPark ou le serveur Join externe a fourni la AppSKey lors de la procédure de Join. Par conséquent, le payload est fourni déchiffré à l'AS.
Capteur OTAA
Payloads chiffrés de bout en bout		La AppKey n'a pas été provisionnée dans le serveur Join local de ThingPark ou le serveur Join externe n'a pas fourni la AppSKey lors de la procédure de Join. Par conséquent, le payload et la AppSKey sont fournis chiffrés à l'AS. Pour plus de détails, veuillez-vous référer à Chiffrement de payload de bout en bout pour les capteurs OTAA avec le module de sécurité matérielle (HSM).

Aperçu​

Le principal objectif de ce rapport est de donner le statut de transmission RF effective d'une trame Downlink initiée par un serveur d'applications. Le statut de transmission RF des trames Downlink initiées par le LRC lui-même ne sont pas rapportées au serveur d'applications.

La transmission RF effective assure uniquement que la trame Downlink a bien été transmise par une passerelle LRR. Il ne garantit pas que le capteur l'ait reçu. Les rapports qui nécessitent des rapports de livraison de bout en bout doivent être envoyés en mode Confirmé, ou utiliser un mécanisme au niveau de l'application.

Notez qu’aucun rapport de trame Downlink envoyée n'est généré pour une trame Downlink ciblant un groupe multicast. Dans ce cas, un rapport récapitulatif multicast est envoyé.

Rapport récapitulatif multicast​

Aperçu​

Le but du rapport récapitulatif multicast est le même que le rapport de trame Downlink envoyée, mais pour les groupes multicast.

Le principal objectif de ce rapport est de donner le statut de transmission RF effective d'une trame Downlink initiée par un serveur d'applications. Le statut de transmission RF des trames Downlink initiées par le LRC lui-même ne sont pas rapportées au serveur d'applications.

La transmission RF effective assure uniquement que la trame Downlink a bien été transmise par une passerelle LRR. Il ne garantit pas que le capteur l'ait reçu.

Un rapport est envoyé après chaque tentative de transmission de la trame. Le nombre total de tentatives dépend du profil de service associé au groupe multicast.

Rapport de localisation​

Aperçu​

Le but du rapport de localisation est d'informer, de manière asynchrone, sur les données de géolocalisation associées à la trame Uplink actuelle (actuel FCntUp), dès qu'elles sont disponibles depuis le serveur de localisation.

Le message de localisation n'est rapporté que si la géolocalisation du réseau est activée pour le capteur, et si une nouvelle géolocalisation a été résolue.

Rapport de notification​

Aperçu​

Le but du rapport de notification est de signaler les événements suivants :

  • Réinitialisation de capteur : Une réinitialisation de capteur a été détectée par le LRC. Une réinitialisation de capteur est détectée dans les cas suivants :

    • Réinitialisation d'un contexte de capteur dans l'interface utilisateur ThingPark

      • LoRaWAN® 1.0 : Le rapport de notification est déclenché par la réinitialisation et contient un horodatage LRC Le FCntDn est réinitialisé à 0 dans ce rapport.

      • LoRaWAN® 1.1 : Le rapport de notification est déclenché par la réinitialisation et contient un horodatage LRC Le AFCntDn est réinitialisé à 0 dans ce rapport.

    • Détection d'une réinitialisation de capteur ABP dans une trame Uplink

      • LoRaWAN® 1.0 lorsque la réinitialisation automatique ABP est autorisée : Le rapport de notification est déclenché par la trame Uplink pour laquelle la réinitialisation FCntUp a été détectée et contient l'horodatage LRR de cette trame Uplink Le FCntDn est réinitialisé à 0 dans ce rapport.

      • LoRaWAN® 1.1 : Le rapport de notification est déclenché par la trame Uplink contenant la commande MAC ResetInd et contient l'horodatage LRR de cette trame Uplink Le AFCntDn n'est PAS réinitialisé à 0 dans ce rapport.

  • Procédure de Join réussie : Après l'envoi du message Join-accept, la nouvelle AppSKey est rapportée au serveur d'application. Une procédure de Join réussie est détectée dans les cas suivants :

    • Procédure Join réussie lors de la première Join-request

      • LoRaWAN® 1.0 : Le rapport de notification est déclenché par la Join-request et contient l'horodatage LRR de cette Join-request Le FCntDn est réinitialisé à 0 dans ce rapport.

      • LoRaWAN® 1.1 : Le rapport de notification est déclenché par la trame Uplink contenant la commande MAC ReKeyInd et contient l'horodatage LRR de cette trame Uplink Le AFCntDn est réinitialisé à 0 dans ce rapport.

    • Procédure de Join réussie sur les Join-request suivantes

      • LoRaWAN® 1.0 avec DevNonce basé sur le compteur : Le rapport de notification est déclenché par la Join-request et contient l'horodatage LRR de cette Join-request Le FCntDn est réinitialisé à 0 dans ce rapport.

      • LoRaWAN® 1.0 sans DevNonce basé sur le compteur : Le rapport de notification est déclenché par la prochaine trame Uplink validant la procédure de Join et contient l'horodatage LRR de cette trame Uplink Le FCntDn est réinitialisé à 0 dans ce rapport.

      • LoRaWAN® 1.1 : Le rapport de notification est déclenché par la trame Uplink contenant la commande MAC ReKeyInd et contient l'horodatage LRR de cette trame Uplink Le AFCntDn est réinitialisé à 0 dans ce rapport.

  • Battery et Margin : Le LRC a reçu une commande MAC DevStatusAns incluant les informations Battery et Margin. Le rapport de notification n'est déclenché que lorsque la trame Uplink contenant la commande MAC DevStatusAns ne contient pas de payload applicatif. Lorsque la trame Uplink contient un payload applicatif, les informations Battery et Margin sont incluses dans le rapport de trame Uplink.

En-têtes personnalisés (Kafka uniquement)​

Les en-têtes Kafka personnalisés suivants sont fournis au serveur d'application lors de la transmission d'un rapport de notification.

Interface de tunnel serveur d'application vers LRC​

Cette section décrit comment les Downlinks sont envoyés de l'AS à un capteur.

Notes importantes

  • Pour les capteurs de Classe A, le LRC met en file d'attente jusqu'à cinq trames Downlink pour chaque capteur. L'AS peut décider de vider la file d'attente des Downlinks, en utilisant le champ FlushDownlinkQueue dans les paramètres de la requête de trame Downlink. De plus, lorsque la file d'attente Downlink contient des payloads chiffrés par AS, elle est automatiquement vidée lorsqu'un capteur OTAA rejoint ou qu'une réinitialisation de capteur ABP (automatique ou administrative) est détectée. Ceci est nécessaire car les payloads chiffrés ne sont plus valides à ce stade : La AppSKey est renouvelée pour les capteurs OTAA et la séquence FCntDn est réinitialisée.

  • Pour les capteurs de Classe B, le LRC transmet les trames Downlink au meilleur LRR Downlink avec les créneaux de ping disponibles pour ce capteur dans la période de beacon actuelle et suivante, afin que le meilleur LRR puisse avoir suffisamment d'occasions de programmation pour retenter la retransmission de la trame Downlink en fonction de son contexte local (LBT, modem occupé ...etc). Pour garantir la livraison dans l'ordre1 des trames Downlink, l'AS doit mettre en œuvre un mécanisme de contrôle de flux pour envoyer les trames Downlink une par une comme suit :

    • Envoyer une trame Downlink (FCntDn X)

    • Attendre le rapport de trame Downlink envoyée

      • Si SUCCÈS : envoyer la trame Downlink suivante (FCntDn X+1)

      • En cas d'échec : il appartient à l'AS de décider si une retransmission est nécessaire.

  • Pour les capteurs de Classe C, comme pour la Classe B, le LRC transmet immédiatement les trames Downlink au meilleur LRR Downlink sans aucune mise en file d'attente. En cas de problèmes de transmission (congestion des ressources due à l'activité du modem), le meilleur LRR peut réessayer de manière autonome la transmission du paquet pendant jusqu'à 60s. Pour garantir la livraison dans l'ordre des trames Downlink pour les capteurs de Classe C, l'AS doit mettre en œuvre un mécanisme de contrôle de flux pour envoyer les trames Downlink une par une comme suit :

    • Envoyer une trame Downlink (FCntDn X)

    • Attendre le rapport de trame Downlink envoyée

      • Si SUCCÈS : envoyer la trame Downlink suivante (FCntDn X+1)

      • En cas d'échec : il appartient à l'AS de décider si une retransmission est nécessaire.

Contrat OpenAPI​

Un OpenAPI contrat est disponible pour cette API :

Chiffrement de Payload​

En fonction du provisionnement du capteur, le chiffrement et le déchiffrement peuvent être effectués par le LRC.

note

Les règles suivantes s'appliquent à chaque type de capteur.

Les règles suivantes s'appliquent à chaque type de capteur.

Activation de capteurChiffrement de Payload
Capteur ABP
Payloads chiffrés par radio		La AppSKey a été provisionnée dans ThingPark. Par conséquent, la payload doit être fournie déchiffrée par l'AS.
Capteur ABP
Payloads chiffrés de bout en bout		La AppSKey n'a pas été provisionnée dans ThingPark. Par conséquent, la payload doit être fournie chiffrée par l'AS accompagnée du FCntDn. L'AS doit être approvisionné avec l'AppSKey pour chiffrer la payload.
Capteur OTAA
Payloads chiffrés par radio		La AppKey a été provisionnée dans le serveur Join local de ThingPark ou le serveur Join externe a fourni la AppSKey lors de la procédure de Join. Par conséquent, la payload doit être fournie déchiffrée par l'AS.
Capteur OTAA
Payloads chiffrés de bout en bout		La AppKey n'a pas été provisionnée dans le serveur Join local de ThingPark ou le serveur Join externe n'a pas fourni la AppSKey lors de la procédure de Join. Par conséquent, la payload doit être fournie chiffrée par l'AS accompagnée du FCntDn. Pour plus de détails, veuillez-vous référer à Chiffrement de payload de bout en bout pour les capteurs OTAA avec le module de sécurité matérielle (HSM).

Le format de message HTTP/POST suivant est utilisé pour tunneliser la payload de la trame radio et les métadonnées associées du serveur d'application cible vers le LRC. Le serveur d'application agit comme un client HTTP et le proxy HTTP inversé (serveur PROXY_HTTP) agit comme un serveur HTTP. Le réacheminement de la requête HTTP vers le LRC principal ou le LRC de secours est géré par le proxy HTTP inversé.

Le code d'intégrité du message MAC LoRaWAN® (MIC) est toujours calculé par le LRC, dans le cadre du formatage de la trame MAC. La MAC payload peut être chiffrée soit par l'application soit par le LRC (voir le tableau ci‑dessus).

Cette commande POST peut être générée facilement par des outils comme curl ou POSTman :

curl -H "Content-type:application/x-www-form-urlencoded" -X POST "https://api.thingpark.com/thingpark/lrc/rest/downlink?DevEUI=000000000F1D8693&FPort=1&Payload=0102030405060708090A&FCntDn=1234"

Les messages de downlink non confirmés ne sont pas acquittés au niveau LoRaWAN®. Par conséquent, le réseau et le serveur d'application en mode tunnel ne savent pas si les messages ont été reçus ou non.

Les messages de downlink confirmés sont acquittés par le capteur cible, mais la section 4.3.1.2 Message acknowledge bit and acknowledgement procedure (ACK dans FCtrl) de la Spécification LoRaWAN® laisse le capteur libre d'envoyer des ACK retardés. Par conséquent, il n'est pas possible de laisser le réseau gérer les retransmissions.

Lorsque le LRC reçoit un message uplink éventuellement vide (sans payload) avec le bit ACK activé dans le champ FCtrl, le LRC ajoutera un indicateur ACKbit dans les métadonnées XML de la trame uplink envoyée au serveur d'application. La politique de retransmission dépend du serveur d'application.

Au niveau PHY, le support multicast dans les classes B et C de LoRaWAN® revient à avoir plusieurs capteurs finaux à l'écoute de la même adresse réseau. Ceci est déjà supporté dans ThingPark Wireless pour les classes B et C. Un serveur d'application doit simplement envoyer un message de downlink non confirmé à l'adresse de groupe cible (configurée comme un capteur fictif).

Cependant, la feuille de route LoRaWAN® inclut des travaux futurs sur le multicast, notamment la gestion de l'appartenance aux groupes et les procédures de gestion des clés, ainsi que la transmission fragmentée de payloads volumineux, comme les mises à jour du firmware. Actility l'implémentera dans ThingPark Wireless une fois que la spécification multicast de LoRaWAN® sera publiée.

Chiffrement de payload de bout en bout pour les capteurs OTAA avec le Hardware Security Module (HSM)​

Cette section décrit les détails d'implémentation nécessaires côté serveur d'application pour supporter le chiffrement de payload de bout en bout pour les capteurs OTAA. Elle fournit des recommandations et des exemples pour les développeurs d'application en vue de concevoir du code du côté du serveur d'application.

Pour garantir la confidentialité des données de bout en bout entre le capteur et l'AS, le mode de chiffrement de payload de bout en bout permet l'échange de la payload applicative uplink/downlink entre le LRC et l'AS au format chiffré. Dans ce mode, la payload applicative est chiffrée via l'AppSKey ; cette clé n'est connue que de l'AS (pas du LRC) et, par conséquent, la payload ne peut pas être déchiffrée par le fournisseur de services.

note

En mode de chiffrement de payload de bout en bout, l'AppSKey est partagé de manière sécurisée avec l'AS (via le network server). Autrement dit, l'AppSKey est chiffrée par la clé de transport de l'AS ; par conséquent, l'AS doit stocker cette clé de transport et gérer le déchiffrement de l'AppSKey envoyé par le NS afin de pouvoir déchiffrer (respectivement chiffrer) la payload applicative en uplink (respectivement en downlink).

Pour fonctionner correctement avec le mode de chiffrement de payload de bout en bout, le serveur d'application doit implémenter les exigences suivantes :

  1. Provisionnement/la gestion de la clé de transport AS dans le compte de l'abonné du serveur d'application

  2. Supporter la réception de l'AppSKey chiffrée et la déchiffrer en utilisant la clé de transport de l'AS

  3. Stockage sécurisé de l'AppSKey décryptée pour chaque abonné

  4. Décryptage des données Uplink à l'aide de l'AppSKey

  5. Cryptage des données Downlink à l'aide de l'AppSKey avant de les envoyer au réseau principal

L'AppSKey présente dans les métadonnées correspond à la clé de la session LoRaWAN® courante du capteur ; elle est donc toujours synchronisée avec l'AppSKey utilisée par le capteur pour chiffrer/déchiffrer la payload de données. Lorsque le capteur traverse une nouvelle procédure de Join, le nouvel AppSKey (correspondant à la nouvelle session) doit être transmis par le LRC à l'AS une fois que les nouvelles clés de session sont validées par une trame Uplink valide (comme spécifié par la section 6.2.4 de la spécification LoRaWAN® 1.0.2).

note

En mode de chiffrement du payload radio, la payload applicative est échangée en clair entre le LRC et l'AS ; néanmoins, elle est protégée par TLS sur l'interface tunnel. Dans ce mode, l'AppSKey n'est PAS envoyé du LRC à l'AS via l'interface de tunnel (le champ AppSKey est vide dans le rapport de trame Uplink).

Provisionnement de la clé de transport AS​

La clé de transport AS ne peut pas être accessible à ThingPark car elle sécurise le transfert de l'AppSKey entre HSM et AS. Pour permettre une échange sécurisé de la clé de transport AS entre HSM et AS, une cryptographie asymétrique est utilisée.

ThingPark permet à l'administrateur d'AS de provisionner sa clé publique RSA. Le bouton de génération de clé de transport AS permet aux administrateurs AS de demander une nouvelle clé de transport AS à HSM, comme illustré dans la figure suivante.

Provisionnement de clé de transport AS

Cette clé sera renvoyée à l'administrateur AS chiffrée par la clé publique précédemment configurée, seul l'administrateur AS pourra donc la décoder. De plus, la clé de transport AS est renvoyée au LRC, chiffrée par HSM, de sorte que seul HSM peut la déchiffrer. Cela est nécessaire car le HSM est sans état et donc la fonction JS doit transmettre la clé de transport AS chiffrée au HSM chaque fois que nécessaire.

Afin de générer et de récupérer de manière sécurisée la clé de transport AS à partir de HSM, l'abonné utilise une paire de clés RSA asymétriques.

Génération de paires de clés RSA​

Dans une session shell, l'abonné génère une paire de clés RSA asymétriques en utilisant les deux commandes suivantes :

  • Pour générer la clé privée RSA (private.key) :
openssl genrsa -des3 -out private.key 2048
  • Pour générer la clé publique RSA (public.pem) :
openssl rsa -in private.key -outform PEM -pubout -out public.pem

Récupération de la clé de transport AS​

L'interface utilisateur ThingPark permet à l'abonné de générer la clé de transport AS.

L'abonné fournit la clé publique RSA au format PEM. Le HSM génère une clé de transport AS aléatoire et la retourne chiffrée avec la clé publique RSA. la clé de transport AS chiffrée est encodée en base64.

Cette clé de transport AS chiffrée est prête à être copiée, déchiffrée et provisionnée dans le Serveur d'Application. L'étiquette générée sera utilisée pour identifier la clé de transport AS à utiliser lors de la réception d'une trame Uplink.

Cette clé de transport AS chiffrée n'est pas sauvegardée dans ThingPark. Si elle est perdue par l'abonné, une nouvelle clé de transport AS devra être générée.

La clé de transport AS chiffrée peut être stockée au format ASCII dans un fichier texte (par exemple encryptedASTransportKey.txt) et déchiffrée comme suit :

cat encryptedASTransportKey.txt | base64 -d | openssl rsautl -decrypt -inkey private.key | xxd -p

Exemple de déchiffrement de la clé de transport AS chiffrée​

ParamètreValeur
Clé de transport AS chiffrée (encodée en base64)k13rCYqFTIui/JfEh7sTR6ejA0p3cj8GzBIm3nQM8VZ42EsCZT/9w9a8yrjllqsr
Y7WHzNGBvPAXccqAyMaqyFmI3MczU1/PfiOKZ0FL487Z/cPucGTiS2ThsG7t0UEz
zSuLfqzy3ieI0nz+YEgGLwB2DdRJS2fNgZYQmvyaIbFcdDfv6g3iY1OLP2ffOKCh
MaBWJEQWyZ1cgQd95GNhBBv6XXNVISRibjyx/szFEFP1kcZkYJJ22goOTvvbDt8Q
fG1Md/7dOc9g1StpfW5dIFP+jL8W4PCOyR6JFREGTJjUI7SHKiliq73FT+QTb4Ih
ZUjqQA2x7WfhjLXfBlOxKQ==
Clé de transport AS déchiffrée (encodée en hexadécimal)65e040875cb38ad99681379df656306b
Clé RSA publique-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0/L/n52Fvlf2A9IFvRG1
kT9VNN5XSDyMlWkwrZMiQthHgues09YFo9yyNz3n+WI7laJz3LZfbZAX3ljNq1Dm
CLnW64e+4nSc6Qw/aLgvFKZPZ4R3SezHkV5bSsD87Bpx8eDti8w77ovfx/Or27Jw
WY1YLixbAJ8pP7MT9W70tEMYhfcLYzCX0kFi3eDbsvzz5H+tA0b/DXrtAfjw7Smy
IfeNi/GYrFKQEkrj9co67BWaT9RH9mLIVnuyDpsUMpdriGbc8UJ2/2ZSAL11lI8D
54UZUPJugIOc51BLDVQRVN6h8Mu1rCUo2QD95kd6mgCdZCuZVo3vpmzBTQDrSnr2
mQIDAQAB
-----END PUBLIC KEY-----
Clé RSA Privée-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEA0/L/n52Fvlf2A9IFvRG1kT9VNN5XSDyMlWkwrZMiQthHgues
09YFo9yyNz3n+WI7laJz3LZfbZAX3ljNq1DmCLnW64e+4nSc6Qw/aLgvFKZPZ4R3
SezHkV5bSsD87Bpx8eDti8w77ovfx/Or27JwWY1YLixbAJ8pP7MT9W70tEMYhfcL
YzCX0kFi3eDbsvzz5H+tA0b/DXrtAfjw7SmyIfeNi/GYrFKQEkrj9co67BWaT9RH
9mLIVnuyDpsUMpdriGbc8UJ2/2ZSAL11lI8D54UZUPJugIOc51BLDVQRVN6h8Mu1
rCUo2QD95kd6mgCdZCuZVo3vpmzBTQDrSnr2mQIDAQABAoIBABzJQyill1Wb0sEA
FGFyd0uL44GztP0NpDZivAbHFf8oKsY/uvxmdAumXNod4VTAn8EZ+EyAxIM379X2
D7D14thKjUMeA7H0Dp+kVzRc16AhWmV/20fCDfTTcOi9P1y91r34Q6saCQXEH5ej
o7LKEHJJPTHAOnfiJhMNumc6M6gLuU88J8UkDrWAM8ji6soMY67VmzAjanpxaSjA
2NBBNJ1Yjh6X/8Pp53qxwrTZRThSrjJAO/vANMy5VsnHqPAXM5Jg7BGJGp24IgPF
4L/2MnWRApCSNNK+MM88AaDOeYBwMvL9rRFGU87gwCP2Tqhy5jryw/Z0QtSbQ2ij
meePpQECgYEA/wjkC9qO3libaTjgVlQyJXGO7qNzgBhI5nwvVStsGgl/k/rZ+4zf
19d5LHRAhh6llQpYvKwIT/QPk6Jdyh/8tIBCurTuYAlwFmbYFC7HhjtXRPgjgNzE
voujfkkqe9sW88NjBeJY9Sn2KgdFuAUkB8CY+HuKn+8GXD6RXAQ+PLkCgYEA1MBc
dAGpheQYO9IULId0cgi36WELpedsE4SM9t499ReZ13sdle9l96FQ21psgxY0jps0
ySfHBsgAZRWva51txYK0nX3Ievebwkpu15STGvjmPXNyiYZSp454zeSwHjxiX6en
NgQzE7Ih5Kz6nAyMUoP+VxPlOCpEmbEFNx4oWOECgYEAjo5QspOLkpui21EwjPDp
SubMB3aUBEEO1s8JwijQd0lh57yrhiG7qbHHCOM+gfm1grbS3TuoNdDtuA9lL6tr
nRWotyaVrFb6MXtxQu7XFqAq6uFtLwW4b+4sCFYriinwDXfk7RAVu4ymDd4cyX0O
I8szdonP9hAs1PkgVXgFtfkCgYAY7nHnJkq3ZgNw/y1eCoGa22qx7q1uw6/mmaHr
TB/2mM1ucv8Ekwlf+4d+LRqKQg/mpkmJSSAJq2ZgciocclZqzuZbjmHwBxQ5sH9M
xBx5DLHugZjqhNMqz4dYmXQKFwlwLDVsHxHdPQK7yYmUv+Oxx8YGbk5uRoXDfPsf
emlAAQKBgQCW4AALAsBfhd1ZGkK4S3P4vq67bNDyC8b/Yq/Q8dNIIhc3CmU7xP7Y
AQsN/VMX6h/zPnP/tuqefDqKl2m03x58ghzC4PFTNJyrDJeJaeEPazzHch7v/tgY
CwlM8IFwEeQVkcA+Q7xRuxgUsZrPZWZTvL7hsaoYAKsdhSBB/FThUA==
-----END RSA PRIVATE KEY-----

Déchiffrement AppSKey​

Déchiffrement de l'AppSKey chiffré​

L'AppSKey peut être déchiffré à l'aide d'openssl comme suit :

echo $AppSKey | xxd -r -p | openssl enc -d -aes-128-cbc -nosalt -iv 0 -K $ASTransportKey -nopad | xxd -p

Exemple de déchiffrement de l'AppSKey chiffré​

ParamètreValeur
AppSKey chiffréeDFE758AFD5FD4DD8A64BE063373AF6C8
Clé de transport AS déchiffrée98CC5DDD614FF2DF44FD09CA9F52CDBA
AppSKey déchiffréeb0ad83c614043c76c434d460b48b90b4

Détails

echo "DFE758AFD5FD4DD8A64BE063373AF6C8" | xxd -r -p

Convertit l'AppSkeyEnc en binaire

openssl enc -d -aes-128-cbc -nosalt -iv 0 -K 98CC5DDD614FF2DF44FD09CA9F52CDBA -nopad

Déchiffre l'AppSkey avec la clé de transport AS déchiffrée

| xxd -p

Affiche l'AppSKey en format hexadécimal

Déchiffrement du payload​

Déchiffrement du payload chiffré​

Processus de déchiffrement selon LoRaWAN® :

  • Déterminez le nombre de blocs de 16 octets - k

  • Créez un ou plusieurs blocs de chiffrement A1 ... Ak

Taille (octets)1414411
Ai0x014 x 0x00DirDevAddrFCntUp ou FCntDown0x00i

  • Créer la chaîne de chiffrement S1 = aes128_encrypt (AppSKey, Ai)

  • S = S1 | S2 | .. | Sk

  • Remplir la payload à 16 octets

  • XOR payload et S

  • Tronquer le XOR à la taille de la payload d'origine

Exemple de déchiffrement de payload chiffré​

ParamètreValeur
AppSKey déchiffrée2B7E151628AED2A6ABF7158809CF4F3C
Payload chiffré90ada2ccf937393e229e
DevAddr00790D93 (930D7900 en little endian)
FCntUp11 (0B000000 en little endian)
Payload déchiffrée48656c6c6f576f726c64
  • Déterminez le nombre de blocs de 16 octets - dans ce cas, nous avons un bloc de 16 octets
# export enc_payload=90ada2ccf937393e229e
# echo $((($\{#enc_payload} + 31) / 32))
1
  • Créez un ou plusieurs blocs de chiffrement A1 ... Ak
# export A1=010000000000930D79000B0000000001
  • Créer une chaîne de chiffrement
# export AppSKey=2B7E151628AED2A6ABF7158809CF4F3C
# export S=`echo $A1 | xxd -r -p | openssl enc -e -aes-128-cbc -nosalt -iv 0 -K $AppSKey -nopad | xxd -p`
# echo $S
d8c8cea09660564c4efaeaa752df7e47
  • Remplir la payload à 16 octets
# export pad=`echo $enc_payload | sed -e :a -e 's/^.\{1,31\}$/&0/;ta'`
# echo $pad
90ada2ccf937393e229e000000000000
  • XOR payload et S
# export xor=`printf '%x%x\n' "$((0x${pad:0:16} ^ 0x${S:0:16}))" "$((0x${pad:16:16} ^ 0x${S:16:16}))"`
# echo $xor
48656c6c6f576f726c64eaa752df7e47
  • Obtenir la payload déchiffrée en coupant le résultat de l'opération XOR à la taille de la payload d'origine
# echo ${xor:0:$\{#enc_payload}}
48656c6c6f576f726c64

Footnotes​

  1. La couche MAC du capteur final doit abandonner les trames Downlink reçues hors séquence. ↩

Dernière mise à jour sur
Copyright © 2025 Actility
Sur cette page