Les programmes chargés sur la carte NodeMCU peuvent-ils être extraits?

13

J'utilise une carte NodeMCU avec des capacités WiFi pour construire un simple tracker d'actifs. J'ai réussi à trouver quelques croquis Arduino qui permettent la connectivité à Azure IoT Hub et à publier des messages.

L'une des clés que je dois «charger» sur la carte est la chaîne Azure Device Connection et bien sûr un SSID WiFi et un mot de passe.

Ma crainte est que quelqu'un puisse simplement prendre le tableau et "télécharger" les fichiers pour accéder aux informations d'identification de sécurité.

Ma crainte est-elle injustifiée ou la perte de justificatifs d'identité est-elle une menace réelle que je dois atténuer?

security béliers
la source
3
Je pense que les réponses de @Mike Ounsworth et Bence Kaulics prises ensemble me donnent une option décente. Malheureusement, je ne peux pas marquer les deux comme des réponses acceptées.
béliers

Réponses:

12

[Avertissement: Je suis un professionnel de la sécurité / crypto et je traite quotidiennement des questions d'architecture de sécurité comme celle-ci.]

Vous êtes tombé sur le problème du stockage des informations d'identification de telle manière qu'un processus sans assistance puisse y accéder, mais pas un attaquant. Il s'agit d'un problème bien connu et très difficile à résoudre.

Si votre appareil IoT dispose d'un magasin de clés matériel intégré à la carte mère, comme certains TPM, ou l'équivalent du magasin de clés Android ou Apple Secure Enclave, alors vous pouvez l'utiliser.

Avec les serveurs traditionnels, vous pouvez utiliser des HSM ou des cartes à puce, mais la seule solution logicielle complète à ma connaissance consiste à dériver une clé AES à partir d'une sorte d '"empreinte digitale matérielle" construite en combinant les numéros de série de tous les périphériques matériels. Utilisez ensuite cette clé AES pour crypter les informations d'identification. Un processus exécuté sur le même serveur peut reconstruire la clé AES et déchiffrer les informations d'identification, mais une fois que vous extrayez le fichier du serveur, il est essentiellement non déchiffrable.

L'IoT y jette une clé pour deux raisons:

  1. L'hypothèse selon laquelle les numéros de série matériels sont uniques ne tient probablement pas, et

  2. Contrairement aux serveurs, les attaquants ont un accès physique à l'appareil, ils peuvent donc probablement obtenir un shell sur l'appareil pour exécuter le programme de déchiffrement.

Le chiffrement matériel (TPM) et le chiffrement «d'empreintes digitales matérielles» sont au mieux de l'obscurcissement car, fondamentalement, si un processus local peut déchiffrer les données, un attaquant capable d'exécuter ce processus local peut également le déchiffrer.

Donc, l'astuce standard semble ne pas fonctionner ici. La première question que vous devez vous poser est:

  • Quel est mon modèle de menace / où se situe ce projet à l' Secure <--> Convenientéchelle?

En fin de compte, je pense que vous devez soit décider cela security > convenienceet demander à un humain d'entrer les informations d'identification après chaque démarrage (en utilisant quelque chose comme la réponse de @ BenceKaulics ), soit vous décidez cela security < convenienceet vous mettez simplement les informations d'identification sur l'appareil, peut-être en utilisant un peu d'obscurcissement si vous sentir que cela fait une différence.

Il s'agit d'un problème difficile rendu plus difficile par la nature des appareils IoT.

Pour être complet, la solution industrielle complète à ce problème est:

  • Donnez à chaque appareil IoT une clé publique RSA unique au moment de la fabrication. Enregistrez cette clé publique dans une base de données par rapport au numéro de série de l'appareil.
  • Stockez les informations d'identification sensibles sur un serveur approprié, appelons-le une «passerelle».
  • Lorsqu'un appareil IoT s'authentifie auprès de la passerelle (à l'aide de sa clé RSA), la passerelle ouvre une session pour lui à l'aide des informations d'identification stockées et remet le jeton de session au périphérique.
  • Pour une meilleure sécurité, la passerelle est une passerelle physique (ou VPN) afin que tout le trafic provenant de l'appareil IoT passe par la passerelle et que vous ayez plus de contrôle sur les règles et autres choses du pare-feu - ce qui empêche idéalement le périphérique d'avoir un accès direct (tunnel non VPN) accès à Internet.

De cette façon, et l'attaquant qui compromet un appareil peut ouvrir une session, mais n'a jamais accès directement aux informations d'identification.

Mike Ounsworth
la source
2
Oui. Une grande partie du problème est que ce qui tente d'être protégé ici est le secret partagé qui est un mot de passe wifi. Les secrets partagés sont une mauvaise idée lorsqu'un appareil peut être physiquement disséqué. Une meilleure conception séparerait chaque instance de l'appareil (ou autre ordinateur) dans son propre environnement de sécurité avec un canal sécurisé unique entre chaque gadget individuel et les systèmes avec lesquels il a besoin de communiquer. De toute façon, le wifi n'est peut-être pas très bien adapté à l'application de toute façon par rapport à un schéma point à point de 2,4 GHz ou même au protocole "Esp Now".
Chris Stratton
1
Bon point. Vous pouvez résoudre le problème de secret partagé en utilisant des certificats de client d'entreprise WPA2 plutôt qu'un mot de passe SSID (si le périphérique IoT est assez grand pour avoir une pile TLS, beaucoup ne le sont pas). Je ne sais rien d'Azure IoT Hub, mais je suppose que ces chaînes Azure Device Connection sont déjà uniques par appareil. Malheureusement, cela semble être un noir et blanc assez net entre «DIY no security» et «Industrial-scale security» avec pas grand-chose entre les deux.
Mike Ounsworth
2
Je me demande, si je peux ouvrir une session à volonté, pourquoi aurais-je besoin des informations d'identification?
Andrew Savinykh
1
@AndrewSavinykh Dépend de ce que sont les informations d'identification. Peut-être qu'ils ne font qu'ouvrir une session, auquel cas oui, pas beaucoup de raison. Mais ce sont peut-être des informations d'identification de domaine Windows AD, ou donnent accès à des API supplémentaires qui ne sont normalement pas utilisées / accessibles à partir de l'appareil IoT. Peut-être que vous êtes d'accord avec les sessions provenant d'appareils compromis, mais pas avec les sessions provenant des ordinateurs portables des attaquants. Oui, cela devient assez rapide spécifique au cas d'utilisation.
Mike Ounsworth
3
Numéros de série??? Trouver un numéro de série unique ne devrait pas être un problème, mais les numéros de série ne sont pas secrets. Ils sont inutiles pour former une clé. Où diable utilise les numéros de série pour former une clé, une «astuce standard»?
Gilles 'SO- arrête d'être méchant'
6

La menace est réelle mais heureusement, ce n'est pas vous le premier ou le seul à avoir ce genre de problèmes de sécurité.

Ce dont vous avez besoin, c'est que ESP WiFi Manager est ce dont vous avez besoin ici.

Avec cette bibliothèque, l'ESP qui n'a pas de session enregistrée passera en mode AP et hébergera un portail Web. Si vous vous connectez à cet AP avec un PC ou un téléphone intelligent, vous pourrez configurer les informations d'identification WiFi via une page Web.

Vous n'avez pas à coder en dur les informations critiques et vous pouvez utiliser votre appareil sur n'importe quel réseau WiFi que vous souhaitez sans avoir besoin de le reflasher.

Comment ça fonctionne

  • lorsque votre ESP démarre, il le configure en mode Station et essaie de se connecter à un point d'accès précédemment enregistré

  • si cela échoue (ou si aucun réseau précédent n'a été enregistré), il place l'ESP en mode point d'accès et fait tourner un DNS et un serveur Web (IP par défaut 192.168.4.1)

  • en utilisant n'importe quel appareil compatible wifi avec un navigateur (ordinateur, téléphone, tablette) se connecter au point d'accès nouvellement créé

  • en raison du portail captif et du serveur DNS, vous obtiendrez soit une fenêtre contextuelle de type «Rejoindre le réseau», soit tout domaine auquel vous tenterez d'accéder sera redirigé vers le portail de configuration.

  • choisissez l'un des points d'accès scannés, entrez le mot de passe, cliquez sur enregistrer

  • ESP essaiera de se connecter. En cas de succès, il renonce au contrôle de votre application. Sinon, reconnectez-vous à AP et reconfigurez.

(Documentation ESP WiFi Manager)

Bence Kaulics
la source
1
Ou téléchargez simplement les enregistrements ou quoi que ce soit pendant qu'il est en mode AP. Espérons que l'affiche n'essaie pas d'utiliser le wifi lui-même pour le suivi des actifs.
Chris Stratton
1
@ChrisStratton :-) en fait, j'essaie d'utiliser le WiFi pour le suivi des actifs. Heureusement, le réseau WiFI que j'utilise est public et ouvert, mais je m'inquiète des implications lorsque j'en utiliserai un autre qui a besoin d'un mot de passe. Le fait que la chaîne de connexion AzureIoT Hub se trouve également sur l'appareil.
béliers
2
@rams Sûrement, la lecture de l'EEPROM de l'appareil ne serait pas une grosse tâche.
Bence Kaulics
3
@rams Sur votre matériel, oui EPROM peut être lu. Les appareils plus récents peuvent avoir certaines régions flash sécurisées qui sont mieux protégées. Il s'agit certainement d'un problème connu qui nécessite un support sur puce pour essayer de fonctionner correctement.
Sean Houlihane
2
@SeanHoulihane - l'ESP8266 n'a pas d'EEPROM. Le flash SPI qu'il utilise pour tout (y compris le type d'émulation de la fonctionnalité Arduino) est externe à l'ESP8266. Même dans le module multi-puces, c'est un dé distinct qui peut être sondé dans un laboratoire décent.
Chris Stratton
3

Oui, ils peuvent accéder à votre mot de passe si vous le laissez en texte brut.

Le bon point est que de nombreuses interfaces de connexion wifi acceptent les mots de passe hachés. Bien que ceux que j'ai utilisés acceptent les hachages md5 et que md5 ne soit pas super sécurisé, c'est toujours un défi très difficile pour un joe moyen. En fonction de votre fichier de configuration, vous indiquez le nom de votre algorithme de hachage puis écrivez votre mot de passe ou vous utilisez la valeur par défaut utilisée par votre interface wifi.

atakanyenel
la source
3
S'ils peuvent extraire un mot de passe haché qui fonctionne pendant le hachage, qu'est-ce qui les empêche de l'utiliser sans jamais l'inverser?
Chris Stratton
1
@ChrisStratton vous avez raison. Les moyens de la prévenir sont pour la sécurité de l'information SE, cette question demande de prévenir la perte des informations d'identification. Néanmoins, les mots de passe hachés ne peuvent toujours pas être utilisés par les mobiles pour se connecter au réseau sans logiciel supplémentaire.
atakanyenel
1
Oui, en effet, il offrirait une certaine protection en cas de réutilisation du mot de passe wifi sur un autre système, mais pas beaucoup contre une connexion non autorisée à ce point d'accès wifi.
Chris Stratton
1
@ChrisStratton oui, par exemple, la liste blanche MAC est beaucoup plus sécurisée que le simple fait d'avoir un mot de passe et de le hacher, mais ces étapes concernent la sécurité wifi en général, pas la confidentialité des informations d'identification sur les appareils publics.
atakanyenel
2
Non, la liste blanche MAC est une blague - il n'y a pas de secret du tout. Et bien sûr, le MAC est facilement extrait de l'ESP8266 volé ou de son flash SPI. Le seul endroit où la liste blanche MAC aiderait serait contre les personnes qui utilisent une interface graphique pour rejoindre les réseaux wifi, ou si un point d'accès était assis là en attente d'une connexion d'un client qui pourrait apparaître un jour, mais ne s'y était jamais connecté - c'est-à-dire , épée dans les trucs de type pierre.
Chris Stratton
1

Réponse simple - OUI. Ça peut être fait. Vous devez, au moins, effectuer une sorte d' obscurcissement pour fournir une protection minimale.

Amit Vujic
la source
1
L'obfuscation rend plus difficile de savoir comment l'appareil fait les choses, mais il est inutile de se protéger contre le clonage de l'appareil. Il est inutile de se protéger contre l'extraction des informations d'identification: tout ce que vous avez à faire est d'exécuter le firmware dans un émulateur.
Gilles 'SO- arrête d'être méchant'
Entièrement d'accord. Ma motivation en donnant une telle réponse était de noter que <la sécurité du réseau IoT doit être prise en compte>. @Mike Ounsworth a donné une réponse détaillée suggérant des solutions utilisant une infrastructure AES et / ou RSA. J'envisage de donner une réponse de plus, mais je ne sais pas trop comment plonger dans la cryptographie (je suis également depuis de nombreuses années dans les solutions de paiement et bancaires). Je pense que nous devons fournir des conseils pratiques / équilibrés car, généralement, les gens évitent d'aller en profondeur dans la cryptographie pour protéger les appareils IoT dans son jardin.
Amit Vujic
1
Si les gens veulent fabriquer des appareils non sécurisés parce qu'ils ne peuvent pas se soucier de savoir comment fabriquer des appareils sécurisés, je ne vois aucune raison de les activer.
Gilles 'SO- arrête d'être méchant'
D'après mon expérience, les gens veulent apprendre, mais encore une fois, il doit y avoir un équilibre entre le niveau de sécurité et la complexité. Il y a une histoire célèbre dans l'industrie du paiement concernant SET ( en.wikipedia.org/wiki/Secure_Electronic_Transaction ) qui est / était très sécurisé mais complexe à mettre en œuvre et à cause de cela a échoué dans la pratique.
Amit Vujic
2
L'obfuscation ajoute de la complexité sans améliorer la sécurité. Ce n'est pas un équilibre.
Gilles 'SO- arrête d'être méchant'