IoT security

Focus sur la sécurité du Bluetooth Low Energy

Jenny Baur BLOG

La technologie Bluetooth Low Energy (BLE) est aujourd’hui en train de devenir l’un des standards sans fil les plus utilisés au sein des appareils IoT. En parallèle, son utilisation se généralise également de plus en plus au sein d’applications dans lesquelles des informations sensibles sont transférées. Les fabricants d’appareils IoT qui cherchent à intégrer la technologie BLE à leurs produits devraient, par conséquent, être conscients de ses fonctions de sécurité et des limites qu’elle implique. Dans cet article, je vais m’efforcer de vous fournir une vue d’ensemble des fonctions de sécurité de la technologie BLE. Si vous ne connaissez pas encore la technologie BLE, je vous suggère de jeter un œil à ce webinar très bien fait de Nordic Semiconductor.

Vue d’ensemble

Une connexion BLE est présentée comme fonctionnant selon un mode de sécurité spécifique, pour lequel il existe plusieurs niveaux de sécurité différents. Le niveau/mode de sécurité exigé d’une connexion peut changer de temps à autre, ce qui a donné naissance à la création de procédures permettant de renforcer la sécurité. Notez que le cycle de vie de chaque connexion débute en Mode de sécurité 1, Niveau 1.

Lorsque deux appareils, qui ne sont initialement pas dotés de moyens de sécurité, souhaitent réaliser une opération nécessitant un certain niveau de sécurité, les appareils doivent tout d’abord être appairés. Ce processus est déclenché par un périphérique maître (ou Central device, par exemple un smartphone) qui tente d’accéder à une valeur (une « caractéristique ») sur un périphérique esclave (Peripheral Device) qui exige un accès authentifié. L’appairage implique l’authentification de l’identité des deux appareils, le chiffrement de la liaison à l’aide d’une clé court terme (STK) et la transmission de clés long terme (LTK) utilisées pour le chiffrement. La clé long terme est enregistrée pour accélérer toute nouvelle connexion à l’avenir, un mécanisme qui porte le nom de couplage (bonding).

Le processus est illustré dans le schéma suivant :

Le nouveau niveau de sécurité de la connexion se base sur la méthode d’appairage mise en œuvre. Il est par ailleurs sélectionné en fonction des I/O capabilities de chaque appareil. Le niveau de sécurité de toute nouvelle connexion ultérieure s’appuie sur le niveau mis en œuvre lors du premier appairage.

Le rôle que chaque appareil joue est défini dans le gestionnaire de sécurité de la stack BLE. Les rôles sont les suivants : Initiator (périphérique maître) et Responder (périphérique esclave).

Chiffrement et authentification

Le chiffrement dans Bluetooth LE se base sur le standard de chiffrement avancé 128 bits selon le protocole CCM (AES-CCM). Les clés long terme sont traitées par cet algorithme pour créer la clé « secrète partagée » de 128 bits.

Sous BLE, l’authentification est effectuée lors de la signature numérique des données à l’aide de la clé CSRK (Connection Signature Resolving Key). L’appareil qui émet place sa signature à la suite du PDU. L’appareil qui reçoit vérifie la signature à l’aide de la clé CSRK.

Modes et niveaux de sécurité d’une connexion

Pour une connexion BLE, le GAP (Generic Access Protocol) définit deux modes de sécurité, ainsi que plusieurs niveaux par mode.

Mode de sécurité 1

Le Mode de sécurité 1 garantit la sécurité via un chiffrement des données et inclut quatre niveaux :

  • Niveau de sécurité 1 : aucune sécurité (pas d’authentification ni de chiffrement)
  • Niveau de sécurité 2: appairage non authentifié avec chiffrement
  • Niveau de sécurité 3: appairage authentifié avec chiffrement AES-CCM
  • Niveau de sécurité 4: appairage authentifié en mode LE Secure connections et chiffrement. Le Niveau 4 utilise l’algorithme Elliptic Curve Diffie-Hellman P-256 (ECDH) et le chiffrement AES-CCM.

Mode de sécurité 2

Le Mode de sécurité 2 garantit la sécurité via la signature des données et inclut deux niveaux :

  • Niveau de sécurité 1: appairage non authentifié avec signature des données
  • Niveau de sécurité 2: appairage authentifié avec signature des données

Mode de sécurité mixte

Le Mode de sécurité mixte est appliqué lorsqu’un appareil doit à la fois prendre en charge les Modes de sécurité 1 et 2, autrement dit, lorsqu’il doit prendre en charge des données signées et non signées. Le mode Connexion sécurisée uniquement correspond au Mode de sécurité 1, Niveau de sécurité 4, ce qui signifie que l’ensemble du trafic entrant et sortant au niveau d’un appareil Bluetooth doit exclusivement s’appuyer sur des connexions authentifiées et un chiffrement des données.

Le cycle de vie de chaque connexion débute en Mode de sécurité 1, Niveau 1. Ce niveau de sécurité peut par la suite être renforcé en mettant en œuvre une procédure d’authentification, comme mentionné ci-dessous. Lors de l’appairage, la méthode/l’algorithme choisi(e) détermine si l’appairage s’est ou non basé sur une authentification forte. Les appairages non authentifiés ont lieu lorsque l’appareil n’a pas pu s’authentifier par lui-même (par exemple, s’il n’a pas d’I/O capabilities).

Davantage d’informations sont disponibles dans le document « BLE v4.2 Core Specification », Vol. 3, Partie C, Section 10.

Modes d’appairage

L’appairage implique d’authentifier l’identité des deux appareils à appairer, habituellement via un processus d’échange d’informations secrètes. Dès que l’authentification est terminée, la liaison est chiffrée et les clés sont distribuées pour permettre d’accélérer le processus lors de toute nouvelle connexion ultérieure. Si ces clés sont enregistrées pour utilisation ultérieure, il s’agit d’un couplage. L’appairage se déroule en 3 phases.

Phase 1

Lors de la première phase, les deux appareils se transmettent mutuellement des informations sur leurs capacités (capabilities). Les valeurs auxquelles ils ont accès sont des valeurs ATT (Attribution Protocol), stockées dans la couche 4 à l’aide du protocole L2CAP. Elles ne sont pas chiffrées. Ces valeurs déterminent la méthode d’appairage qui sera utilisée lors de la deuxième phase, ce que les appareils peuvent faire et ce à quoi ils peuvent s’attendre. À titre d’exemple, les I/O capabilities de l’appareil qui sont sélectionnées à partir de l’une des catégories citées ci-après déterminent le niveau de sécurité de la collection. Les appareils communiquent leurs capacités à l’aide d’un message de demande d’appairage formulée par le gestionnaire de sécurité. Les catégories possibles sont les suivantes : No Input No Output, Display Only, Display Yes/No, Keyboard Only et Keyboard Display.

Phase 2

Lors de la phase 2, l’objectif est de générer une clé court terme. Les appareils se mettent ainsi d’accord sur une clé temporaire associée à un certain nombre de chiffres aléatoires, qui leur donne la clé court terme. La clé court terme en elle-même n’est jamais transmise. Le fait d’utiliser une clé court terme est connu sous le nom « LE legacy pairing ». Si le mode Connexion sécurisée uniquement est utilisé, une clé long terme est toutefois générée à ce stade (plutôt qu’une clé court terme), ce processus étant baptisé « LE Secure connections ».

Phase 3

Pour la phase 3, la clé de la phase 2 est utilisée pour distribuer le reste des clés nécessaires aux communications. Tandis qu’aucune clé de ce type n’a été générée lors de la phase 2, une clé long terme est générée au cours de la phase 3. À ce stade, des données telles qu’une clé CSRK pour la signature des données ou une clé IRK (Identity Resolving Key) pour la génération et la recherche d’une adresse MAC privée sont générées.

flowcharts

Organigramme d’appairage applicable aux deux modes « LE legacy pairing » et « LE Secure connections ».

Procédures d’appairage

Une procédure d’appairage implique un échange de paquets via le protocole du gestionnaire de sécurité pour générer une clé de chiffrement temporaire intitulée clé court terme, comme décrit dans le schéma ci-dessus. Pendant cet échange de paquets, les deux appareils conviennent de l’une des méthodes de génération de clé court terme suivantes :

Just Works : la clé court terme est générée par les deux appareils, en fonction des paquets échangés en texte brut. Cette méthode n’offre aucune garantie contre les attaques de l’homme du milieu (MITM).

Passkey Display : l’un des appareils affiche un code à 6 chiffres généré aléatoirement et l’autre invite l’utilisateur à le saisir. Dans certains cas, il est nécessaire de saisir le code sur les deux appareils si aucun écran n’est disponible. Cette méthode offre une protection contre les attaques MITM.

Out of Band (OOB) : avec cette méthode, les données supplémentaires peuvent être transférées par d’autres moyens qu’une radio BLE (tels qu’une autre technologie sans fil comme NFC). Cette méthode offre également une protection contre les attaques MITM.

Numeric Comparison (LE Secure Connections Pairing) and only with BLE 4.2 : cette méthode utilise un algorithme baptisé Elliptic Curve Diffie–Hellman (ECDH) pour la génération des clés et une nouvelle procédure d’appairage pour l’échange de clés. La liaison est chiffrée à l’aide d’une clé long terme à partir de la phase 2.

Vous pouvez vous référer au tableau ci-dessous pour déterminer la méthode d’appairage en fonction des I/O capabilities des deux appareils et du rôle que chaque appareil joue dans le processus.

Procedure

Procédure d’appairage et I/O capabilities

Procédure et modes de couplage

Il existe deux modes :

  • Non-Bondable Mode : il s’agit du mode de couplage par défaut pour les appareils. Cela signifie que l’appareil n’acceptera pas de couplage. Aucune clé ne sera échangée ni stockée par l’appareil.
  • Bondable Mode : pour accepter une demande de couplage, le périphérique esclave doit définir la chaîne de bits de couplage au sein des paramètres d’authentification du message de demande d’appairage pendant l’appairage. Les appareils échangent des clés de sécurité et les stockent.

Si un périphérique maître souhaite établir un couplage avec un périphérique esclave qu’il pense capable de le faire, il utilise la procédure de couplage. Il initie l’appairage grâce à la chaîne de bits de couplage définie dans les paramètres d’authentification du message de demande d’appairage. Si le périphérique esclave peut être couplé, il répondra en envoyant la chaîne de bits de couplage. À l’issue de ces étapes, les clés seront distribuées dès que la liaison sera chiffrée, puis elles seront stockées. Une fois que les clés ont été distribuées et stockées, les deux appareils sont couplés.

Conclusion

La technologie BLE offre plusieurs fonctions pour sécuriser les communications entre différents appareils, chacune ayant ses propres avantages et ses propres limites.

En tant que fabricants d’appareils IoT, nous prenons soin d’implémenter les fonctions BLE au sein de nos produits. Nous sommes conscients des menaces de sécurité spécifiques qui pèsent sur la technologie BLE et nous nous efforçons de tirer parti des fonctions de sécurité BLE pour les neutraliser.

Annexe 1 : Récapitulatif des différences entre la version 4.0 et la version 4.2

Bluetooth 4.2 a introduit un nouveau modèle de sécurité baptisé « LE Secure connections ». Cette méthode utilise un algorithme portant le nom d’Elliptic Curve Diffie–Hellman (ECDH) pour la génération des clés et une nouvelle procédure d’appairage pour l’échange de clés.

En s’appuyant sur cette méthode, ainsi que sur des algorithmes ECDH pour générer les paires de clés publiques/privées, le gestionnaire de sécurité protège des communications de toute écoute passive, indépendamment des I/O capabilities des appareils et des méthodes d’appairage (Numeric Comparison, Just Works, Passkey Entry et Out Of Band). Elle offre un moyen de protection contre les attaques MITM si l’application utilise l’une des méthodes d’appairage suivantes : Numeric Comparison, Passkey Entry ou Out Of Band.

Références

Bluetooth Core Specification, ver. 4.1, Bluetooth SIG, December 2013

Bluetooth Core Specification, ver. 4.2, Bluetooth SIG, December 2014

Bluetooth Pairing https://blog.bluetooth.com/bluetooth-pairing-passkey-entry August 2016

Rosa, T. (2013, May 23). Bypassing Passkey Authentication in Bluetooth Low Energy. Retrieved August 01, 2016, from https://eprint.iacr.org/2013/309.pdf

Ryan, M. (2013). Bluetooth: With Low Energy Comes Low Security. Retrieved August 01, 2016, from https://www.usenix.org/conference/woot13/workshop-program/presentation/ryan

A propos de l'auteur

Alexis Duque

Doctorant au laboratoire CITI et ingénieur R&D en développement logiciel embarqué, Alexis effectue sa thèse sur le Visible Light Communication. Il est aussi passionné par l'Open Source. Voir son profil