[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:
L'hypothèse selon laquelle les numéros de série matériels sont uniques ne tient probablement pas, et
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 > convenience
et 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 < convenience
et 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.