Tout, tout, tout vous saurez tout sur le ZigBee

1. ZigBee, il s'appelle ZigBee

Le ZigBee est un protocole de communication sans-fil à courte portée et à faible consommation énergétique basé sur la norme IEEE 802.15.4. Il est maintenu par un consortium regroupant des entreprises, des universités et des organismes gouvernementaux connus sous le nom de ZigBee Alliance.

Cette dernière propose plusieurs versions pour le protocole ZigBee : ZigBee (2004/2006/2007), ZigBee PRO qui définit une pile et des caractéristiques supplémentaires (2007/2012), ZigBee 3.0 en cours de développement et des protocoles spécifiques tels ZigBee IP, ZigBee RF4CE, ZigBee Green Power.

La communication entre les équipements ZigBee repose sur la définition de profils qui se décompose en deux types : privés et publics. Chaque profil public possède un identifiant (ID) allant de 0x0000 à 0x7FFF et 0xBF00 à 0xFFFF pour les profils privés. Ci-dessous quelques exemples de profils publics :

• ZigBee Smart Energy (SE - 0x0109) : gestion de l’énergie ;
• ZigBee Personal Home & Hospital Care (PHHC - 0x0108) : monitoring de patients, équipements de santé, fitness, etc. ;
• ZigBee Home Automation (HA - 0x0104) : contrôle de la maison, domotique ;
• etc.

L'utilisation d'un profil d'application public permet l'interopérabilité entre les produits développés par différents fournisseurs pour une application spécifique. Pour cela un jeu de fonctionnalités (messages, commandes , etc.) est proposé par l'alliance. L'utilisation d'un profil d'application privé est généralement prévue lorsqu'il n'y a pas de nécessités d'interactions avec les autres produits.

Les équipements utilisant un même profil communiquent entre eux par l'intermédiaire de clusters (entrées et sorties). Par exemple, un cluster dédié au contrôle de l'éclairage (on/off) est présent dans le profil de type Home Automation (HA) et est caractérisé par son Cluster ID. Une bibliothèque (ZCL - ZigBee Cluster Library [1]) regroupe les clusters par fonction et les profils peuvent les utiliser.

Le standard 802.15.4 sur lequel se base le protocole ZigBee définit plusieurs bandes de fréquences radio pour la communication (868 MHz, 915 MHz et 2.4GHz).

1.1 La pile

ZigBee est structuré en 4 couches dont les deux couches inférieures (PHY et MAC) sont définies par les spécifications de l’IEEE 802.15.4 et sont détaillées dans l'article sur 802.15.4 de ce même dossier :

• la couche « Network » (NWK) est responsable de la topologie maillée (mesh networking) permettant à un nœud de communiquer à un autre grâce à un routage automatique. Elle fournit des mécanismes pour joindre, quitter et former un réseau, sécuriser le routage et la transmission des trames, identifier les chemins entre les équipements connectés, découvrir le voisinage réseau, la gestion des types de services applicatifs, etc. Les paquets de la couche réseau peuvent être envoyés en unicast, broadcast ou encore multicast ;
• la couche « Application » (APL) est associée à plusieurs éléments :
• la sous-couche Application Support Sub-Layer (APS) assure l'interface entre la couche de réseau et la couche d'application à travers un ensemble de services. Elle gère le maintien des tables de routage, le transfert des messages entre les appareils reliés, le management des adresses, le mapping des adresses étendues de 64 bits en adresse de 16 bits pour la couche NWK, la fragmentation et ré-assemblage des paquets, ou encore dispose d'un mécanisme de multiplexage (cas de plusieurs applications sur la même adresse) ;
• l'Application Framework (AF) qui accueille les différents profils d’application. Elle propose également des API pour les développeurs. Chaque application dispose d'une adresse sur le nœud ZigBee comprise entre 0 et 255 ;
• le module Security Service Provider (SSP) qui s'occupe de fournir des services de sécurité aux couches NWK et APS ;
• le module ZigBee Device Object (ZDO) qui est responsable du management des équipements notamment pour la définition du rôle (coordinateur, routeur), de la découverte ou encore des services d'applications du dispositif qui seront fournis.

La figure suivante montre l’empilement de protocoles de ZigBee, réparties sur les couches précédemment décrites :

Chaque couche expose un certain nombre de services pour la couche supérieure et chaque service fournit une interface à la couche supérieure au travers d’un Service Access Point (SAP). Ces SAP offrent les API pour permettre aux couches de communiquer tout en isolant le travail interne à chacune des couches.

Identiquement à la norme 802.15.4, le protocole ZigBee prévoit deux types d’objets :

• les FFD (Full Function Device) implémentent toutes les spécifications du protocole. Ces derniers ont trois rôles possibles : coordinateurs (ZigBee Coordinator - ZC), routeurs (ZigBee Router - ZR) ou équipements finaux (ZigBee End-Device - ZED) ;
• les RFD (Reduce Function Device) sont des équipements allégés qui sont peu gourmands tant au niveau énergétique que sur l'utilisation mémoire du microcontrôleur. Les équipements RFD sont donc des équipements finaux et ne peuvent être des coordinateurs ou routeurs.

La couche réseau ZigBee supporte 3 topologies différentes :

• topologie en étoile : le coordinateur contrôle les équipements (nœuds) qui ne communiquent qu'avec lui ;
• topologie maillée : aussi référencé comme réseau pair-à-pair, il est composé de routeurs et terminaux ZigBee. Chaque routeur est généralement connecté par plusieurs chemins et achemine les paquets de données de ses voisins (multi-sauts, meilleur chemin, tolérance aux pannes et aux interférences) ;
• topologie en arbre : dans les réseaux en arbre, les routeurs transmettent les données et contrôlent les messages en utilisant un routage hiérarchique, ils utilisent de plus une communication de type annonce (beacons). Ce type de topologie permet des réseaux très étendus 255 clusters comprenant chacun 254 nœuds soit : 64770 nœuds.

1.3 Création d'un réseau

Dans un premier temps, le coordinateur cherche un canal utilisable qui n'interférera pas avec les fréquences en cours d'utilisation puis il envoie en broadcast via un message d'annonce (beacon) le numéro de PAN-ID choisi sur le canal sélectionné (la spécification précise une plage entre 0x0000 à 0x3FFF pour l'adresse du PAN-ID). Ce dernier doit être unique par canal pour les réseaux non capables de changements de canaux dynamiques (ZigBee 2006) et unique sur tous les canaux (ZigBee 2007, ZigBee PRO). Le coordinateur doit également inclure dans sa requête un numéro de PAN-ID étendu (EPID sur 8 octets) en supplément à l'ID-PAN afin de faciliter la sélection d'un réseau spécifique pour les nœuds qui vont s'y joindre.

1.4 Joindre un réseau

Les équipements qui ne sont pas associés doivent capturer un message d'annonce ou localiser un réseau ZigBee en envoyant une requête 802.15.4 sur plusieurs canaux radio. Si le coordinateur est bien accessible sur l'un des canaux scannés par l'équipement, il répond en broadcast le numéro du PAN-ID utilisé, l'adresse du coordinateur et optionnellement son PAN-ID étendu.

Après avoir récupéré ces informations, l'équipement souhaitant se joindre au réseau ZigBee effectue une demande d'association dont voici le détail :

Les équipements ayant perdu la connexion au réseau pourront le joindre à nouveau via l'utilisation d'un paquet spécifique sur la couche NWK.

Nous recommandons aux lecteurs curieux et souhaitant avoir plus de détails sur le protocole ZigBee à se référer à la spécification [3].

2. La sécurité dans ton ZigBee

Le niveau de sécurité offert par l'architecture de sécurité ZigBee dépend de la protection des clés symétriques, des mécanismes de protection utilisés, ainsi que de la bonne mise en œuvre des mécanismes cryptographiques et des politiques de sécurité.

ZigBee utilise certains éléments de sécurité de la norme 802.15.4 qui sont détaillées dans l'article précédent. Il étend les fonctionnalités de cette norme en utilisant :

• des clés de chiffrement AES d'une taille de 128 bits ;
• définition de différentes clés pour sécuriser les communications : Master, Link, Network ;
• utilisation de l'algorithme CCM* ;
• utilisation d'un Trust Center (TC) ;
• sécurité qui peut être personnalisée par application.

Bien que plusieurs protections de sécurité soient présentes sur la couche MAC de la norme 802.15.4, le protocole ZigBee intègre également les différentes sécurité dans les couches NWK et APS :

Cependant, la spécification indique que les sécurités de la couche MAC doivent être désactivées pour certains paquets : « Route Request », « Route Reply », « Network Status », « Route Record », « Link Status », « Network Report » et « Network Update ». De ce fait, les constructeurs désactivent souvent l'intégralité des sécurités sur cette couche.

2.1 Couche réseau (NWK)

Les sécurités proposées sur la couche NWK sont plus ou moins copiées de la couche MAC.

Une clé AES 128 bits (Network Key) est utilisée pour chiffrer/déchiffrer les paquets. Tous les équipements qui sont autorisés à joindre le réseau doivent avoir une copie de cette clé. Un numéro de séquence (de 0 à 255 puis retour à 0 au-delà) est généralement associé à la clé afin d'en identifier l'instance. Lorsqu'une clé est mise à jour, le numéro de séquence est incrémenté.

Chaque routeur qui doit transférer un paquet chiffré doit dans un premier temps vérifier si ce paquet est valide. Pour cela, le routeur déchiffre le paquet et vérifie son intégrité. Si le paquet est bien valide, il chiffre à nouveau le paquet avant de le transmettre au prochain routeur ou à l'équipement final.

L'entête auxiliaire contient des données sur la sécurité des paquets. Ces données incluent le type de clé utilisé, le numéro de séquence (si c'est une clé réseau), l'adresse de l'équipement qui sécurise les données et le système anti-rejeu. L'AES 128 est également utilisé pour créer un hash de l'ensemble du paquet (entête et charge) qui est ajouté à la fin du message. Ce hash est utilisé comme Message Integrity Code (MIC) et permet de s'assurer que le paquet n'a pas été altéré.

Le compteur de trames (32 bits) est également inclus dans l'entête auxiliaire et permet d'éviter les attaques par rejeu. À chaque fois qu'un équipement envoie un paquet, il incrémente la valeur du compteur. Un équipement qui reçoit le paquet va vérifier si la valeur a bien été incrémentée par rapport au paquet précédent. Si ce n'est pas le cas, le paquet est rejeté. La clé réseau doit être mise à jour avant que le compteur atteigne sa valeur maximale. Quand cela se produit, le compteur est automatiquement remis à 0.

2.2 Sous-couche applicative (APS)

La sécurité de cette couche est différente de celle précédemment détaillée. En effet, tandis que sur la couche réseau le routeur peut déchiffrer et transmettre de nouveau le paquet à un autre routeur, ici la sécurité se fait de bout en bout. La clé (Link Key) est partagée uniquement entre l'équipement source et celui de destination.

La sous-couche APS fournit des primitives de sécurité qui peuvent être utilisées par les développeurs d'applications notamment pour la gestion des clés de sécurité pour le chiffrement des communications (ex : APSME-ESTABLISH-KEY, APSME-TRANSPORT-KEY, APSME-REQUEST-KEY, etc.).

2.3 Le Trust Center (ZTC ou TC)

Le ZigBee Trust Center (ZTC ou TC) est généralement le coordinateur (ZC) du réseau, mais peut également être un appareil dédié. Il est approuvé par tous les autres équipements et est responsable des sécurités suivantes:

• manager de confiance : afin d'authentifier les équipements souhaitant se joindre au réseau ;
• manager réseau : permettant de maintenir et distribuer les clés réseau ;
• manager de configuration : pour activer la sécurité de bout en bout entre les équipements.

Le Trust Center peut être configuré pour utiliser l'un des deux modes suivants :

• le mode commercial (ou haute sécurité dans ZigBee 2007) : ce dernier est utilisé pour des applications nécessitant un haut niveau de sécurité. Dans ce mode, le TC maintient la liste des équipements, des différentes clés, de la politique de mise à jour des clés réseau ainsi que celle d'accès au réseau.
• le mode résidentiel (ou standard dans ZigBee 2007) : ce dernier est utilisé pour des applications nécessitant un faible niveau de sécurité. Dans ce mode, le TC maintient la liste des clés réseau et de la politique d'accès au réseau. Cependant, il ne dispose pas de la liste des équipements et des autres clés. Par ailleurs, la clé réseau n'est jamais mise à jour dans ce mode.

2.4 Les différentes clés

3 types de clés sont utilisées par ZigBee pour assurer la sécurité des échanges :

• Link Key : clé uniquement partagée entre deux équipements permettant de protéger les trames sur la couche APS ;
• Network Key : clé utilisée pour réaliser les actions de la couche réseau (routage, requête pour joindre le réseau, etc.) et pour prévenir l'insertion illégitime d'un équipement ;
• Master Key : utilisée pour partager le secret initial entre deux équipements lorsqu'ils effectuent la procédure d'établissement de clé (SKKE) pour générer la Link Key.

Afin de distribuer les clés, plusieurs méthodes peuvent être utilisées par les constructeurs :

• pré-installation sur l'équipement ;
• transport ;
• établissement : les équipements négocient avec le centre de confiance pour établir les clés sans qu’elles soient transportées en utilisant l'une de ces trois techniques :
  • SKKE (Symmetric-Key Key Establishment) ;
  • CBKE (Certificate-based Key Establishment) ;
  • ASKE (Alpha-secure Key Establishment).

L'échange SKKE permet de générer la Link Key basée sur la Master Key. De ce fait, si la Master Key est compromise, publiquement connue ou laissée par défaut, l'établissement de la clé Link est également compromis.

Bien que ces sécurités soient suffisantes pour une protection contre différentes attaques, elles ne sont pas forcément toutes implémentées par les constructeurs ce qui engendre de multiples menaces sur les équipements utilisant ce protocole.

3. Les attaques connues

En 2009, Joshua Wright a présenté à la ToorCon 11 [4] ses résultats de recherches sur le protocole ZigBee. Il y présente plusieurs attaques ainsi que le Framework KillerBee.

En 2015, une équipe de Cognosec a présenté lors de la Black Hat un talk intitulé « The Good, the Bad and the Ugly » [5].

Dans ces derniers, différentes attaques sur le protocole ont été présentées dont voici un aperçu.

3.1 Sniffing

Une attaque de type sniffing permet la récupération passive d'informations (identifiants PAN, adresse MAC réelle du Trust Center Link Key, etc.). Aussi, en utilisant un équipement et un logiciel adapté et dans le cas où le chiffrement n'est pas utilisé, il est possible pour un attaquant de capturer le trafic en clair.

Si le trafic est chiffré, il est tout de même possible, dans plusieurs cas de figure, de récupérer les communications en clair. En effet et pour exemple, dans le cas d'une implémentation par défaut du profil ZigBee « Home Automation », il est possible de déchiffrer l'ensemble des trames réseau. Ceci est réalisable, car la Network Key utilisée pour chiffrer les communications est bien envoyée de manière chiffrée lors de l'appairage mais la clé (Trust Center Link Key) par défaut est connue « ZigBeeAlliance09 ». Voici un extrait de la documentation officielle pour un profil public de type "Home Automation" :

et la version décodée :

Ainsi, si cette clé n'a pas été explicitement modifiée lors de la conception du produit, il est possible pour un attaquant de déchiffrer l'ensemble du trafic...

Une méthode permettant de récupérer la Network Key alors que les équipements sont déjà appairés, serait de provoquer une désassociation de l'équipement lui forçant à se réassocier et de faire réémettre la clé par le routeur.

3.2 Rejeu

L'attaque précédente permet de récupérer l'ensemble du trafic chiffré ou non et si souhaité d'enregistrer dans un fichier spécifique cette capture ZigBee. Le rejeu consiste simplement à émettre de nouveau le trafic capturé. Prenons l'exemple d'un thermostat connecté. En utilisant une application mobile, il est possible d'envoyer une commande spécifique au thermostat (pour exemple, récupérer la température et le taux d'humidité dans la pièce). La partie routeur du thermostat (souvent un équipement séparé) se chargera de réceptionner la commande envoyée via l'application mobile (borne Wifi -> routeur du thermostat), de transformer la requête et de la transmettre via une communication ZigBee au thermostat. Ce dernier renvoi alors les éléments demandés au routeur qui se chargera de renvoyer l'information à l'application mobile en utilisant la borne Wifi.

Si un attaquant récupère la requête ZigBee émise entre le routeur et le thermostat puis la transmet à nouveau, alors (dans le cas où le système anti-rejeu n'est pas activé) elle sera valide et les informations seront bien traitées par l'équipement.

Également, l'attaquant pourrait se servir d'une capture, d'en modifier certaines valeurs dont pour exemple des commandes spécifiques (nécessite de déchiffrer le paquet et de le chiffrer à nouveau).

3.3 Physique

Pour cette partie et comme son nom l'indique, il est nécessaire d'avoir un accès physique au matériel. Elle est le plus souvent réalisée en démontant l'équipement et en réalisant plusieurs actions :

• analyse des puces présentes et recherche des informations sur des moteurs de recherches (FCC ID Search pour exemple) ;
• dump de la mémoire flash (SPI, JTAG, etc.) ;
• dump de la RAM (JTAG, SWD, etc.).

Pour réaliser ces dumps, un Shikra, un Bus Pirate ou autre matériel de ce type peuvent être utilisés.

3.4 Déni de service

Une attaque par déni de service vise à faire saturer l'équipement cible afin qu'il ne soit plus fonctionnel. Pour cela, de nombreuses requêtes pourraient être envoyées à l'un des équipements afin de saturer sa charge ou de provoquer une décharge rapide de la batterie. Aussi, l'utilisation d'un numéro de trame très élevé pourrait potentiellement empêcher l'appareil légitime de fonctionner. En effet, si l'attaquant qui se trouve dans le réseau ZigBee usurpe un appareil légitime en utilisant un numéro de trame très élevé, il pourrait rendre inopérant l'appareil légitime. Celui-ci essaiera de se connecter avec son numéro de trame + 1 qui ne sera alors plus valide.

4. Jouons avec le ZigBee

Afin de pouvoir tester les attaques précédemment détaillées, un dongle ZigBee ou autre matériel supportant cette technologie est nécessaire. Pour notre cas d'étude, nous avons utilisé le dongle RZUSBSTICK proposé par ATMEL fabricant de composants à semi-conducteur. Bien que ce dongle possède de très bonnes caractéristiques, il ne permet pas l'injection de paquets par défaut. Seules les fonctionnalités dites passives (sniffing) sont possibles. Afin de fournir les pleines capacités au dongle, il est nécessaire de flasher son Firmware. Pour réaliser cette recette, vous aurez besoin de :

• 1 Atmel AVR RZUSBSTICK ;
• 1 Atmel AVR Dragon (ATAVRDRAGON) ;
• 1 adaptateur JTAG Atmel 100-mm vers 50-mm ;
• 1 broche de 50mm mâle-mâle ;
• 1 nappe femelle / femelle 10-pin (2x5) 100-mm ;
• le logiciel AVRDUDE (http://winavr.sourceforge.net pour Windows ou http://www.nongnu.org/avrdude pour Linux) ;
• le firmware KillerBee pour le dongle RZUSBSTICK.

Le branchement est assez simple si on a le matériel adéquat comme constaté ci-dessous :

Il est bien entendu possible de bidouiller pour éviter l'achat de certains connecteurs, mais cela nécessite de ne pas avoir les doigts carrés :)

Le téléchargement du firmware se fait à l'aide de la commande suivante :

et pour flasher le dongle :

Pour s'assurer que le flash s'est correctement effectué, il est nécessaire de :

• vérifier le message de bon déroulement de l'opération ;
• contrôler la diode qui passe du bleu (avant flashage) à l'orange (après flashage) ;
• s'assurer que la commande sudo zbid retourne le nom de produit « KILLERB001 » (nécessite l'installation de KillerBee détaillée plus bas).

4.1 KillerBee

KillerBee [6] est un framework python comportant plusieurs outils permettant d'effectuer des attaques sur ZigBee et autres réseaux 802.15.4.

L'installation de ce dernier nécessite les dépendances suivantes :

Pour télécharger et installer le framework KillerBee, les commandes suivantes sont à exécuter :

Afin de tester les outils sur un cas réel, nous avons choisi une ampoule connectée utilisant le protocole ZigBee. Le matériel acheté se compose de deux éléments :

• une base servant de passerelle Wifi et disposant de la technologie ZigBee permettant de piloter l'ampoule ;
• une ampoule connectée utilisant le protocole ZigBee pour communiquer avec la base. L'ampoule ne dispose pas de connexion Wifi.

Nous commençons par vérifier les réseaux ZigBee accessibles à travers l'outil zbstumbler :

Puis une capture est effectuée lors de l'appairage des équipements via l'outil zbsniff :

À travers l'utilisation de la Trust Center Link Key « ZigBeeAlliance09 » souvent laissée par défaut, il est possible de déchiffrer le trafic et de récupérer la Transport Key. Pour cela, il est nécessaire renseigner la Trust Center Link Key dans les options Wireshark dédiées au dissecteur ZigBee (Edit > Preferences > Protocols > Zigbee NWK : cliquer sur Nouveau puis ajouter la clé en hexadécimal) :

Comme illustré ci-dessous, il a été possible de récupérer la Transport Key (qui est ici la clé réseau) :

En ajoutant cette clé dans les options ZigBee de Wireshark, il est possible de déchiffrer l'ensemble du trafic :

En ayant connaissance de ces informations, il est possible de forger des paquets en les chiffrant avec la Network Key puis avec la Trust Center Link Key (en réalité c'est un dérivé de cette clé qui est utilisé) afin qu'ils soient pris en compte par le coordinateur/routeur et paraître pour une requête légitime. Des tests ont été réalisés dans notre laboratoire et sont fonctionnels.

L'inconvénient de cette méthode est que la capture de la clé ne peut être réalisée qu'au moment de l'initialisation de l'équipement final (ici l'ampoule) au routeur ou si elle est envoyée en clair. Afin de récupérer la Network Key sur un appareil déjà appairé, deux méthodes peuvent être utilisées :

• rendre inopérant le réseau cible via l'envoi de nombreuses associations. L'utilisateur devra alors procéder à une reconfiguration de son système et donc de procéder à un nouvel appairage ;
• dans certaines implémentations, simuler un nouvel appairage à destination du routeur.

Par la suite, il a été possible de réaliser une attaque par rejeu sur l'équipement testé. Bien que la sécurité de type anti-rejeu soit présente, elle ne semble pas être utilisée sur notre cas d'étude. Ainsi, il est possible de rejouer n'importe quelle commande envoyée (ex : éteindre et allumer l'ampoule, modifier sa couleur et sa luminosité, etc.) :

D'autres outils sont disponibles dans la suite KillerBee et sont détaillés dans son fichier README.

4. SecBee

SecBee [7] est un outil développé par Cognosec permettant de tester certains points de sécurité ZigBee. Il est complémentaire à KillerBee et intègre des fonctionnalités supplémentaires notamment sur des actions à réaliser à travers le chiffrement utilisé (clés du Trust Center et NWK) ou tout simplement pour se connecter ou communiquer avec des équipements ZigBee.

Pour exemple, l'outil permet de retrouver la Network Key (via sa récupération en clair ou en déchiffrant les paquets avec la Trust Center Link Key) et de l'utiliser pour simuler des paquets légitimes. Toutes les fonctions pour la création d'un paquet ZigBee légitime sont présentes dans l'outil.

La procédure d'installation est disponible sur le lien suivant : https://github.com/Cognosec/SecBee/blob/master/installsecbee.txt.

Conclusion

De nombreuses sécurités ont été prévues dans les spécifications du protocole ZigBee, dont l'utilisation d'un algorithme de chiffrement robuste, d'un contrôle d'intégrité, d'un système anti-rejeu, etc. Cependant, la principale faiblesse du protocole réside dans son implémentation pour l'échange de clés qui n'offre pas suffisamment de sécurité et équivaut plus ou moins à un échange de clé en clair. Seul l'établissement de clés via CBKE semble intéressant mais n'est que très rarement rencontré car sa mise en place et son maintien semble assez fastidieux. De plus, les sécurités proposées par le protocole ne semblent pas être implémentées de la bonne manière sur de nombreux équipements du marché. Ceci entraîne de nombreuses failles de sécurité qui permettent souvent à un attaquant de prendre le contrôle des équipements utilisant le protocole ZigBee.

Remerciements

Merci à toute l'équipe Digital Security et les différents relecteurs.

Références

[1] ZigBee Cluster Library : http://www.zigbee.org/?wpdmdl=2177

[2] https://fr.wikipedia.org/wiki/Carrier_Sense_Multiple_Access_with_Collision_Avoidance

[3] Spécification ZigBee 2007 : http://www.zigbee.org/?wpdmdl=2168

[4] http://www.willhackforsushi.com/presentations/toorcon11-wright.pdf

[5] https://www.blackhat.com/docs/us-15/materials/us-15-Zillner-ZigBee-Exploited-The-Good-The-Bad-And-The-Ugly.pdf

[6] https://github.com/riverloopsec/killerbee

[7] https://github.com/Cognosec/SecBee

[8] Drew Gislason, « Zigbee Wireless Networking », Newnes, 2008

[9] Shahin Farahani, « ZigBee Wireless Networks and Transceivers », Newnes, 2008

[10] Olivier Hersent, David Boswarthick, Omar Elloumi, « The Internet of Things: Key Applications and Protocols », Wiley, 2008