Mises à jour sans fil du micrologiciel des appareils IoT

Une mise à jour sans fil, ou OTA, installe un nouveau micrologiciel sur un appareil par son réseau radio. Un compteur ou capteur reste en service dix ans ou plus ; pendant ce temps, des défauts peuvent être découverts dans sa pile radio ou son logiciel applicatif. Pour un parc de 400 appareils sur 20 sites, un correctif posé à la main exige 20 visites. Le même correctif transmis par radio devient une campagne planifiée depuis la Gateway.

Ce guide fait partie du parcours Réseaux et architecture.

Pourquoi mettre à jour les appareils de terrain

Le cas Zigbee le mieux documenté est l'attaque publiée en 2016 par Ronen, O'Flynn, Shamir et Weingarten contre les lampes Philips Hue. Ces lampes authentifiaient leur micrologiciel avec une clé AES-CCM commune à toutes celles d'un même type. Les chercheurs ont extrait cette clé par analyse de consommation électrique avec un matériel de quelques centaines de dollars. Ils ont ainsi pu construire une image acceptée comme authentique par chaque lampe de ce type ; une faille du code Zigbee Light Link permettait ensuite à l'image malveillante de se propager de lampe en lampe. Philips a corrigé la faille de prise de contrôle et diffusé le correctif par OTA. L'extraction de la clé montre pourquoi une image doit porter une signature que l'appareil vérifie à l'aide d'une clé publique.

Les défauts ordinaires comptent autant que les attaques. Une anomalie qui corrompt un compteur d'impulsions ou fait quitter le réseau à un appareil après le redémarrage de son routeur parent doit être corrigée sur chaque unité concernée. NIST SP 800-82 Rev. 3, section 6.2.11, demande aux exploitants de technologie opérationnelle une procédure documentée de gestion des correctifs : comment connaître les correctifs, les tester, décider de leur installation et appliquer des mesures compensatoires en attendant. Le document recommande aussi de les déployer pendant des arrêts planifiés. Les étapes ci-dessous suivent ce principe.

Fonctionnement sur Zigbee

Les appareils Zigbee utilisent le cluster OTA Upgrade, identifiant 0x0019, défini au chapitre 11 de la Zigbee Cluster Library (ZCL). La Gateway sert de serveur OTA et conserve les fichiers image. L'appareil est le client OTA et conduit le téléchargement.

Chaque fichier OTA commence par l'identifiant 0x0BEEF11E et un en-tête indiquant le code fabricant, le type d'image, la version du fichier et sa taille totale. Des versions matérielles minimale et maximale peuvent également y figurer. Le serveur utilise le code fabricant et le type d’image pour sélectionner une image candidate. Vérifiez le modèle exact, la révision matérielle et le fichier approuvé par le fabricant ; la correspondance des identifiants d’en-tête ne prouve pas à elle seule la compatibilité.

L'échange suit cet ordre :

1. Le serveur peut envoyer Image Notify pour annoncer une image disponible. Il ne peut pas avertir immédiatement et de façon fiable un terminal en veille ; ces clients envoient donc périodiquement Query Next Image Request, avec code fabricant, type d’image et version actuelle.
2. Le serveur répond par Query Next Image Response, avec la version et la taille de l'image proposée.
3. Le client envoie Image Block Request avec le décalage voulu dans le fichier et la taille maximale du bloc accepté. Le serveur renvoie les données par Image Block Response. Le client répète jusqu'au fichier complet. C'est lui, et non le serveur, qui suit la progression ; le serveur conserve donc peu d'état par appareil.
4. Le client vérifie l'image et envoie Upgrade End Request avec l'état SUCCESS ou INVALID_IMAGE.
5. Le serveur répond par Upgrade End Response, qui indique l'heure d'installation. Le client passe à la nouvelle image à cet instant. La valeur 0xFFFFFFFF lui demande d'attendre une instruction ultérieure, ce qui permet de faire basculer un groupe ensemble.

La ZCL exige un chargeur d’amorçage applicatif et une mémoire supplémentaire pour l’image complète avant son activation. Le téléchargement peut ainsi se faire pendant que l’ancienne image fonctionne, sans garantie de continuité de l’application ou des transmissions. Vérifiez l’implémentation de l’appareil et la charge réseau ; le redémarrage sur la nouvelle image interrompt le service.

Durée d'une mise à jour Zigbee

La taille des blocs ralentit la transmission. Le client indique une taille maximale de données dans chaque demande. La ZCL permet au serveur de répondre avec moins, pour laisser de la place au routage lorsque plusieurs sauts séparent le client, et des serveurs courants envoient 50 octets d'image par bloc. Une image de 200 ko exige ainsi 4 000 blocs ; chaque bloc comporte une demande et une réponse traversant tous les sauts. Si l'aller-retour sur deux sauts dure un quart de seconde, le transfert prend environ 17 minutes. Cela concorde avec les 10 à 20 minutes annoncées par Edge pour une mise à jour.

Deux facteurs l'allongent. Le serveur peut limiter la cadence d'un client par l'attribut MinimumBlockPeriod, délai minimal en millisecondes entre demandes de blocs. La ZCL donne l'exemple d'un bloc toutes les 500 ms par client quand plusieurs téléchargent simultanément : les 17 minutes doublent. Un terminal en veille ne reçoit des données que lorsqu'il interroge son parent. La ZCL lui permet de demander les blocs plus lentement que ne l'autorise le serveur pour préserver sa batterie ; un capteur sur pile peut donc prendre des heures.

Signature des images

La ZCL recommande vivement une signature réalisée avec la clé privée du fabricant, que l'appareil vérifie avec la clé publique correspondante une fois le téléchargement achevé (clause 11.3.3.1). Elle ne l'impose pas : chaque norme applicative fixe son minimum. Smart Energy peut combiner signature de l'image et chiffrement réseau et APS ; d'autres normes peuvent se contenter du chiffrement réseau (clause 11.3.2). Sans signature, une empreinte de l'image (clause 11.3.3.2) prouve l'intégrité du transfert, pas l'identité du fabricant. Certains fabricants ajoutent leur propre vérification dans le chargeur d'amorçage. Demandez la méthode utilisée par l'appareil. Une clé symétrique n'est pas plus sûre que l'appareil le moins protégé qui la détient, comme l'a montré l'attaque des lampes.

Fonctionnement sur LoRaWAN

Les transmissions descendantes LoRaWAN sont courtes et limitées. La LoRa Alliance a donc conçu la mise à jour de micrologiciel sans fil, FUOTA, comme un ensemble de modules applicatifs. Le résumé du processus TR002 les assemble :

• TS003, synchronisation d'horloge applicative, donne à chaque appareil l'heure du réseau pour commencer une session multicast à l'instant convenu.
• TS005, configuration distante du multicast, attribue aux appareils une adresse et des clés multicast communes et planifie une session de classe C ou B. Un appareil limité à la classe A ne peut pas participer à une session multicast ; il reçoit les fragments uniquement en unicast, dans ses fenêtres de réception après ses propres transmissions montantes.
• TS004, transport de blocs fragmentés, découpe l'image en fragments et ajoute une correction d'erreurs sans retour. Avec 10 % de redondance, un appareil peut perdre environ 10 % des trames et reconstruire malgré tout le fichier, sans redemander les fragments absents. Une session transporte au plus 16 383 fragments.
• TS006, protocole de gestion du micrologiciel, rapporte et commande sa version sur l'appareil.

Une fois assez de fragments reçus, l'appareil reconstruit l'image, vérifie sa signature numérique avec la clé publique du serveur de mise à jour et contrôle que l'en-tête correspond à son matériel et à son micrologiciel actuel. Il marque l'image comme prête puis redémarre. Le chargeur d'amorçage l'installe dans une seconde zone ou page par page avec sauvegarde de la progression, afin qu'une coupure d'alimentation pendant l'écriture ne laisse pas l'appareil sans micrologiciel. Il s’agit du processus recommandé par TR002. Le seul transport de fragments ne prouve ni la vérification des signatures ni la reprise après coupure d’alimentation. Vérifiez ces fonctions sur l’appareil et son chargeur d’amorçage exacts.

Durée d'une mise à jour LoRaWAN

Prenons une image de 100 ko diffusée en multicast de classe C en EU868, sur la fréquence RX2 par défaut de 869,525 MHz à DR0 (SF12, 125 kHz) :

• RP002 limite la charge utile applicative à DR0 à 51 octets. La commande TS004 DataFragment en utilise 3 : il reste 48 octets d'image par trame.
• 100 ko représentent 2 084 fragments. Avec 10 % de redondance, le serveur envoie environ 2 300 trames.
• Chaque trame occupe environ 2,8 s de temps d'antenne à SF12.
• La recommandation ERC 70-03 limite la bande de 869,40 à 869,65 MHz à un cycle d'émission de 10 %. La Gateway peut émettre 360 s par heure, soit environ 129 trames horaires.

Ces trames utilisent environ 1,8 heure de temps d'antenne de la Gateway, répartie sur quelque 18 heures à la limite de cycle de 10 %. La Gateway partage ce quota avec toutes les autres transmissions descendantes du canal. À DR5 (SF7), une trame peut transporter 239 octets et la même image demande environ 460 trames de 0,39 s : environ 30 minutes avec la même limite. Mais tous les appareils du groupe doivent recevoir SF7 de façon fiable ; ceux en bord de couverture en sont souvent incapables. L'unicast vers un appareil de classe A est encore plus lent. À raison d'environ un fragment par transmission montante, un appareil qui émet toutes les 15 minutes met plus de trois semaines à recevoir les mêmes 2 300 trames.

La prise en charge varie selon les modèles. Vérifiez les modules FUOTA effectivement implémentés, la capacité à ouvrir une session de classe B ou C et l'espace flash disponible pour une seconde image.

Planifier une campagne de mise à jour

1. Inventoriez chaque appareil avec modèle, révision matérielle, code fabricant, type d'image et version actuelle du fichier.
2. Lisez les notes de version. Cherchez tout changement de valeur, d'unité, de facteur d'échelle ou de registre lu par le système. Un facteur modifié produit des relevés plausibles mais faux.
3. Demandez au fabricant si l'image est signée, si l'appareil accepte une version antérieure et si son chargeur d'amorçage conserve l'image précédente.
4. Mettez d'abord à jour un groupe pilote. Incluez la plus ancienne révision matérielle, un appareil à la limite du maillage et un appareil sur pile si le site en comporte.
5. Traitez ensuite les autres en petits groupes, par exemple cinq appareils à la fois sur une Gateway, avec un délai entre eux. Surveillez les appareils non concernés : des rapports tardifs ou absents signalent un maillage saturé ; réduisez alors la taille des groupes.
6. Après chaque appareil, relisez sa version. Sur Zigbee, il s'agit de l'attribut CurrentFileVersion du cluster OTA ou de la version transmise par le cluster Basic. Vérifiez ensuite la reprise des rapports au rythme prévu et comparez les relevés à ceux d'avant la mise à jour.

Quand une mise à jour échoue

La ZCL n'a pas de commande de retour arrière. Elle autorise le serveur à proposer un fichier de version inférieure à celle installée, mais le micrologiciel de l'appareil décide s'il l'accepte. La méthode de récupération appartient au fabricant (clause 11.18). Parmi les exemples de la norme figurent un chargeur d'amorçage qui échange la nouvelle image avec l'ancienne et une pression sur un bouton au démarrage qui rétablit la précédente. Sans l'un ni l'autre, une mauvaise image impose une visite sur site.

Des lacunes peuvent survenir pendant le téléchargement comme au redémarrage. Un index d’énergie cumulée ne peut préserver le total pendant une interruption de transmission que si la mesure continue et si l’index survit à la mise à jour sans remise à zéro ni dépassement non traité. Il ne restitue pas l’historique manquant de puissance ou de température instantanée. Le guide des données périmées explique comment afficher la lacune.

Micrologiciel des appareils et logiciel de la Gateway : deux mises à jour distinctes

La Gateway est le serveur OTA. Elle conserve les images et répond à chaque demande de bloc : une mise à jour de son logiciel qui la redémarre pendant une campagne arrête tous les transferts en cours. Terminez ou suspendez une campagne d'appareils avant d'actualiser la Gateway. Ne lancez la suivante que lorsque la Gateway mise à jour est stable et que tous les appareils transmettent de nouveau.

Mises à jour de micrologiciel avec Edge

Edge, sur la Gateway ZGW-20, conserve un catalogue d'images de micrologiciel sur la Gateway. Il accepte trois types de fichiers, de 5 Mo au plus chacun : fichiers Zigbee OTA (.ota) pour les appareils tiers, images EBL (.ebl) pour les appareils EpiSensor et images binaires (.bin) pour la carte d'E/S. Edge vérifie chaque fichier au chargement et l'affiche avec fabricant, modèle, version, taille et état de validité.

Une mise à jour peut commencer immédiatement ou à l'heure programmée, et viser un appareil ou une sélection. Pour une sélection, Edge envoie la commande à chaque appareil successivement avec un délai pouvant atteindre 60 s entre eux, afin que les transferts ne démarrent pas tous ensemble. Edge prévient qu'une mise à jour peut durer 10 à 20 minutes par appareil et que celui-ci peut redémarrer ; chaque opération apparaît comme en cours, achevée ou échouée. Edge lui-même se met à jour par son canal snap ou l'application de bureau, pas depuis ce catalogue.