Les images de firmware pour l'IoT doivent-elles être cryptées pour des raisons de sécurité?
Lorsque vous travaillez avec des appareils Internet of Things, est-il recommandé d'obscurcir ou de crypter les images du micrologiciel transmises aux clients? Cela rend plus difficile l'ingénierie inverse.
(Ils doivent être signés bien sûr)
Certaines personnes soutiennent que le code qui est open source peut être audité par beaucoup et contient donc de petits bugs. D'un autre côté, les attaquants ont le même accès facile et recherchent également ces mêmes vulnérabilités. Il y a certainement un compromis ici qui n'est pas correctement décrit dans les réponses précédentes.
D'autres mentionnent que le code doit être intrinsèquement sécurisé et ne nécessite donc aucune obfuscation/chiffrement/masquage. Il est vrai qu'un système doit être conçu pour être sécurisé même si vous savez comment il fonctionne. Cela ne signifie pas que c'est toujours le cas ET la mise en œuvre est sans faille. En pratique, le code n'est jamais sécurisé à 100%. (Jetez un œil à la sécurité des applications Web: pourquoi avons-nous besoin d'en-têtes de sécurité pour nous protéger contre les attaques XSS et CSRF s'il n'y a pas de vulnérabilités dans l'application Web?) Des mesures de sécurité supplémentaires peuvent être prises en essayant de masquer le code par le chiffrement et l'obscurcissement . Dans le monde mobile, l'ingénierie inverse est même considérée comme un risque sérieux: OWASP Mobile Top 10 risques .
Comme aucun système n'est sécurisé à 100%, nous ne pouvons qu'accroître l'effort requis pour le casser.
Alors maintenant, le compromis entre code open source/code facilement accessible VS code crypté et obscurci. Autoriser la révision publique de votre code source peut aider à réduire le nombre de bogues. Cependant, si vous êtes une petite entreprise où le public est peu incité à auditer librement votre code, il n'y a aucun avantage à publier votre code car personne ne le regardera avec de bonnes intentions. Cependant, il devient beaucoup plus facile pour les attaquants de découvrir des vulnérabilités. (Nous ne parlons pas de la dernière version d'iOS que chaque chercheur en sécurité essaie de résoudre).
Dans ce cas, nous ne parlons même pas de source ouverte du code pour examen public. Nous parlons de crypter le firmware en transit. Les chercheurs en sécurité ne vont probablement pas acheter votre appareil pour obtenir le code permettant de découvrir et de publier des vulnérabilités. Par conséquent, la chance d'avoir les bons gars trouver les vulnérabilités VS les méchants les trouver diminue.
Non. Vous ne devez pas vous fier à l'obscurité de votre micrologiciel pour masquer les failles de sécurité potentielles qui existent peu importe que vous chiffriez/masquiez ou non votre micrologiciel.
J'ai une suggestion radicale: faites exactement le contraire. Rendez vos binaires du micrologiciel accessibles au public et téléchargeables, librement accessibles à tous ceux qui le souhaitent. Ajoutez une page sur votre site avec des détails sur la façon de vous contacter à propos des problèmes de sécurité. Interagissez avec la communauté de la sécurité pour améliorer la sécurité de votre produit.
Douteux, ce serait bénéfique. C'est de loin une meilleure option pour le pousser open-source que la source fermée. Cela peut sembler stupide et même controversé au début, mais l'ouverture d'un projet au public présente de nombreux avantages.
Bien qu'il y ait des gens avec des intentions malveillantes, il y a aussi des gens qui veulent aider et faire d'Internet un meilleur endroit. L'open source permet à plus d'yeux de regarder le projet, non seulement pour voir les fonctionnalités potentielles, les bugs et les problèmes, mais aussi pour augmenter la sécurité et la stabilité de la "chose"
Et être d'accord avec la réponse de Polynomial, s'engager dans une communauté et bâtir une base de personnes qui vous aident avec la sécurité, augmentera la clientèle de manière significative.
Un micrologiciel bien conçu doit s'appuyer sur la force de sa clé d'accès plutôt que sur l'ignorance de l'attaquant de la conception du système. Cela suit le principe fondamental de l'ingénierie de la sécurité connu sous le nom de axiome de Kerckhoffs :
Un système d'information doit être sécurisé même si tout ce qui le concerne, à l'exception de la clé du système, est de notoriété publique.
Le mathématicien américain Claude Shannon recommandé partant de l'hypothèse que "l'ennemi connaît le système", c'est-à-dire "on devrait concevoir des systèmes en supposant que l'ennemi se familiarisera immédiatement avec eux".
Vous serez peut-être intéressé de savoir qu'avant la fin du XIXe siècle, les ingénieurs en sécurité préconisaient souvent obscurité et secret comme moyen valide de sécurisation des informations. Cependant, ces approches antagonistes des connaissances sont antithétiques à plusieurs principes de conception en génie logiciel - en particulier la modularité.
Êtes-vous sûr de ne pas confondre deux méthodes cryptographiques?
Vous devez certainement signer les mises à jour de votre firmware pour des raisons de sécurité. Cela permet à l'appareil de vérifier qu'ils proviennent de vous.
Les crypter ajoute un peu d'obscurité et c'est tout. Étant donné que le dispositif de déchiffrement n'est pas sous votre contrôle, quelqu'un le piratera tôt ou tard, extraira la clé de déchiffrement et la publiera sur Internet.
Dans le sens de "le cryptage du firmware empêchera-t-il la détection de vulnérabilités dans mon code?" d'autres réponses ont abordé le fond de celle-ci: bien qu'elle puisse décourager certains attaquants, la sécurité par l'obscurité conduit à un faux sentiment d'invulnérabilité qui est contre-productif.
Cependant, je voudrais ajouter un peu plus sur la base de mon expérience. J'ai vu que les progiciels sont parfois cryptés, mais la motivation est uniquement de préserver la propriété intellectuelle d'une entreprise, plutôt que d'être un contrôle contre les attaquants.
Bien sûr, les pirates trouvent souvent des moyens de contourner ce "contrôle", mais c'est une autre histoire.
Vous devez vous poser cette question. Quelqu'un est-il assez intelligent et suffisamment intéressé pour télécharger votre firmware et commencer à rechercher des vulnérabilités qui seront dissuadées par une couche de cryptage de firmware supplémentaire où la clé doit être révélée?
C'est juste un autre cerceau à parcourir, pas différent de déterminer le format de disque dans lequel se trouve l'image de votre micrologiciel. Ce n'est même pas un cerceau particulièrement difficile à parcourir. Gardez à l'esprit que toutes les méthodes FAR plus sophistiquées de ce qui équivaut à DRM ont toutes été brisées.
Les chances sont que quelqu'un suffisamment déterminé pour pirater votre cafetière/lave-vaisselle connecté à Internet ne sera pas dissuadé par une couche de cryptage supplémentaire.