Ecouteurs, casques, haut-parleurs : des centaines de millions d’appareils audios présentent une faille technique qui les rend vulnérables au piratage

Des failles dans la manière dont des modèles de casques et d'enceintes utilisent le protocole Bluetooth Fast Pair de Google ont rendu ces appareils vulnérables aux écoutes clandestines et aux harceleurs.

Comment un protocole aussi largement déployé que Google Fast Pair a-t-il pu être implémenté de manière défaillante par autant de fabricants, au point d’exposer des centaines de millions d’utilisateurs à l’écoute clandestine et au suivi de localisation ?

L’affaire WhisperPair illustre une faiblesse bien connue des spécialistes de la sécurité. Un protocole peut être solide sur le papier, mais devenir dangereux dès lors que son implémentation est approximative.

Google Fast Pair repose sur l’hypothèse que les fabricants appliqueraient strictement certaines règles essentielles, notamment le refus automatique de toute nouvelle tentative de connexion une fois l’appairage initial effectué. Or, les travaux menés par les chercheurs de l’université KU Leuven montrent que cette hypothèse ne tient pas face à la réalité industrielle.

Des acteurs majeurs du marché, parmi lesquels Sony, JBL, Jabra ou même Google, ont mal interprété ou appliqué de manière incomplète ces exigences, laissant certains accessoires accepter des connexions non sollicitées. Ces dérives transforment alors de simples écouteurs ou enceintes en vecteurs potentiels d’écoute clandestine ou de suivi à l’insu de leurs utilisateurs. À l’origine, Google Fast Pair a pourtant été pensé pour simplifier au maximum l’appairage Bluetooth, en éliminant les étapes de validation manuelle jugées trop contraignantes, au nom d’une expérience utilisateur fluide et immédiate. Un choix qui, dans ce cas précis, s’est fait au détriment de la sécurité. Le problème est aggravé par une dépendance massive à des SDK Bluetooth fournis par des fabricants de puces, souvent intégrés sans audit approfondi. Cette faille systémique, reproduite à l’identique sur des millions de produits a pour conséquence de permettre à des attaquants d’exploiter cette vulnérabilité pour écouter des conversations, localiser les utilisateurs ou même prendre le contrôle à distance d’un accessoire en quelques secondes. L’absence de mécanisme de validation centralisé et la fragmentation du marché ont permis à cette faille de se propager à grande échelle, exposant des centaines de millions d’utilisateurs à des risques concrets. Ce scandale rappelle que, dans un écosystème où chaque acteur applique les standards à sa manière, l’innovation ne peut durablement se faire au détriment de la sécurité sous peine de compromettre la confiance même dans les technologies que nous utilisons au quotidien.

Cette vulnérabilité révèle-t-elle une faiblesse structurelle du Bluetooth et de l’écosystème des accessoires, où chaque constructeur applique les standards à sa manière sans réel contrôle centralisé ?

WhisperPair montre surtout que la sécurité du Bluetooth dépend davantage des choix faits par les fabricants que d’un défaut du protocole lui-même. Aujourd’hui, le Bluetooth et ses extensions fonctionnent selon un modèle très permissif. Un produit peut être certifié et mis sur le marché tant qu’il respecte les fonctions attendues, même si certaines règles de sécurité ne sont pas appliquées de manière stricte. Cette logique contraste avec celle de systèmes plus critiques, où l’absence d’un prérequis empêche tout simplement le fonctionnement. Dans le cas d’une authentification à deux facteurs, par exemple, la connexion est bloquée si l’un des deux éléments manque.

Les protocoles de connexion rapide comme Fast Pair n’appliquent pas ce principe. Ils acceptent des implémentations incomplètes tant que l’expérience utilisateur reste fluide. En pratique, cela signifie qu’un accessoire peut continuer à fonctionner même si certaines étapes de contrôle prévues par la spécification sont absentes ou mal appliquées. À l’inverse, dans un modèle de sécurité plus strict, le service ne devrait être accessible qu’après la validation complète de tous les mécanismes de protection. De la même manière qu’une authentification forte, l’absence d’un élément critique comme une vérification cryptographique claire lors de la phase de découverte devrait bloquer toute tentative de connexion. WhisperPair montre que ce principe n’est pas appliqué dans l’écosystème des accessoires Bluetooth. Des précédents comme Blue Borne ou SweynTooth ont déjà démontré que cette approche permissive conduit à des erreurs répétées à grande échelle. Tant que la sécurité restera une option et non une condition indispensable au fonctionnement, ce type de vulnérabilité restera possible dans les objets connectés grand public.

Faut-il s’attendre à une refonte des protocoles de connexion rapide - voire à une régulation - pour empêcher que des vulnérabilités comme WhisperPair ne deviennent la norme dans les objets du quotidien ?

À ce stade, rien n’indique qu’une refonte complète des protocoles de connexion rapide soit indispensable d’un point de vue strictement technique. L’histoire récente du Bluetooth montre que, dans la majorité des cas, les vulnérabilités majeures ne proviennent pas des standards eux-mêmes, mais de leur implémentation défaillante.

En 2017, la faille Blue Borne a par exemple permis l’exécution de code à distance sur des smartphones, ordinateurs et objets connectés sans aucune interaction utilisateur, non pas à cause du protocole Bluetooth en tant que tel, mais en raison d’erreurs dans les piles logicielles utilisées par les fabricants.

En 2019, la série de vulnérabilités SweynTooth a touché des puces Bluetooth Low Energy intégrées dans des objets médicaux et industriels, entraînant des risques de déni de service ou de perte de contrôle, là encore liés à des implémentations incorrectes des spécifications BLE. Plus récemment, plusieurs attaques dites man-in-the-middle sur le Bluetooth Low Energy ont démontré que des procédures de pairage mal configurées pouvaient permettre l’interception ou l’altération de communications pourtant basées sur des standards formellement sécurisés.

WhisperPair s’inscrit dans cette continuité. Le protocole Fast Pair prévoit des mécanismes empêchant toute nouvelle connexion une fois l’appairage terminé, mais ceux-ci n’ont pas été appliqués de manière rigoureuse par certains fabricants. Dans ce contexte, une refonte lourde du protocole apparaît moins pertinente qu’un renforcement des exigences d’implémentation, de test et de certification. Tant que les constructeurs respectent strictement les règles définies, notamment le refus systématique des connexions non sollicitées et l’authentification explicite des échanges, le risque reste maîtrisable sans bouleverser l’existant. La question de la régulation ne se pose donc pas tant en termes de nouveaux protocoles que de responsabilités. Imposer des audits de sécurité, des tests d’intrusion et des obligations de mise à jour pourrait suffire à éviter que des failles comme WhisperPair ne se reproduisent à grande échelle, sans transformer les objets du quotidien en surfaces d’attaque permanentes.