Non. Vous ne devez pas vous fier à l'obscurité de votre micrologiciel pour masquer les vulnérabilités de sécurité potentielles qui existent indépendamment du fait que vous cryptez / obscurcissez ou non votre micrologiciel.

J'ai une suggestion radicale : faites exactement le contraire. Rendez les fichiers binaires de votre 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é. Engagez-vous avec la communauté de la sécurité pour améliorer la sécurité de votre produit.

Je doute que ce soit bénéfique. C'est de loin une meilleure option pour le pousser à open-source que fermé. Cela peut sembler idiot et même controversé au début, mais ouvrir 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, bogues et problèmes potentiels, mais aussi pour augmenter la sécurité et la stabilité de la "chose"

Et pour être d'accord avec la réponse de Polynomial, s'engager dans une communauté et la création d'une base de personnes qui vous aident avec la sécurité, augmentera la base de clients d'une marge 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 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 concerne le système, à l'exception de la clé du système, est de notoriété publique.

Le mathématicien américain Claude Shannon a recommandé en partant de l'hypothèse que "l'ennemi connaît le système", c'est-à-dire "on devrait pour 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 l'obscurité et le secret comme moyen valable de sécuriser les informations. Cependant, ces approches antagonistes des connaissances sont antithétiques à plusieurs principes de conception de génie logiciel - en particulier la modularité.

Certaines personnes affirment que le code open source peut être audité par beaucoup et qu'il contient donc de petits bugs. D'autre part, 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 veut pas dire que c'est toujours le cas ET que 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 cryptage et obfuscation . Dans le monde mobile, l'ingénierie inverse est même considérée comme un risque sérieux: Top 10 des risques OWASP Mobile.

Comme aucun système n'est sécurisé à 100%, nous ne pouvons qu'essayer d'augmenter l'effort requis pour le casser.

Alors maintenant, le compromis entre code open source / facilement disponible VS code chiffré et obscurci. Autoriser l'examen public 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 tous les chercheurs en sécurité essaient de déchiffrer) ..

Dans ce cas, nous ne parlons même pas de l'open sourcing du code pour examen public. Nous parlons de crypter le firmware en transit. Les chercheurs en sécurité n'achèteront probablement pas votre appareil pour obtenir le code permettant de découvrir et de publier des vulnérabilités. Par conséquent, les chances que les gentils trouvent les vulnérabilités par rapport aux méchants diminuent.

Ê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 viennent de vous.

Les chiffrer ajoute un peu d'obscurité et c'est tout. Puisque l'appareil de décryptage n'est pas sous votre contrôle, quelqu'un le piratera tôt ou tard, extraira la clé de décryptage et la publiera sur Internet.

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és par une couche de cryptage de firmware supplémentaire où la clé doit être révélée?

Ceci est juste un autre cerceau à franchir, non différent de celui de déterminer le format de disque de votre image de firmware. Ce n'est même pas un cerceau particulièrement difficile à franchir. Gardez à l'esprit que toutes les méthodes FAR plus sophistiquées de ce qui équivaut à DRM ont toutes été brisées.

Il y a des chances qu'une personne suffisamment déterminée pour pirater votre cafetière / lave-vaisselle connectée à Internet ne soit pas dissuadée par un autre couche de chiffrement.

Dans le sens de "le chiffrement du firmware empêchera-t-il la détection de vulnérabilités dans mon code?" d'autres réponses ont abordé le cœur de celui-ci: bien que cela puisse décourager certains attaquants, la sécurité par l'obscurité conduit à un faux sentiment d'invulnérabilité qui est contre-productif.

Cependant, j'aimerais ajouter un peu plus sur le base de mon expérience. J'ai vu que les packages de micrologiciels sont parfois chiffrés, mais la motivation pour cela est uniquement de préserver la propriété intellectuelle d'une entreprise, plutôt que de contrôler les attaquants.

Bien sûr, les pirates trouvent souvent des moyens de contourner cela " control ", mais c'est une autre histoire.

Plusieurs personnes ont dit qu'il ne fallait pas compter sur le brouillage du code en le chiffrant, mais simplement pour le sécuriser. Tout récemment, le cryptage de certains logiciels plutôt critiques dans les iPhones d'Apple a été fissuré (ce qui signifie que les pirates peuvent maintenant voir le code réel, pas plus). Cela a empêché quiconque d'examiner le code pendant trois ans, de sorte que le délai entre la publication et la première fissure a été augmenté de trois ans. Cela semble être une obfuscation très réussie.

Et le chiffrement va très bien avec la signature de code. Ainsi, lorsque votre appareil reçoit un nouveau micrologiciel, il peut rejeter tout faux micrologiciel. Maintenant cette partie n'est pas seulement recommandée, c'est absolument essentiel.