¿Se deben cifrar las imágenes de firmware para IoT por razones de seguridad?

Algunas personas argumentan que el código que es de código abierto puede ser auditado por muchos y por lo tanto contiene pequeños errores. Por otro lado, los atacantes tienen el mismo acceso fácil y también buscan estas mismas vulnerabilidades. Definitivamente hay una compensación aquí que no se describe correctamente en las respuestas anteriores.

Otros mencionan que el código debe ser intrínsecamente seguro y, por lo tanto, no requiere ofuscación / cifrado / ocultación. Es cierto que un sistema debe estar diseñado para ser seguro, incluso si sabe cómo funciona. Esto no significa que este sea siempre el caso Y la implementación es impecable. En la práctica, el código nunca es 100% seguro. (Eche un vistazo a la seguridad de la aplicación web: ¿Por qué necesitamos encabezados de seguridad para protegernos contra los ataques XSS y CSRF si no hay vulnerabilidades en la aplicación web?) Se pueden tomar medidas de seguridad adicionales al tratar de ocultar el código a través del cifrado y la ofuscación. . En el mundo móvil, la ingeniería inversa incluso se ve como un riesgo grave: OWASP Mobile Top 10 risk .

Como ningún sistema es 100% seguro, solo podemos intentar aumentar el esfuerzo requerido para romperlo.

Así que ahora, el compromiso entre el código de código abierto / código de fácil acceso VS encriptado y codificado. Permitir la revisión pública de su código fuente puede ayudar a reducir la cantidad de errores. Sin embargo, si usted es una pequeña empresa en la que el público tiene pocos incentivos para auditar libremente su código, no hay ningún beneficio al publicar su código ya que nadie lo verá con buenas intenciones. Sin embargo, es mucho más fácil para los atacantes descubrir vulnerabilidades. (No estamos hablando de la última versión de iOS que todos los investigadores de seguridad están tratando de descifrar) ..

En este caso, ni siquiera estamos hablando de código abierto para su revisión pública. Estamos hablando de cifrar el firmware en tránsito. Es probable que los investigadores de seguridad no compren su dispositivo para obtener el código para descubrir y publicar vulnerabilidades. Por lo tanto, la posibilidad de que los chicos buenos encuentren las vulnerabilidades frente a los chicos malos que los encuentran disminuye.

No. No debe confiar en la oscuridad de su firmware para ocultar las posibles vulnerabilidades de seguridad que existen independientemente de si está o no cifrado / ofuscado su firmware.

Tengo una sugerencia radical: haga exactamente lo contrario. Haga que sus binarios de firmware estén disponibles públicamente y se puedan descargar, y que estén disponibles para cualquier persona que los desee. Agregue una página en su sitio con detalles sobre cómo contactarlo sobre problemas de seguridad. Póngase en contacto con la comunidad de seguridad para mejorar la seguridad de su producto.

Dudoso sería beneficioso. Es, con mucho, una mejor opción para empujar el código abierto que el código cerrado. Puede parecer tonto e incluso polémico al principio, pero abrir un proyecto al público tiene muchos beneficios.

Si bien hay personas con intenciones maliciosas, también hay personas que desean ayudar y hacer de Internet un lugar mejor. El código abierto permite que más personas vean el proyecto, no solo para ver las posibles características, errores y problemas, sino que también aumentan la seguridad y la estabilidad de la "cosa".

Y para estar de acuerdo con la respuesta de Polynomial, participar en una comunidad y construir una base de personas que lo ayuden con seguridad, aumentará la base de clientes en un margen significativo.

Un firmware bien diseñado debe confiar en la fuerza de su clave de acceso en lugar de confiar en la ignorancia del diseño del sistema por parte del atacante. Esto sigue el principio de ingeniería de seguridad fundacional conocido como axioma de Kerckhoffs :

  

Un sistema de información debe ser seguro incluso si todo lo relacionado con el   El sistema, excepto la clave del sistema, es de conocimiento público.

El matemático estadounidense Claude Shannon recomendó a partir de la suposición de que "el el enemigo conoce el sistema ", es decir," uno debe diseñar sistemas bajo el supuesto de que el enemigo se familiarice de inmediato con ellos ".

Le puede interesar saber que antes de finales del siglo XIX, los ingenieros de seguridad a menudo defendían la oscuridad y secreto como válida Medios de obtención de información. Sin embargo, estos enfoques antagónicos al conocimiento son antitéticos a varios principios de diseño de ingeniería de software, especialmente la modularidad.

¿Está seguro de que no está confundiendo dos métodos criptográficos?

Por supuesto, debes firmar tus actualizaciones de firmware por razones de seguridad. Esto permite que el dispositivo verifique que son de usted.

Para cifrarlos se agrega un poco de oscuridad y eso es todo. Debido a que el dispositivo de descifrado no está bajo su control, alguien, tarde o temprano, lo pirateará, extraerá la clave de descifrado y lo publicará en Internet.

Necesitas hacerte esta pregunta. ¿Alguien lo suficientemente inteligente y lo suficientemente interesado como para descargar su firmware y comenzar a buscar vulnerabilidades va a ser disuadido por una capa de cifrado de firmware adicional donde se debe revelar la clave?

Este es solo otro aro para saltar, no es diferente a averiguar en qué formato de disco se encuentra la imagen de firmware. Este no es un aro particularmente difícil de saltar. Tenga en cuenta que todos los métodos FAR más sofisticados de lo que equivale a DRM se han roto.

Es probable que alguien con la suficiente capacidad para piratear tu cafetera / lavaplatos conectado a Internet no sea disuadido por una capa de encriptación adicional.

En el sentido de "¿el cifrado del firmware evitará la detección de vulnerabilidades en mi código?" otras respuestas han abordado su núcleo: aunque puede desalentar a algunos atacantes, la seguridad a través de la oscuridad conduce a un falso sentimiento de invulnerabilidad que es contraproducente.

Sin embargo, me gustaría agregar un poco más sobre la base de mi experiencia. He visto que los paquetes de firmware a veces están encriptados, pero la motivación es preservar la propiedad intelectual de una empresa, en lugar de ser un control contra los atacantes.

Por supuesto, los hackers a menudo encuentran maneras de evitar este "control", pero esa es una historia diferente.

Varias personas dijeron que no deberías confiar en ofuscar el código al encriptarlo, sino simplemente hacerlo seguro. Recientemente, el cifrado de algún software bastante crítico en los iPhones de Apple se rompió (lo que significa que los piratas informáticos ahora pueden ver el código real, no más). Impidió que alguien examinara el código durante tres años, por lo que el tiempo desde el lanzamiento hasta la primera grieta se ha incrementado en tres años. Eso parece una ofuscación muy exitosa.

Y el cifrado va muy bien junto con la firma de código. Entonces, cuando su dispositivo recibe un nuevo firmware, puede rechazar cualquier firmware falso. Ahora, esa parte no solo se recomienda, eso es absolutamente esencial.