Cuando Ryan Castellucci adquirió recientemente paneles solares y un sistema de almacenamiento de baterías para su casa en las afueras de Londres, se sintió atraído por la posibilidad de utilizar un panel de control de código abierto para supervisar y controlar el flujo de electricidad que se generaba. En cambio, obtuvo mucho, mucho más: unos 200 megavatios de capacidad programable para cargar o descargar a la red a voluntad. Esa es suficiente energía para abastecer a aproximadamente 40.000 hogares. Castellucci, cuyos pronombres son ellos/ellas, adquirió este notable control después de obtener acceso a la cuenta administrativa de GivEnergy, el proveedor de gestión de energía con sede en el Reino Unido que suministró los sistemas. Además del control sobre aproximadamente 60.000 sistemas instalados, la cuenta de administrador, que equivale al control raíz de los productos conectados a la nube de la empresa, también les permitió enumerar nombres, direcciones de correo electrónico, nombres de usuario, números de teléfono y direcciones de todos los demás clientes de GivEnergy (algo que el investigador en realidad no hizo). “Mi plan es configurar Home Assistant e integrarlo con eso, pero mientras tanto, decidí dejarlo hablar con la nube”, escribió Castellucci el jueves, refiriéndose al equipo recientemente instalado. “Configuré una carga programada, luego comencé a experimentar con la API. La noche siguiente, tenía el control de una planta de energía virtual compuesta por decenas de miles de baterías conectadas a la red”. Todavía roto después de todos estos años La causa de la omisión de autenticación que descubrió Castellucci fue una interfaz de programación que estaba protegida por una clave criptográfica RSA de solo 512 bits. La clave firma tokens de autenticación y es el equivalente aproximado de una clave maestra. Los tamaños de bits permitieron a Castellucci factorizar la clave privada que sustenta toda la API. La factorización requirió $ 70 en costos de computación en la nube y menos de 24 horas. GivEnergy introdujo una solución dentro de las 24 horas posteriores a que Castellucci revelara privadamente la debilidad. El primer caso conocido públicamente de factorización RSA de 512 bits se produjo en 1999 por un equipo internacional de más de una docena de investigadores. La hazaña requirió siete meses de una supercomputadora y de cientos de otras computadoras. En 2009, los aficionados dedicaron unas tres semanas a factorizar 13 claves de 512 bits que protegían el firmware de las calculadoras de Texas Instruments contra la copia. En 2015, los investigadores demostraron la factorización como servicio, un método que utilizaba la computación en la nube de Amazon, costaba 75 dólares y tardaba unas cuatro horas. A medida que ha aumentado la capacidad de procesamiento, los recursos necesarios para factorizar claves se han vuelto cada vez menores. Es tentador culpar a los ingenieros de GivEnergy por atribuir la seguridad de su infraestructura a una clave que es fácil de descifrar. Sin embargo, Castellucci dijo que la responsabilidad se asigna mejor a los creadores de las bibliotecas de código en las que confían los desarrolladores para implementar procesos criptográficos complejos. “Esperar que los desarrolladores sepan que el RSA de 512 bits es inseguro claramente no funciona”, escribió el investigador de seguridad. “No son criptógrafos. Ese no es su trabajo. El fracaso no fue que alguien utilizara el RSA de 512 bits. Fue que una biblioteca en la que confiaban se lo permitió”. Castellucci señaló que OpenSSL, la biblioteca de código criptográfico más utilizada, todavía ofrece la opción de usar claves de 512 bits. Lo mismo ocurre con la biblioteca de cifrado Go. Casualmente, la biblioteca de cifrado Python eliminó la opción hace solo unas semanas (la confirmación del cambio se realizó en enero). En un correo electrónico, un representante de GivEnergy reforzó la evaluación de Castellucci, escribiendo: En este caso, el enfoque de cifrado problemático fue recogido a través de una biblioteca de terceros hace muchos años, cuando éramos una pequeña empresa emergente con solo 2 desarrolladores de software bastante jóvenes y experiencia limitada. Su suposición en ese momento era que debido a que este cifrado estaba disponible dentro de la biblioteca, era seguro de usar. Este enfoque se transmitió a través de los años intermedios y esta parte de la base de código no se modificó significativamente desde la implementación (por lo que no había pasado por la revisión del equipo más experimentado que tenemos ahora).