Cet article fait partie d’une série consacrée à Netatmo : les autres articles sont disponibles ici.
Avant de se lancer et d’ouvrir les produits Netatmo, on va regarder les informations disponibles sur internet…
Pour cela, on va tout d’abord regarder les informations disponibles sur le site du constructeur. Ensuite, on va regarder les analyses cyber existantes.
Analyse Software BOM
La « B.O.M. » (Bill Of Materials) d’une carte électronique est un document qui liste l’ensemble des composants montés sur une carte. De la même manière, on parle de SBOM ou Software Bill Of Materials pour la liste des dépendances logicielles.
Établir une SBOM dans un format « couramment utilisé et lisible par machine » est une exigence du CRA, le Cyber Resillience Act, une nouvelle norme européenne qui doit rentrer en application en 2027 et qui agite aujourd’hui le monde de l’embarqué.
Pourquoi je vous parle de ça?
Parce que Netatmo est plutôt bon élève sur ce point, et que ces SBOM sont disponibles sur son site: on a celle de la caméra indoor, celle de la sirène, celle de des détecteurs et en bonus celle de la caméra outdoor.
Qu’est-ce qu’on en apprend? cela peut nous donner des informations sur les fonctionnalités des produits, et nous éclairer sur les choix de conception.
SBOM détecteur
Sur le détecteur, pas grand-chose : on apprend que le détecteur est basé sur un NRF51 de chez Nordic. Nordic est un concepteur de puces électroniques norvégien sans usine (fabless). Il est spécialisé dans les puces qui intègrent un micro-contrôleur et une partie radio (qui peut être bluetooth, BLE, …). Il s’agit de composants européens, relativement cher : 2.4€ chez Mouser pour le NRF51822-QFAA-R7 par lot de 1000, ce qui accrédite le « Created in France. Made in China ». Le NRF51822 contient un coeur ARM Cortex M0, avec une horloge à 16 MHz, jusqu’à 256 Ko de Flash et 32 Ko de RAM et supporte les protocoles BLE et ANT. La conso en veille du circuit est de l’ordre du µA et il embarque un coprocesseur crypto (128-bit AES).
Il utilise Newlib qui est une implémentation populaire de la lib C, très répandue dans l’embarqué.
SBOM sirène
On n’apprend pas beaucoup de chose en plus que pour le détecteur.
La sirène est architecturée autour d’un NRF52, toujours de chez Nordic. Le NFR52 dispose d’un cœur Arm Cortex M4. Plus récent que le NRF51, il tourne à 64 MHz, possède une FPU, embarque 512Ko de Flash et 64Ko de RAM. Il supporte le BLE, possède une Trust-zone, un coprocesseur crypto (AES) et peut gérer du NFC. Il affiche également une conso en veille de l’ordre du µA.
Elle utilise l’OS temps réel FreeRTOS (racheté par Amazon), très populaire dans l’embarqué.
Elle utilise la bibliothèque Nordic SoftDevice qui utilisée pour la gestion des protocoles BLE et ANT chez Nordic.
Le truc un peu étrange, c’est l’utilisation de la librairie de chiffrement Mbed TLS qui est plutôt utilisée pour la partie sécurité de la stack TCP/IP. Je vois deux possibilités : soit des bouts de TLS sont utilisés uniquement (les algo de chiffrement ou la gestion de certificats), soit TLS est utilisé par-dessus le protocole BLE.
SBOM caméra
La SBOM de la caméra est beaucoup, beaucoup plus fournie. Attention, c’est un peu indigeste.
Tout d’abord on apprend que la caméra tourne sous Linux, sans info de version.
FreeRTOS serait également utilisé, ce qui sous-entendrait qu’il y a en plus du SOC Linux, au moins un micro-contrôleur (on vérifiera plus tard :p)
Apple WAC POSIX Server est lié au programme MFI d’Apple, cela permet d’afficher le logo « Works with Apple Homekit » et permet de se connecter à l’écosystème Apple.
Apple mDNSResponder sert pour le protocole Bonjour (ZeroConf qui permet des attributions de s’auto-attribuer des adresses IP,… sans serveur DHCP si j’ai bien compris).
Microchip WILC driver, les WILC sont des SOC Wifi de chez Microchip.
LwIP est une stack IP Open source, assez répandue de l’embarquée, je vois deux possibilités : soit LwIP est utilisée en remplacement de la stack IP Linux, soit un micro sous FreeRTOS embarque LwIP… pour pouvoir trancher, il faudra ouvrir la caméra 🙂
STM32 Standard Peripheral Library : cela voudrait dire que la caméra possède un microcontrôleur STM32, pareil, à creuser en ouvrant la caméra.
CSRP est une implémentation en langage C du protocole SRP Secure Remote Password qui permet une authentification par mot de passe sécurisée (le mot de passe n’est pas émis en clair sur le réseau).
LwBT est une pile Bluetooth conçue pour s’interfacer avec LwIP. Je me demande ce qu’ils font avec… Est-ce qu’il y a de l’IP par-dessus du BLE ? Cela permettrait de comprendre l’utilisation de MbedTLS dans la sirène… ou pas.
Il y a ensuite les SDK pour Nrf51 et Nrf52. Peut-être qu’en fonction des versions la caméra embarque soit un Nrf51 soit un Nrf52? On a déjà parlé du « Nordic SoftDevice », la caméra embarque également le Nordic nRF HK SDK. J’avoue, je n’ai pas réussi à trouver de façon certaine ce que c’est. Je ne demande si c’est le « nRF5 SDK for HomeKit » ou l’addon pour HomeKit du « nRF Connect SDK » ou encore complètement autre chose…
OpenSSL c’est un classique (librairie de chiffrement SSL/ TLS). Fun fact : elle est notée deux fois dans les dépendances.
Je me demande pourquoi est utilisé AES Gladman : il s’agit d’une implémentation d’AES soft. Il y en a déjà une dans OpenSSL, et que les Nrf ont un accélérateur crypto (AES hardware)… Je ne comprends pas, à moins que ce soit pour un secure boot ou pour un micro sans accélérateur AES et où OpenSSL ne serait pas adapté (trop grosse?).
Libsodium est une librairie de crypto : hash, chiffrement, signature,… J’avoue, je commence à me demander combien d’implémentation d’AES différentes sont embarquées dans cette caméra?
Hmacsha512 c’est un algo de signature au sens cryptographique du terme.
BitField-C est une petite librairie de gestion de champ de bits, développée à l’origine pour gérer le bus CAN par Ford.
LZ4 est un algo de compression/décompression.
Android : ça c’est une surprise! La caméra tournerait sous Android… je ne vois pas trop l’intérêt par rapport à un Linux dans le contexte d’une caméra connectée, mais pourquoi pas? Pour rappel Andoid est basé sur Linux donc quand vous avez Andoid, vous avez forcément Linux.
OpenCV : bon, là pas de surprise, c’est une librairie de traitement de l’image et de la vidéo. L’abréviation « CV » veut dire Computer Vision.
Boost : là, c’est une librairie C++ qui est tellement vaste qu’on ne peut pas vraiment dire pourquoi elle est utilisée dans ce contexte. Y a de tout : du traitement d’image, des algorithmes, de la sérialisation, des fonctions mathématiques…
TinyALSA est si j’ai bien compris une librairie pour relier le monde android et les drivers audio de Linux.
openPDM-Filter: cette librairie, développée par ST est utilisée pour convertir du format PDM vers le format PCM. Il s’agit de formats audio.
LibJPEG est une librairie de gestion de JPEG (allez, en cœur: « merci captain Obvious »).
LibCurl est une lib de transfert de données vers ou depuis un serveur par le biais d’url (FTP, …)
LibCedar est une lib d’encodage/décodage vidéo pour les formats H.264, MJPEG, MPEG2 et MPEG4 écrite pour les DSP Cedarx d’AllWinner. Allwinner est une entreprise chinoise de semi-conducteur qui fait des SOC compatible Android et Linux avec du traitement vidéo. A voir si la caméra utilise un SOC AllWinner.
EGL est une API du Khronos-Group qui fait le lien entre OpenGL et le système de gestion de fenêtre de l’OS (merci wikipedia). Qu’est ce que ça vient faire dans une caméra sans écran? C’est probablement une dépendance d’Android ou de Linux.
FFTW est une librairie de calcul de FFT (transformées de Fourrier). En gros, cela permet de passer d’une fonction dépendant du temps à une fonction dépendant de la fréquence. C’est très utilisé dans tout ce qui est traitement de signal.
PCRE est une librairie d’expression régulière…
Vo-aacenc est en encodeur AAC (format audio)
Lua est un langage de script pas mal utilisé dans le jeu vidéo… je vois pas trop l’intérêt dans ce contexte…
Caffe est un framework de deep-learning. Utilisé pour de la classification d’image et la reconnaissance faciale?
Protobuf est une lib de serialisation pour des échanges client/serveur créée par Google et qui est assez populaire .
Gflags est une lib de gestion de flags de ligne de commande. Je la découvre… et je ne savais même pas qu’il y avait des libs pour ça.
OpenBLAS est une lib de calcul matriciel.
ZXing-C++ est une lib de traitement d’image spécialisée dans les codes barres.
FFMPEG est un outil vidéo. Il permet de faire plein de chose : ajouter une piste audio, convertir le format vidéo, extraire des images d’une vidéo …
LIGHTTPD est un serveur HTTP
Probablement que certains des composants listés ci-dessus pour la caméra ne sont pas réellement utilisés, et ne sont là que comme dépendance d’Android ou de Linux.
Analyse Cyber
Les analyses cyber sont un bon moyen de trouver des infos sur un produit. Attention : je ne suis pas un expert en cybersécurité, je peux raconter des bêtises 🙂
On peut noter que Legrand est également plutôt un bon élève, puisqu’ils ont mis en place une page pour prendre contact avec eux en cas de découverte de vulnérabilité (c’est également une exigence du CRA). Avant cette mise en place, Netatmo avait déjà sa page de contact (qui a depuis été remplacée).
J’ai trouvé deux analyses cyber :
- la première, menée par softscheck (en 2018~2019), une entreprise allemande de cyber-sécurité: ici et là, se concentre principalement sur la caméra et l’application. De leur première page, on peut retenir qu’ils ont réussi à faire passer un inconnu pour une personne enregistrée par la caméra à l’aide de l’impression d’une photo. Dans la seconde, ils ont réussi à obtenir un accès root sur la caméra à l’aide d’un accès local.
- la seconde, menée par bitdefender (société de cybersécurité et éditeur d’antivirus) et PCMag (Magazine PC) en 2020 de ce que j’ai compris, c’est un autre moyen d’obtenir un accès local root. PCMag indique que Netatmo a été très réactif sur leur analyse.
Obtenir un accès root à partir d’une connexion locale n’est pas le pire scénario de faille de sécurité (pas exploitable à distance à priori)… et la réaction de Netamo a été rapide et efficace. Donc, plutôt un bon point pour Netatmo qui prend la cybersécurité au sérieux. Évidement cela aurait été encore moins grave si la caméra avait été auto-protégée … ce qui est le cas pour les systèmes NFA2P ou EN-50131.
La possibilité de tromper la caméra avec une simple photo est un peu plus … gênante. On va voir si c’est toujours le cas en 2025 dans un prochain article… stay tuned!