RFC 8240: Informe del taller sobre actualizaciones de software en Internet de las Cosas (IoTSU 2016)

Este texto es una traducción del artículo RFC 8240: Report from the Internet of Things (IoT) Software Update (IoTSU) Workshop 2016 [fr] publicado el 12 de septiembre de 2017 en el blog del especialista en DNS y seguridad Stéphane Bortzmeyer, quien estuvo en La Paz en el mes de abril de 2017 para un seminario sobre seguridad informática. Describe y comenta los resultados del evento de la IETF que tuvo lugar en Dublín en junio de 2016, que trató de la seguridad del Internet de la Cosas, en particular la dificultad de contar con software actualizado para los aparatos conectados, lo que permitió por ejemplo ataques masivos como Mirai [en] que dejó sin Internet a un millón de personas al atacarse a enrutadores. Más allá del caso particular de los pequeños aparatos conectados, enseña muchos conceptos sobre la actualización de software.

Como lo acostumbra hacer Stéphane en su blog [fr], el artículo traducido es una ficha de lectura de un RFC, en este caso el RFC 8240 [en], en la cual repasa todo el contenido y aporta con comentarios sobre el contexto.

Traducción el 19 de septiembre de 2017 por Sylvain Lesage y editado por Natalia Antezana. Publicado bajo la licencia GFDL.

Internet de las Cosas - por <a href="https://pixabay.com/es/users/jeferrb-590530/">jeferrb - CC0</a>

Internet de las Cosas – por jeferrb – CC0

RFC 8240 [en]: Informe del taller 2016 sobre actualización de software para Internet de las Cosas

Fecha de publicación del RFC: Septembre 2017

Autores del RFC : H. Tschofenig (ARM Limited), S. Farrell (Trinity College Dublin)

La moda de los objetos conectados ha llevado a la creación de muchos « objetos », que en realidad son computadoras (con sus problemas, por ejemplo el hecho de que su software tenga fallas de seguridad), pero que no son considerados como tal por sus dueños y entonces no son administrados (no hay administrador de sistemas, no hay actualizaciones del software). El ataque contra Dyn el 21 de octubre de 2016, aparentemente llevado a través de estos objetos, ilustró claramente el riesgo que crea esta profusión irresponsable. Este nuevo RFC es el informe de un taller de reflexión sobre la actualización de los objetos conectados [en], que tuvo lugar en Dublín los días 13 y 14 de junio de 2016. Da un pantallazo sobre esta (difícil) cuestión.

La pregunta de base era « ¿qué podemos hacer para que estos “pinches” objetos estén actualizados, por lo menos para parchear sus fallas de seguridad? ». El taller reunido en el Trinity College obviamente no ha proveído una respuesta perfecta, pero por lo menos permitió clarificar el problema. Me parece sin embargo, a la lectura del informe, que faltó tratar un tema importante: los derechos del dueño del objeto. La mayoría de las soluciones discutidas estaban relacionadas con la idea de actualizaciones sistemáticas y automáticas del software desde los servidores del vendedor, encambio las eventuales consecuencias nefastas para el dueño (como la aparición de nuevas funciones de vigilancia, por ejemplo) son apenas mencionadas.

Hoy en día, un número importante de las máquinas que tienen acceso, aún indirecto, a Internet está compuesto por cosas cualificadas de objetos que solo tienen en común que no se las llama « computadoras » (aunque claramente de eso se trata). Estos objetos son muy diversos y van desde aparatos que tienen las mismas capacidades que una computadora (un televisor conectado, por ejemplo) hasta pequeñas cosas muy restringidas (CPU y memoria limitados, batería con una capacidad finita, etc). El riesgo que hacen pesar estos objetos « irresponsables » (no administrados, no supervisados) sobre el conjunto de Internet es conocido desde tiempo. El RFC cita el artículo de Schneier, « The Internet of Things Is Wildly Insecure And Often Unpatchable [en] », que alertaba sobre el tema en 2014. Notaba que el software de estos objetos ya está desactualizado cuando el objeto sale de su caja la primera vez (a los fabricantes de objetos conectados les encanta usar versiones antediluvianas de las librerías). Sin embargo, estos objetos pueden seguir conectados y activos durante años, con su software obsoleto y nunca actualizado, lleno de fallas de seguridad que muy probablemente los crackers explotaron (cf. el software Mirai).

Por la misma época, un informe de la Comisión Federal de Comercio de Estados Unidos, « FTC Report on Internet of Things Urges Companies to Adopt Best Practices to Address Consumer Privacy and Security Risks [en] » y otro del Grupo de trabajo del artículo 29, « Dictamen 8/2014 sobre la evolución reciente de la Internet de los objetos » hacían las mismas observaciones.

Entonces, el problema es conocido desde años. Pero no es fácil de resolver:

  • El mecanismo de actualización en sí puede ser una falla de seguridad. Por ejemplo, una cierta proporción de objetos actualizan su software en HTTP, sin firma sobre el código recuperado, haciendo de que sea trivial realizar un ataque del hombre del medio.
  • El RFC no lo menciona mucho, pero, aún verificando el código recuperado, este puede ser malicioso. Numerosas compañías (por ejemplo Sony) han distribuido deliberadamente malware a sus clientes sin consecuencias penales. Una actualización automática podría, por ejemplo, instalar una puerta trasera o establecer un código DRM nuevo.
  • Los problemas operacionales no faltan. Si los objetos verifican el código recuperado mediante una firma, que la comparan a una clave pública que detienen, ¿qué deberíamos hacer si la clave privada correspondiente ha sido perdida o copiada? (cf. « Winks Outage Shows Us How Frustrating Smart Homes Could Be [en]. »)
  • Si los objetos se conectan automáticamente al servidor para buscar actualizaciones, genera un serio problema de privacidad (el RFC no hace mención que, además, la mayoría de estos objetos son espías tremendos que instalamos en nuestra casa.)
  • Para una compañía con fines de lucro, administrar la infraestructura de actualización (los servidores, la plataforma de desarrollo, las actualizaciones del código, la gestión de los eventuales problemas) tiene un cierto costo. No existe ninguna motivación financiera para hacerlo porque la seguridad no le brinda nada. (El RFC solo llega a esta conclusión, sin mencionar la solución evidente: reglamentaciones que obliguen a las empresas a hacerlo. El Dios Mercado ciertamente no será una solución).
  • Si la empresa original desfallece ¿quién podría y debería asegurar sus actualizaciones? (Pensemos en la ex-estrella de los medios, el conejo Nabaztag [en] y su abandono por la empresa que lo había vendido.) Aunque el RFC no lo menciona, es obvio que el software libre es la solución al problema del « poder » pero no al problema del « deber » (dicho de otra manera, el software libre es necesario pero no suficiente).

El riesgo entonces, no solo surge de la ausencia de sistema de actualización. Puede venir también de un sistema de actualización con bugs, vulnerable o no documentado, entonces no mantenible.

El problema de la actualización automática de software es obviamente antiguo y varios sistemas operativos tienen soluciones operativas desde un cierto tiempo (como pacman o aptitude). El RFC se focaliza sobre los objetos más restringidos, con limitaciones en sus capacidades materiales y por lo tanto en los software que lograrán hacer correr.

Luego de esta introducción el RFC trata de la terminología porque la elección de las palabras suscitó una discusión en el taller. Primero, la noción de clase. Los « objetos conectados » van de sistemas que tienen las capacidades materiales y la alimentación eléctrica de una computadora de escritorio (un televisor conectado, por ejemplo) y entonces pueden usar las mismas técnicas, hasta objetos mucho más restringidos en sus capacidades. Para tomar unos ejemplos conocidos por los geeks, un Raspberry Pi hace correr un sistema operativo « normal » y se actualiza como una computadora de escritorio; al contrario, un Arduino no lo puede hacer. Entonces, sin duda habrá que desarrollar soluciones diferentes según la clase. O, si queremos clasificar según el tipo de procesador, se pueden separar los objetos que tienen más o menos el equivalente de un Cortex-A [en] (como el Pi) de otros objetos cuyos recursos corresponden a un Cortex-M [en] (como el Arduino).

El RFC también define en la sección 2 la diferencia entre actualización del software y actualización del firmware. La distinción importante es que los aparatos más restringidos en recursos típicamente solo tienen acceso a una actualización del firmware, que cambia todo, sistema y aplicaciones, mientras que los aparatos de clase « superior » tienen actualizaciones modulares (se puede actualizar una aplicación sola).

Último término a retener, hitless (« sin impacto »). Es una propiedad de las actualizaciones que no perjudican el funcionamiento normal. Por ejemplo, si hay que apagar el aparato para una actualización, no será hitless. Obviamente, la actualización del software de un coche probablemente no será hitless y necesitará entonces precauciones particulares.

Ahora, la parte más gruesa del RFC, la sección 3, agrupa en particular las exigencias que resultan del taller. Es un poco desordenado y hay más preguntas que respuestas. Para empezar ¿qué deberían hacer los fabricantes de objetos conectados (si suponemos que leen los RFC y tienen el sentido de las responsabilidades, dos apuestas arriesgadas)? Por ejemplo, el RFC nota que las actualizaciones globales (remplazamos todo) son peligrosas y recomienda que sea posible realizar actualizaciones parciales, en particular para limitar el ancho de banda utilizado en la red (como se hace con bsdiff [en] o courgette [en]). Idealmente se debería poder actualizar una sola librería, pero necesitaría un enlazador dinámico y un código independiente de la posición [en], lo que quizás es pedir mucho para los objetos más pequeños. Pero por lo menos existe un sistema operativo concebido para los « clase M », los objetos más restringidos, llamado Contiki, que contiene un enlazador dinámico.

Ciertos dispositivos industriales tienen varios procesadores, de los cuales uno solo maneja la conexión con el resto del mundo. Puede ser preferible tener una arquitectura donde este procesador se encargue de la actualización del software de sus compañeros que no están directamente conectados.

Un problema más preocupante, porque no es exclusivamente técnico, es el de los aparatos que tienen varios responsables potenciales. Si una maquina sirve para varias funciones existe el riesgo de no poder establecer, dentro de la empresa, qué departamento debe tomar la decisión en cuanto a las actualizaciones. Para las computadoras, esta cuestión social ha sido resuelta desde hace tiempo en la mayoría de las organizaciones (por ejemplo dejando las decisiones al servicio de infraestructura tecnológica) pero los objetos conectados redistribuyen las cartas. Si el servicio Comunicación tiene una cámara conectada, ¿quién puede decidir de actualizarla (o no)?

Un caso cercano es cuando un aparato industrial incluye una computadora comprada a un tercero (con el sistema operativo). ¿Quién tiene que realizar la actualización? ¿Quién es responsable? Pensemos por ejemplo en el problema de Android, para el cual las actualizaciones deben circular desde Google hasta el constructor del teléfono y (a menudo) hasta el operador que lo ha vendido. En la práctica constatamos que Android está mal actualizado. Y será peor para un refrigerado conectado, porque su parte informática estará fabricada independientemente, y antes que el refrigerador esté completo. Cuando este arranque por primera vez, su software ya tendrá por lo menos varios meses de atraso.

¿Y la seguridad? Imaginemos un objeto conectado cuyo fabricante es tan incompetente y tan irresponsable que las actualizaciones se realizan recuperando código en HTTP, sin ningún tipo de autenticación. Este objeto sería muy vulnerable a ataques que apunten a remplazar el código autentico por un código malicioso. Por eso la exigencia de DAO (Data Origin Authentication [en]). Sin DAO, no habría salida. Existen dos soluciones evidentes que utilizan la criptografía: autenticar el servidor que distribuye las actualizaciones (por ejemplo con HTTPS) o autenticar el código descargado, mediante una firma digital (noten que la IETF tiene un formato CMS para eso, descrito en el RFC 4108, pero parece poco utilizado.)

¡Pero firmar y verificar es más fácil de decir que de hacer! Primero, la criptografía no es un problema para los aparatos de « clase A », como un televisor conectado o un automóvil conectado, pero puede ser mucho más costosa para objetos más limitados. La criptografía simétrica generalmente es más barata, pero también menos práctica. El problema de fondo es que la criptografía simétrica no autentica a un remitente, sino a una clase de remitentes (todos los que poseen la clave). Sería necesario tener una clave diferente por objeto, lo que parece inmanejable. ¿Será necesario exigir la criptografía asimétrica como base?

Su costo en operaciones de cálculo no es el único problema. Por ejemplo, la clave privada que firma las actualizaciones puede ser robada, o simplemente volverse demasiado débil con los progresos de la criptoanálisis (ciertos objetos pueden quedar en producción durante diez años o más). Entonces se requiere un medio para actualizar la clave pública. ¿Cómo hacerlo sin introducir nuevas vulnerabilidades? Imaginen un atacante que encontrara una manera de subvertir este mecanismo de remplazo de clave, podría cambiar la clave de firma por la suya. Por lo tanto, los métodos « solo hay que… » del estilo « solo hay que usar firmas criptográficas » no son soluciones mágicas.

¿Y que tal si el objeto utiliza código que proviene de varias fuentes? ¿Habrá que usar varias claves, con reglas complicadas como « la organización A tiene permiso para actualizar los componentes 1, 3 y 4 del sistema; la organización B puede actualizar 2 y 3 »? Nota: los sistemas cerrados son malos para el usuario, pero presentan ventajas en materia de seguridad: una sola fuente. Piensen todos los debates alrededor de la utilización del almacén [en] libre F-Droid, por ejemplo la opinión de Whisper [en].

Un problema más fundamental es la confianza: ¿en quién tiene que confiar un objeto conectado?, o sea ¿qué clave pública debe utilizar para verificar las actualizaciones? ¿Confiar en su dueño? ¿en su fabricante? ¿en la empresa subcontratada por el fabricante?

No terminan aquí los problemas. Los objetos están concebidos para ser fabricados y distribuidos en gran cantidad. Será muy problemático asegurarse que todos los objetos de los cuales uno es responsable están actualizados. Imagínense una fábrica que tiene cientos, hasta miles de objetos idénticos, y quiere saber si todos tienen la misma versión del software.

Antes ya habíamos hablado de confianza. Podemos decidir confiar en el fabricante del objeto, porque juzgamos que esta organización es honesta y competente. Pero esta evaluación no necesariamente se extiende a la totalidad de sus empleados. Cómo asegurarse que un empleado malicioso no va a comprometer el proceso de actualización del software, por ejemplo conservando una copia de la clave privada o añadiendo a los objetos producidos una clave pública adicional, lo que le proveería una puerta trasera en cada objeto. Lo cual nos muestra que la actualización en si también es fuente de vulnerabilidades.

Hemos mencionados los riesgos para la seguridad del objeto conectado, sin embargo las precauciones tomadas actualmente son casi nulas. Esperemos que mejore. Pero, aún con las mayores precauciones, a veces se producirán pirateos. Eso abre la cuestión de la recuperación: ¿cómo recuperar un objeto pirateado? Si tenemos diez tostadoras comprometidas, ¿tendremos que volver a “flashear [en]” cada una manualmente? Antes de eso, existe también la interesante cuestión de saber cómo detectar que hubo pirateo, sabiendo que casi la totalidad de las organizaciones no leen los mensajes [fr] que les avisan de comportamientos sospechosos de sus máquinas.

La criptografía aporta claramente soluciones interesantes a muchos de los problemas de seguridad. Pero generalmente necesita un reloj bien ajustado (como para verificar la fecha de expiración de un certificado). Tener un reloj mantenido por una batería durante el apagón de la máquina y durante los cortes de energía no es trivial:

  • Cuesta caro (la batería y el reloj pueden costar mucho más caro que el resto del objeto),
  • Toma espacio (ciertos objetos realmente son pequeños),
  • Las baterías son equipamientos peligrosos, en razón del riesgo de incendio o de explosión, y su presencia impone unas fuertes restricciones en el proceso de fabricación, en particular tomando en cuenta que estas envejecen rápidamente (no hay forma de usar viejos stocks),
  • Las baterías concebidas para la casa pueden no ser adecuadas, porque en un entorno industrial las condiciones son duras (la temperatura puede exceder fácilmente los límites de una batería ordinaria),
  • Las baterías no duran mucho: la presencia de una batería puede acortar seriamente la vida útil de un objeto conectado.

No necesariamente hay una buena solución para este problema. El RFC cita Roughtime [en] como un enfoque prometedor.

Y si tuviéramos la solución correcta para distribuir las actualizaciones a miles o millones de objetos conectados ¿cómo se enterarían estos de la existencia de una actualización? ¿Push o pull? Enviar las actualizaciones desde el servidor es la solución más rápida, pero puede ser delicada si el objeto está por detrás de un cortafuegos que prohíbe las conexiones entrantes (el objeto tendría que contactar el servidor de actualización y quedarse conectado). Y el caso de los objetos que no están accesibles de manera permanente complica las cosas. Y por otro lado, el caso en el que el objeto contacta el servidor de vez en cuando para saber si hay una actualización que genera otros problemas, por ejemplo de consumir mucha energía en vano.

¿Les parece que ya fueron suficientes problemas? Y aún no termina. Imagínense el caso de una actualización que contiene un bug, lo que sin duda ocurrirá. ¿Cómo volver atrás? ¿Realizar una nueva actualización (el bug puede impedir este proceso)? Lo ideal sería que el objeto almacene dos o tres versiones anteriores de su software localmente, para poder bascular hacia estas viejas versiones en caso de problemas. Pero consume espacio de almacenamiento, que es muy limitado para los objetos conectados.

El consenso del taller fue que las firmas de software (con verificación por el objeto) y la posibilidad de actualizaciones parciales son importantes. Asimismo, los participantes estimaron que es esencial la disponibilidad de una infraestructura de actualización, que pueda funcionar para objetos que no tienen un acceso completo a Internet. Por ejemplo, requiere que una organización tenga una copia local del servidor de actualización, tanto por temas de optimización, de protección de la privacidad y para evitar dar un acceso a Internet a sus objetos.

Hablando de vida privada (RFC 6973 [fr]), hay que notar que los objetos al conectarse a un servidor de actualización exponen ciertas cosas al servidor, lo que puede no ser deseable. Y ciertos objetos están estrechamente ligados a un usuario (todos los gadgets en la casa), agravando el problema. El RFC nota que lo mínimo que hay que hacer es no  enviar un identificador único demasiado fácil, sobre todo en una conexión no cifrada. Pero el RFC menciona con razón que existe un conflicto entre la vida privada y el deseo de los vendedores de ganar plata con los datos de los usuarios.

Hemos hablado más que todo de los riesgos para el objeto si el servidor de actualizaciones es malicioso o pirateado. Ciertos actores del sector van a añadir riesgos para el servidor: por ejemplo, si el software no es libre algunos podrían querer autenticar el objeto, para no distribuir su precioso software privativo a « cualquiera ».

Ya lo mencionamos, pero vale la pena volver sobre el tema: un gran problema de fondo es la autorización (sección 4 del RFC). ¿Quién puede aceptar o rechazar una actualización? Claro, existen buenas razones para rechazarla: las actualizaciones obligatorias son una forma de puerta trasera, porque permiten añadir funciones que no estaban antes y que pueden ser maliciosas. Justo un ejemplo de esto fue citado durante el caso del iPhone de San Bernardino [en] (alguna gente proponía una actualización que el teléfono aplicaría, introduciendo una puerta trasera). Y el RFC recuerda el caso de una actualización forzada de impresoras HP que había suprimido unas funciones útiles, pero que HP ya no quería [en] (la posibilidad de aceptar cartuchos de tinta proveídas por competidores). Otro caso similar, desvelado el día anterior de la publicación del RFC, es el de Tesla activando una nueva función a distancia [en] (era para mejorar el coche, pero es fácil ver que podría haber sido al revés). Y obviamente está el famoso caso de Amazon destruyendo libros a distancia [en].

Tomen un teléfono Android programado por Google, fabricado por LG, vendido por Entel a la sociedad Perez, que lo confía a su empleado Sr Gonzalez. ¿Quién va a decidir sobre las actualizaciones?

Podemos separar las actualizaciones que corrigen una falla de seguridad y las otras: solo las primeras serían aplicadas sistemáticamente. No todos los proveedores de software hacen esta separación, que les obliga a manejar dos líneas de actualización. Sin embargo, en la práctica, la distinción no siempre es fácil y la corrección de una falla puede generar otras.

Por otra parte, ciertos objetos conectados son utilizados en un entorno muy regulado, donde todo, material y software, tiene que seguir un proceso de validación formal antes de estar desplegado (es el caso de los objetos utilizados en los hospitales, por ejemplo). Se generará una inminente tensión entre las dos opciones: «realizar la actualización de emergencia porque corrige una vulnerabilidad » y « no realizar la actualización hasta que se haya vuelto a validar todo, porque este objeto está utilizado para funciones vitales ».

Otro problema chistoso, pero que puede asustar, es el riesgo elevado de una cesación del servicio de actualización de software (sección 5 del RFC). Los vendedores de software no son un servicio público: pueden decidir de dejar de proveer un servicio para unos productos que ya no les interesa (o que compiten con un producto más reciente, que ofrece un mejor margen). O simplemente pueden entrar en bancarrota. ¿Qué hacer frente a este fracaso del capitalismo en manejar los productos que pone en el mercado? El problema es muy frecuente, ya que los objetos conectados pueden seguir en servicio durante años, una eternidad para las direcciones comerciales. A parte del caso del Nabaztag [en] citado más arriba, el RFC menciona el ejemplo de Eye-fi [en[. Un objeto un poco complejo puede incorporar partes hechas por organizaciones muy diferentes, algunas más estables que otras.

¿Se podría imaginar un servicio de recuperación del mantenimiento, por organizaciones especializadas en este recojo de huérfanos? Y si estas organizaciones son empresas con fines de lucro ¿cuál será su modelo de negocio? (El RFC no menciona la posibilidad que pueda ser un servicio público.) ¿Y será que la empresa que abandona un producto aceptara esta transferencia de responsabilidad (ninguna ley la obliga a administrar sus desechos de software)?

Pero, en el caso del software, aparece una significante diferencia si se tratara de software libre o no. Un proyecto de software libre puede caerse (por ejemplo porque el único desarrollador ya se aburrió), pero puede -técnica y jurídicamente- ser recuperado por otra persona. Solo es una posibilidad, no una certeza, y muchos proyectos útiles han sido abandonados porque nadie los ha retomado.

Sin embargo, si el software libre no es una condición suficiente para asegurar un mantenimiento en el largo plazo, es en mi opinión una condición necesaria. A veces, el software está liberado cuando una empresa abandona un producto (el caso del mantenimiento de Little Printer [en] fue un éxito ya que lo recuperaron desarrolladores individuales), a veces la empresa no hace nada y el software está perdido. Para resumir, un sistema de custodia de código [en], para poder ser transmitido en caso de problemas de la empresa original, sería bueno.

Como ocurre seguido en seguridad, un ámbito en el cual no bastan las afirmaciones, ciertas exigencias son contradictorias. Por ejemplo, queremos dar seguridad a las actualizaciones (para evitar que un pirata incluya falsas actualizaciones en el proceso), lo que requiere controles, como las firmas digitales. Pero también queremos asegurar el mantenimiento luego de la muerte de la empresa original. Si un tercero asume el mantenimiento del código, pero no tiene la clave privada que permite firmar las actualizaciones, los objetos las rechazaran… La custodia obligatoria de estas claves puede ser una solución, pero introduce otros riesgos (robo de claves en la notaría).

Una posible solución sería que los aparatos conectados sean programados para cesar todo servicio si no logran realizar una actualización durante N meses, o si el servidor de actualizaciones les dice que el contrato de soporte está terminado. Estas bombas de tiempo serían buenas para la seguridad y para las ventas de los fabricantes. Pero cambiarían el modelo de compra de equipamiento: uno ya no sería dueño de su coche o de su tostadora, sino inquilino temporal. ¡La verdadera obsolescencia programada! Estas bombas durmientes pueden interferir también con otras funciones de seguridad. Por ejemplo, un teléfono debería poder pasar unas llamadas de emergencia aún cuando la suscripción expiró. Sería lógico que esté en capacidad de llamar a los bomberos, aún si su software no ha sido actualizado durante lago tiempo (ver RFC 7406 [en] para una discusión sobre un compromiso similar.)

En una lógica libertaria, este RFC habla poco de la posibilidad de obligaciones legales (como existe un control técnico para los coches, podría existir una obligación de medidas de seguridad cuando uno vende objetos conectados). Como las empresas capitalistas no harán esfuerzos espontáneos para mejorar la seguridad de todos, si no usamos restricciones legales, existe la posibilidad de incentivos, lo discutidos en la sección 6. Algunos son utópicos (« es el interés de todos de mejorar la seguridad, entonces hay que explicar a los capitalistas gentiles el interés de la seguridad, y lo harán gratís »). Una posibilidad es la suscripción: al comprar un objeto conectado, uno tendría que pagar regularmente para actualizarlo. Del punto de vista de la seguridad, es absurdo: es el interés de todos que todas las máquinas estén actualizadas, en cuanto a la seguridad. Con una suscripción, ciertos dueños decidirán no pagar y sus aparatos serán un peligro para todos. (Comparemos con la salud pública: es el interés de los ricos que los pobres accedan a la salud, sino las enfermedades contagiosas se extenderán y tocarán a todo el mundo. Entonces, las vacunas gratuitas no son pura generosidad.)

Uno de los problemas de lo llamado «Internet de las cosas » es que no se sabe mucho de lo que ocurre en él. ¿Cuántos constructores de objetos conectados pueden decir cuántos de sus objetos siguen activos y qué porcentaje está al día en cuanto al software? La sección 7 del RFC trata de la cuestión de las mediciones. Uno de los artículos presentados en el taller [en] notaba que, trece años después del fin de la distribución de un objeto conectado, todavía se detectaba algunos ejemplares activos.

Mantener contacto con estas máquinas no es trivial, porque algunas solo estarán encendidas de manara muy intermitente y otras serán desplegadas en unas redes cerradas. Y sin embargo sería útil, por ejemplo, para saber durante cuánto tiempo más se debe seguir administrando actualizaciones para tal modelo, saber qué problemas se han presentado en el terreno, saber qué máquinas han sido comprometidas, etc.

La solución simple sería que el objeto tenga un identificador único y contacte su fabricante de vez en cuando, dando informaciones sobre si mismo. Obviamente, eso genera grandes problemas de preservación de la privacidad, si el fabricante de cepillos dentales conoce sus costumbres de higiene (« su cepillo no ha sido encendido durante seis meses, enviémosle unas publicidades para un dentista »). Existen técnicas estadísticas que permiten recuperar datos sin revelar todo, como el sistema RAPPOR [en] o EPID [en].

Cualquiera que sea la eficacia de las actualizaciones, no hay duda que a veces unas máquinas serán pirateadas. ¿Cómo manejarlas, a partir de ese momento (sección 9)? Porque seguramente no solo serán uno o dos objetos que se tendrán que reformatear con una copia nueva del sistema operativo. En caso de falla explotada, serán por lo menos cientos o miles de objetos que habrán sido pirateados por un software como Mirai. (Noten que un trabajo – que fracasó – había sido realizado en la IETF sobre la gestión de las maquinas terminales y su seguridad, NEA [en].)

Simplemente el hecho de señalar el problema al usuario, sin abrir una nueva vía de ataque para el phishing, es difícil (el RFC 6561 [fr] propone una solución, pero no está muy usada). Hasta el momento no hay solución para este problema. Sabiendo que las organizaciones con fines de lucro nunca reaccionan cuando se les señala un bot en su red, imaginemos lo que ocurrirá cuando avisemos al usuario de a pie que su tostadora está pirateada y participa a unas ataques por denegación de servicio (como las que usan SNMP [en] o la que apuntó a Brian Krebs [en]).

Antes de llegar a una conclusión muy parcial, nuestro RFC en su sección 10 trata diversos puntos:

  • Muchos gadgets conectados serán abandonados rápidamente, por ya no entregar un servicio útil y no interesarle a su dueño; pero algunos seguirán conectados y posiblemente pirateados. ¿Quién se encargará de estos huérfanos peligrosos?
  • ¿Qué deberá hacer la máquina que ve que no logra realizar sus actualizaciones? ¿Rompernos los oídos como el detector de humo cuando su batería se agota? ¿Se imaginan su cocina cuando diez aparatos gritaran al mismo tiempo « Software update failed. Act now! »? ¿O será que los aparatos tendrán que apagarse automáticamente y silenciosamente? (Los fabricantes adorarán esta solución: para eliminar las viejas máquinas y forzar los clientes a comprar unas nuevas, les bastará con apagar el servidor de actualizaciones.)
  • La criptografía postcuántica es inútil para el momento (y los mecanismos actuales producen firmas enormes, inadecuadas para los objetos restringidos) pero es imposible predecir cuándo se volverá indispensable. ¿Cinco años? ¿Diez años? ¿Nunca? el problema es que, como los objetos conectados quedan mucho tiempo en la naturaleza, existe un riesgo que un objeto sea entregado con criptografía precuántica que sea rota por las computadoras cuánticas durante su vida. Será un gran problema entonces.
  • Finalmente, para los que usan certificados para verificar las firmas, se tiene que notar que pocos verifican las revocaciones (RFC 6961 [en] y asociados). Entonces será difícil, hasta imposible, limitar el impacto si una clave privada de firma es robada.

La sección 11 agrupa las conclusiones del taller. Notaremos que existe poco consenso.

  • Como se trata de la IETF, no fue extraño que los participantes se hayan acordado sobre la utilidad de una solución normalizada para la distribución y la firma de software, con el fin de permitir actualizaciones fiables.
  • Al contrario, no queda claro si esta solución tiene que incluir todo o solamente ciertas partes del sistema (la firma por ejemplo).
  • Algunos mecanismos de « transmisión del poder » son necesarias, por ejemplo para tratar el caso de una empresa muerta, que entrega el mantenimiento de los objetos que ha vendido a una asociación o a un servicio público. Pasar la contraseña root es un ejemplo (muy primitivo).

El anexo B del RFC lista todos los papeles presentados en el taller que están obviamente en línea [en]. Sino, podrán mirar el sitio oficial del taller [en], y un buen resumen de presentación [en]. Les recomiendo también este artículo del IEFT Journal [en], y un muy buen artículo crítico [en] sobre los objetos conectados.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *