Comment sécuriser la communication entre l'application et l'appareil IoT?

Je travaille actuellement sur un projet qui inclut la communication Bluetooth entre une application mobile (utilisant actuellement la plateforme Ionic) et un appareil embarqué. À titre de comparaison, notre produit est similaire à une serrure intelligente .

La sécurité est de la plus haute importance et nous cherchons des moyens de garantir que notre matériel et nos logiciels ne sont pas piratables. Quelles mesures devons-nous prendre pour garantir la sécurité de notre système?

Modifier: Oui, nous chiffrons actuellement les communications et utilisons HTTPS lorsque l'appareil communique avec notre serveur.

Pour vous assurer que votre appareil est suffisamment sécurisé, j'ai quelques conseils:

1. Ajoutez un chiffrement à la communication Bluetooth. Je recommanderais de garder les clés de cryptage hors de portée. Par exemple, vous pouvez demander à l'utilisateur de scanner un code QR qui se trouve sur l'appareil, sur imprimé dans la boîte, etc. lors de la configuration initiale de l'application mobile, peut-être avec une clé AES? Dépend de vous. Il s'agit d'empêcher quelqu'un de voir le mot de passe transmis en direct avec du texte brut.
2. Si vous le pouvez, éloignez-vous du mode ECB (utilisez CBC) de l'algorithme de chiffrement que vous choisissez, car il pourrait donner des informations sur les données transmises. Vous trouverez plus d'informations à ce sujet ici .
3. Lors de la transmission de données Bluetooth, assurez-vous d'inclure un identifiant unique, afin que le message ne puisse pas être répété (par exemple, vous pouvez inclure un horodatage). Vous pouvez également implémenter un système de type TOTP.
4. Mettez un port sur l'appareil qui permet de le flasher facilement, de sorte que si vous réalisez que le logiciel a un bogue (et pour une raison quelconque, vous ne pouvez pas le mettre à jour OTA), l'appareil n'est pas un presse-papier coûteux, juste un appareil qui doit être branché sur un PC et flashé sur un nouveau logiciel.
5. Extra: pour garantir qu'une personne possédant un certificat racine non autorisé (probablement auto-émis et installé sur la machine cliente) ne peut pas intercepter les communications de votre serveur, vérifiez le certificat HTTPS. Voici un SO lui demandant pour Android, vous devez également pouvoir trouver des ressources similaires pour iOS .

De plus, si vous souhaitez en savoir plus sur la cryptologie et le cryptage que vous utiliserez pour sécuriser votre appareil, consultez cet ebook (gratuit) . Il parle beaucoup de bonnes et de mauvaises implémentations d'algorithmes de chiffrement et devrait vous aider à sécuriser votre produit. (Remarque 1: veuillez ne pas créer votre propre algorithme. Remarque 2: je ne suis pas affilié à crypto101 ou lvh.)

Si vous pouvez avoir un TCP de bout en bout, alors utilisez TLS de bout en bout (par exemple avec HTTPS).

Ne réinventez pas la roue, surtout en ce qui concerne la cryptographie - la plupart des gens se trompent. À moins que l'appareil ne soit trop limité en ressources pour prendre en charge TLS, si vous descendez au niveau d'AES, vous vous trompez . L'erreur n ° 1 est de crypter et d'oublier de s'authentifier - si vous avez un canal crypté entre votre serveur et un homme au milieu, au lieu d'un canal crypté entre votre serveur et votre appareil, le cryptage n'a fourni aucun avantage . Si vous ne pouvez pas utiliser TLS, assurez-vous que le protocole que vous utilisez authentifie tout et chiffre ce qui doit être confidentiel.

Pour utiliser TLS en toute sécurité, pensez aux garanties dont vous avez besoin, du point de vue de chaque participant. En général, l'appareil doit savoir qu'il parle au serveur légitime. Cela signifie qu'il doit vérifier le certificat du serveur. Le périphérique doit avoir le certificat X.509 d'une autorité de certification enregistré comme approuvé; cela nécessite un stockage qui ne peut pas être modifié par un attaquant, mais cela ne nécessite aucune confidentialité du stockage. Notez que vous ne devez pas coder en dur le certificat du serveur directement, car cela ne vous permettrait pas de remplacer facilement ce certificat s'il est compromis. Au lieu de cela, l'appareil stocke l' identité attendue(nom d'hôte) du serveur et le certificat d'une autorité de certification qui garantit qu'une certaine clé publique appartient au nom d'hôte attendu. Encore une fois, ne réinventez pas la roue, comptez sur la vérification des certificats fournie par votre bibliothèque ou application TLS.

Si le serveur doit savoir qu'il parle à un client légitime, chaque client doit avoir son propre certificat client. Cela nécessite un stockage confidentiel sur le client. Passez le certificat client à la fonction d'ouverture de session TLS à partir de votre bibliothèque TLS ou définissez-le dans la configuration de l'application.

Cela permet de sécuriser la communication entre votre serveur et votre appareil. Si l'application mobile peut communiquer directement avec l'appareil (par exemple pour permettre un fonctionnement déconnecté alors qu'il est sur le réseau wifi local), vous devez d'abord effectuer le couplage entre le commutateur intelligent et le téléphone mobile. Le pairage signifie un échange de clés, de préférence un échange de clés publiques si les ressources le permettent, sinon un accord de clés secrètes. Le but de cette association est de s'assurer que chaque appareil sait à qui il parle.

Vous devrez également sécuriser le canal de contrôle, qu'il passe directement de l'appareil mobile au commutateur intelligent ou via un serveur. Pensez à l'autorisation: existe-t-il différents niveaux d'accès au commutateur, par exemple un niveau de contrôle qui permet de faire la reconfiguration et un canal de base qui permet simplement la commutation marche / arrêt? Ceci est généralement géré par une étape d'authentification après l'établissement du canal sécurisé (TLS si possible).

Une autre considération est les mises à jour du firmware. C'est délicat: d'une part, la sécurité absolue n'existe pas, vous aurez donc des correctifs de sécurité à appliquer de temps en temps. D'un autre côté, un mécanisme de mise à niveau du firmware est une chose complexe et pourrait lui-même avoir des bugs. À tout le moins, assurez-vous que vos mises à niveau du micrologiciel sont signées. S'appuyer uniquement sur la sécurité du canal de communication pour les mises à niveau est douteux, car la base de confiance pour un canal sécurisé est plus grande que pour une vérification de sécurité statique, et parfois vous souhaiterez peut-être appliquer des mises à jour du micrologiciel sans connexion réseau. En plus de vérifier la signature, vous devriez idéalement avoir une certaine protection contre le retour en arrière, afin qu'un adversaire puisse '