En poursuivant votre navigation sur ce site, vous acceptez nos CGU et l'utilisation de cookies afin de réaliser des statistiques d'audiences et vous proposer une navigation optimale, la possibilité de partager des contenus sur des réseaux sociaux ainsi que des services et offres adaptés à vos centres d'intérêts.
Pour en savoir plus et paramétrer les cookies...
Objets connectés : les réseaux LoRaWAN, vulnérables aux attaques de hackers
 

Un chercheur en sécurité a décortiqué la technologie LoRaWAN, soutenue notamment par Orange et Bouygues Télécom. Il a trouvé une multitude de failles à tous les niveaux : protocolaires, logicielles, matérielles.

Inscrivez-vous à la Newsletter Actualités

Newsletter Actualités

A voir aussi

Votre opinion

Postez un commentaire

2 opinions
  • OHersent
    OHersent     

    Un titre un peu alarmiste !
    Concrètement l'étude ne met en relief aucune faille de conception du protocole :
    - l'attaque par le paradoxe des anniversaires du Join, quand on tient compte du fait qu'un capteur fait un Join par jour (ce quele chercheur ignorait peut-être), prend ... plus de 3000 ans pour une probablité de 50%
    - l'attaque par rejeu du DevNonce avait déjà été étudiée par la LoRa alliance, et a été contrée dans LoRaWAN 1.0.2 (sans changement du protocole, c'est une simple recommandation qui protège totalement contre cette attaque à déni de service, et qui consiste simplement à attendre le premier paquet avant de détruire le contexte du Join précédent).
    - le commentaire sur la taille des messages est commun à toutes les cryptographies pour réseaux bas débit, comme CCM*. Il suffit à l'application de normaliser sa taille de message pour s'en protéger, si elle y est sensible (ce qui en pratique est rarement le cas)
    - toutes les remarques ne portent pas sur le protocole lui même, mais sur la possibilité de mal l'implémenter dans un device... On peut supposer effectivement que les entreprises ayant des application strès sensibles à la sécurité utiliseront des Secure Elements pour protéger le AppKey LoRa. Remarquons tout de même que cette clef est unique par capteur.... donc son éventuel piratage par attaque physique d'un capteur ne donne qu'à ce capteur.

  • Sylvain M
    Sylvain M     

    Bonjour

    Je me permets d'apporter quelques précisions à votre article.

    LoRaWAN utilise AES en mode « Output Feedback » (OFB) afin de ne pas gonfler inutilement la taille des messages transmis, très important quand il s'agit de conserver l'énergie. Le message chiffré a donc la même taille que le message non chiffré plutôt que d'être arrondi à un multiple supérieure de la taille de bloc (16 octets pour de l'AES128). Le mode OFB est considéré comme sûr à partir du moment où, pour une clé donnée, un nonce différent est utilisé pour chaque message.

    Tous les opérateurs de réseau publics (à ma connaissance) utilisent la procédure « Over the Air Activation » de LoRaWAN pour appairer des objets à leur réseau. A chaque nouvel appairage d'un objet (ex. après un changement de piles), le compteur de génération du nonce est remis à zéro MAIS une nouvelle clé est générée (dérivée d'une clé secrète unique à chaque objet). Les keystreams sont donc différentes, les messages ne peuvent pas être déchiffrés en utilisant la connaissance des keystreams précédentes et les attaques par rejoue échouent.

    Une procédure simplifiée d' « Activation by Personalization » est aussi décrite dans le protocole LoRaWAN. Dans ce cas, la clé de chiffrement est fixe et c'est au concepteur d' l'objet de prendre des précautions pour que le compteur qui sert à générer les nonces ne soit *jamais* remis à zéro, par exemple en le stockant en mémoire non-volatile. Et c'est à l'opérateur réseau de rejeter tout message émis avec un nonce déjà utilisé. Si ni l'un, ni l'autre ne font leur travail, alors oui, pour les objets concernés (et pas pour les autres objets du réseau) le chiffrement n'offre aucune protection.

    Pour la connexion entre les passerelles et le coeur de réseau, le protocole LoRaWAN ne spécifie rien et c'est laissé entièrement à l'appréciation de l'opérateur réseau. Il n'est dont pas étonnant que certains réseaux montés « à la va-vite » soient des passoires. Point important : les passerelles ne peuvent pas déchiffrer le trafic, ni injecter du trafic *valide*, car elles n'ont pas accès aux clés (seul le coeur de réseau y a accès). Elles peuvent faire du dénis de service par contre.

Votre réponse
Postez un commentaire