Guadalajara, Jalisco, 29 de agosto de 2022.– Ha pasado ya un año desde que Dan Petro, investigador principal y Allan Cecil, consultor de seguridad de Bishop Fox, la principal autoridad en seguridad ofensiva, dieron una presentación en DEF CON 29 detallando el problema sistémico del uso inseguro de los generadores de números aleatorios (RNG) en la industria del Internet de las Cosas (IoT). El resumen es que los dispositivos IoT eligen sistemáticamente números aleatorios para su uso en contextos de seguridad, como las claves criptográficas, de una manera que puede predecirse, incluso cuando se utiliza un periférico de hardware RNG dedicado.

A continuación se presenta cómo se ha adaptado el ecosistema desde entonces.

Sistemas operativos IoT: Soporte del subsistema CSPRNG

La recomendación de primer nivel que los expertos de Bishop Fox dieron el año pasado fue que la mejor manera de garantizar la seguridad de la aleatoriedad es mediante el uso de un subsistema generador de números pseudo aleatorios criptográficamente seguro (CSPRNG), y esto sigue siendo cierto hoy. Lo que esto hace para un desarrollador es proporcionar una pequeña y agradable API que nunca se bloquea y siempre produce números aleatorios de forma segura. No hay que preocuparse por el hardware, no hay resultados inconsistentes. Sólo se tiene que llamar a la API y ya está.

Sin embargo, su implementación puede ser bastante compleja, por lo que se recomienda a los desarrolladores de dispositivos IoT que no lo hagan por su cuenta. El lugar donde es más probable encontrarlas disponibles para su uso es en uno de los muchos sistemas operativos emergentes de IoT como Mbed OS y Keil.  La buena noticia es que cada uno de los principales sistemas operativos de IoT ha implementado un subsistema CSPRNG o está en camino de hacerlo.

¿Qué pasa si no se tiene un sistema operativo para el IoT?

Si se está empezando un nuevo producto IoT desde cero, Petro y Cecil recomiendan encarecidamente que se utilice uno de los sistemas operativos IoT mencionados anteriormente, ya que pueden proporcionar el andamiaje necesario para ayudar tanto al desarrollo ordinario como a la seguridad. Sin embargo, si un proyecto existente no puede cambiar, entonces se podría utilizar un subsistema CSPRNG sin un importante esfuerzo de ingeniería.

El proyecto Mbed TLS ha construido una excelente implementación de un CSPRNG que está disponible para su uso en la mayoría de las plataformas. La API para mbedtls_ctr_drbg_random acumulará entropía de una variedad de fuentes, incluyendo periféricos RNG de hardware, y lo suavizará todo en un flujo de bits de alta calidad de un CSPRNG. De hecho, esta API es la que tienen bajo el cofre la mayoría de los sistemas operativos de IoT mencionados anteriormente.

¿Y si no tiene un periférico RNG de hardware?

Si se está desarrollando un nuevo dispositivo desde cero que realice operaciones relevantes para la seguridad, la recomendación es que se elija un chip que tenga un periférico RNG dedicado. Sin embargo, no todos los chips disponen de esta característica y puede que el proyecto esté demasiado avanzado como para cambiarlo. Si este es el caso, ¿qué opciones se tienen?

Por suerte, hay algunas estrategias para generar entropía incluso en máquinas que no contienen un RNG de hardware dedicado. Los expertos de Bishop Fox han recopilado una lista de algunas y su respectivas fortalezas relativas. Esta lista puede consultarse en este blog.

Hay que sumarlos

La seguridad no suele ser una tarea lineal aditiva. Si se trata de proteger una aplicación web contra fallos de inyección, dos cortafuegos de aplicaciones web juntos no son mucho más seguros que uno solo. Pero por suerte, cuando se trata de generar entropía para un RNG, se pueden juntar diversas fuentes malas para formar una buena.

Cuando se tiene una mala fuente de entropía, cada vez que se genera un número aleatorio, la mitad de los bits son totalmente predecibles. Si se intenta crear un número aleatorio de 128 bits, sólo se obtendrá 64 bits de entropía real. Para evitar esta situación se puede ejecutar el generador una segunda vez y hacer un hash de los valores:

Hash(NúmeroAleatorioUno) xor Hash(NúmeroAleatorioDos) = entropía fuerte

Así de sencillo se puede pasar de una fuente de entropía débil a una fuerte.

Por lo tanto, incluso las fuentes de entropía débiles pueden ser útiles si se utilizan adecuadamente. Se debe agregar continuamente a la reserva de entropía a medida que la entropía adicional esté disponible y sólo utilizar la salida del CSPRNG, nunca de la propia raw source de la entropía. Cada fuente de entropía que se añada a la reserva es puramente aditiva en términos de seguridad.

Conclusión

Ya no hay excusa: se debe utilizar un subsistema CSPRNG en los dispositivos IoT. Hay soporte de software, y el hardware está fácilmente disponible. La información anterior puede ayudar a tomar decisiones de ingeniería sobre la mejor forma de hacerlo.