Modes d'activation

Aperçu

En fonction du niveau de sécurité que vous souhaitez attribuer à votre réseau IoT, vous pouvez choisir parmi trois types d'activation des capteurs. Le niveau de sécurité est défini par la façon dont les clés racine et les clés de session MAC sont générées, échangées et stockées pour vos capteurs finaux.

Les modes d'activation sont énumérés ci-dessous du plus sécurisé au moins sécurisé :

1. Activation Over-the-Air (OTAA) avec Join Server externe : le mode d'activation le plus sécurisé.

   • Les clés racine du capteur sont pré-configurées en toute sécurité par le fabricant dans un Join Server externe, sans être communiquées directement au propriétaire du capteur. Dans ThingPark Activation (TPA), les clés racine sont stockées en toute sécurité dans un Module de sécurité matérielle (HSM) ; elles ne peuvent pas être compromises par des adversaires.
     Pour en savoir plus, voir Intégration transparente avec ThingPark Activation.
   • La procédure de Join génère des clés de session qui sont renouvelées à chaque cycle de Join, ainsi le capteur n'utilise pas les mêmes clés de session pendant toute sa durée de vie.

2. Activation Over-the-Air (OTAA) avec Join Server local :

   • Les clés racine du capteur sont fournies directement au propriétaire du capteur.Cette activation est moins sécurisée que l'utilisation d'un Join Server externe, car les clés racine peuvent être exposées à des tiers ou perdues par le propriétaire du capteur.
   • La procédure de Join génère des clés de session qui sont renouvelées à chaque cycle de Join, ainsi le capteur n'utilise pas les mêmes clés de session pendant toute sa durée de vie.

3. Activation par personnalisation :

   • Le capteur n'inclut pas de clés racine et ne contient que des clés de session permanentes qui ne peuvent pas être renouvelées.
   • Il s'agit du mode d'activation le moins sécurisé.

astuce

Pour les capteurs déjà provisionnés, le mode d'activation est affiché dans la page de détails de chaque capteur sur l'interface utilisateur.

Intégration transparente avec ThingPark Activation

ThingPark Activation (TPA) est un service géré par Actility offrant une activation sécurisée aux capteurs OTA LoRaWAN® via un serveur de Join sécurisé (JS). Toutes les clés LoRaWAN® sont sécurisées par un Module de sécurité matérielle (HSM) intégré au service TPA.

Un processus typique d'activation de capteur OTA consiste en les étapes suivantes :

Étape	Description
#1 - Pré-commissionnement	Le fabricant du capteur importe les informations du capteur (DevEUI, JoinEUI, AppKey, NwkKey (pour les capteurs LoRaWAN® 1.1)) dans TPA. Lors du pré-commissionnement réussi, le fabricant du capteur obtient un jeton de propriété de TPA pour agir comme preuve de possession de ce DevEUI. Le fabricant de capteurs doit communiquer ce Owner-token à l'acheteur/propriétaire du capteur ; par exemple, en l'incluant dans le code QR standard spécifié par la LoRa Alliance. À ce stade, le capteur est dit "générique", ce qui signifie qu'il n'est pas encore personnalisé pour (ni associé à) un Network Server LoRaWAN® (NS).
#2 - Mise en service	Lorsqu'un abonné ThingPark Enterprise achète ce capteur générique, il doit simplement provisionner le capteur sur son abonnement ThingPark, en fournissant le DevEUI, le JoinEUI, l'Owner-token et en sélectionnant l'option « External Join Server ». De cette façon, la procédure de revendication est automatiquement gérée par ThingPark auprès de l'application Key Manager de ThingPark Activation sans que l'utilisateur ait à se connecter à TPA et à revendiquer manuellement le capteur. À la fin de l'étape de mise en service, le Join Server de TPA est prêt à traiter les Join Requests transférées par le Network Server (NS) d'origine pour ce capteur.
#3 - Activation	Lorsqu'un capteur OTA mis en service est mis sous tension, il envoie un message Join Request qui est routé vers le Join Server compétent (JS), identifié par son JoinEUI. Le JS traite la requête et génère un Join Answer. À la fin de cette étape d'activation par voie aérienne, le capteur doit générer ses clés de session MAC et maintenir une session LoRaWAN® sécurisée avec le réseau.

Ce processus en trois étapes est illustré par le schéma suivant :

Le diagramme suivant montre les différents états d'un capteur OTA pendant son cycle de vie, tel que spécifié par LoRaWAN® Backend Interfaces :

Sur l'interface utilisateur ThingPark Enterprise, le gestionnaire de capteurs doit provisionner le capteur avec l'option Mode d'activation = "Over-the-Air Activation (OTAA) with external Join Server" et définir l'Owner-token, comme dans cet exemple :

Une fois le capteur provisionné, la procédure de revendication est automatiquement déclenchée par ThingPark Enterprise vers TPA, sur la base de l'Owner-token fourni par l'utilisateur.

Si la procédure de revendication échoue pour quelque raison que ce soit (par exemple, le capteur n'a pas été pré-commissionné sur TPA, le capteur est déjà revendiqué, l'Owner-token est invalide...), la création du capteur échouera avec l'erreur suivante :

Cette procédure de revendication automatique s'applique aussi bien aux cas d'utilisation de création de capteur unitaire qu'aux importations en masse.

Lorsque le capteur est supprimé de ThingPark Enterprise, une requête de dé-revendication est automatiquement déclenchée vers le Key Manager de TPA si le capteur était déjà mis en service sur TPA.

Codes QR d'activation

Pour qu'un capteur LoRaWAN® soit activé sur un réseau donné, plusieurs attributs spécifiques au capteur doivent être provisionnés sur le Network Server.

Ces attributs incluent des éléments obligatoires, tels que l'identifiant du capteur (DevEUI), l'identifiant du Join Server (JoinEUI) et le profil du capteur, et des éléments optionnels, tels que le numéro de série, l'Owner-token et des attributs spécifiques au fournisseur.
Historiquement, ces attributs ont été soit (partiellement) imprimés sur le capteur pour que l'utilisateur puisse les lire et les saisir manuellement, soit transmis à l'utilisateur par e-mail pour qu'il/elle les copie-colle. Dans les deux cas, la procédure a été laborieuse et sujette aux erreurs.

Pour des raisons de confidentialité, la clé racine du capteur (AppKey) ne doit jamais être incluse dans le code QR. Par conséquent, pour maximiser l'efficacité de l'utilisation des codes QR et empêcher les échanges hors bande entre le fabricant et le propriétaire du capteur (entraînant une livraison non sécurisée de l'AppKey), il est fortement recommandé de s'appuyer sur le mode Join Server externe pour activer les capteurs OTAA. Avec ce mode d'activation, l'Owner Token peut être présent en toute sécurité dans le code QR.

Afin de faciliter le provisioning des capteurs pour une expérience utilisateur sans intervention (zero-touch), la LoRa Alliance a défini un encodage QR standard pour les attributs des capteurs. Les codes QR générés conformément à la norme peuvent intégrer toutes les informations susmentionnées de manière à pouvoir être placés sur le boîtier du capteur et lus à l'aide d'une application de lecture de QR. Un provisioning des capteurs simplifié et fiable est l'un des avantages de l'utilisation de cette nouvelle norme.

The following image shows an example of a standard QR code, together with the format of the underlying onboarding tag:

Pour des informations détaillées sur la spécification technique de la LoRa-Alliance, voir TR005-LoRaWAN-Device-Identification-QR-codes.