Realizar actualizaciones inalámbricas seguras y sólidas por aire (OTA) para sistemas integrados implementados de forma remota requiere la experiencia y la tecnología adecuadas.
Realizar actualizaciones inalámbricas seguras y sólidas por aire (OTA) para sistemas integrados implementados de forma remota requiere la experiencia y la tecnología adecuadas.
A medida que crece la cantidad de sistemas integrados conectados, un aspecto que a menudo se pasa por alto es el mecanismo de actualización del software. La atención se centra en las aplicaciones y funciones en las que los desarrolladores deberían dedicar su tiempo, pero esto significa que el mecanismo de actualización está en un segundo plano.
Muchos desarrolladores asumen que el mecanismo de actualización no es demasiado difícil. Después de todo, “solo está copiando los archivos en el destino”. La realidad, como suele ser el caso especialmente con las actualizaciones inalámbricas por aire (OTA), es mucho más compleja. Desafortunadamente, esta percepción simplista de los mecanismos de actualización ha llevado a muchos equipos integrados a desarrollar sus propios actualizadores, robándoles el tiempo que realmente dedican a construir sus productos. El gráfico a continuación muestra un desglose de los costos de software/firmware típicamente asociados con los sistemas integrados.
Como se muestra arriba, el costo se encuentra principalmente en los niveles inferiores donde hay opciones de código abierto disponibles. Construir un mecanismo de actualización OTA desde cero debería ser una reliquia del pasado. Mender.io
También tienen la mayor responsabilidad de garantizar que los sistemas integrados en red sean seguros, utilizando mecanismos confiables para parchear las vulnerabilidades de seguridad. Las muchas historias de la vida real de dispositivos médicos conectados, automóviles conectados y cerraduras inteligentes comprometidas deberían hacer sonar las alarmas para cualquier persona involucrada en proyectos integrados que requieran conectividad del dispositivo de destino. La creación de un mecanismo de actualización suele ser una ocurrencia tardía y, debido a las presiones del tiempo de comercialización y los plazos de lanzamiento, los mecanismos OTA generalmente se ensamblan con prisa.
Consideremos algunos requisitos importantes del mecanismo de actualización.nuestro papel blanco original Este tema agrupa estos requisitos en cuatro categorías amplias: seguridad, robustez, gestión de flotas e integración del entorno existente. Esta columna solo trata sobre robustez y seguridad.
Robustez
Un escenario común que hace que un dispositivo falle (es decir, deje de funcionar por completo) es una pérdida de energía o de red durante una actualización. Uno de los peores escenarios posibles es que uno o más dispositivos se implementen de forma remota y queden inutilizables y bloqueados debido a una interrupción durante una actualización. Dados los desastrosos resultados, la resiliencia y la confiabilidad del proceso de actualización deberían ser su principal preocupación. La pérdida de red o de energía es muy común en los sistemas integrados de campo. Así que este es un riesgo muy real durante el proceso de actualización.
Esta es también una de las razones por las que los sistemas integrados necesitan una instalación atómica de actualizaciones. Esto instalará la actualización completamente o no la instalará. Las instalaciones parciales pueden provocar incoherencias en los dispositivos implementados de forma remota. Si su flota de dispositivos tiene diferentes actualizaciones y sus dispositivos de producción no coinciden con su entorno de prueba, las cosas pueden volverse caóticas rápidamente. Por lo tanto, en los sistemas integrados, es una buena práctica evitar las actualizaciones no atómicas, ya que comprometen la integridad.
Las actualizaciones basadas en paquetes son comunes para el software tradicional de Linux (como apt y yum), pero Linux incorporado evita este enfoque debido a muchos problemas. Por ejemplo, es difícil administrar un conjunto coherente de paquetes instalados en un conjunto de dispositivos. Además, la cantidad de combinaciones de paquetes instalados puede conducir a una pesadilla de control de calidad (QA). El sistema de embalaje es frágil. Si el post-trigger/script falla, la instalación del paquete en sí fallará. Y esto probablemente no sea un completo fracaso. En otras palabras, un paquete parcialmente instalado puede bloquear la instalación de nuevos paquetes diseñados para actualizarlo y corregirlo. Administrar paquetes individuales puede volverse difícil fácilmente, y la necesidad de probar cada combinación de paquetes instalados para cada versión se convierte en una tarea enorme, por lo que debe prestar mucha atención a los detalles. Esto también afecta si las actualizaciones se pueden implementar de manera oportuna.
La capacidad de revertir de manera confiable es otro requisito clave. Es muy común que las compilaciones integradas de Linux CI generen un sistema de archivos raíz completo. El uso de un enfoque de banco dual es, por lo tanto, una de las formas más fáciles y confiables de garantizar que su sistema integrado sea sólido frente a reversiones a otros sistemas de archivos raíz.
Un proveedor de cerraduras inteligentes respaldado y promocionado por Airbnb proporcionó una actualización incorrecta de una cerradura de generación anterior, lo que provocó que el dispositivo dejara de funcionar. Luego, después de recibir la actualización incorrecta, no pudo comunicarse con el servidor y no se revirtió automáticamente, por lo que quedó bloqueado e inutilizable.
Por lo tanto, el enfoque del sistema de archivos de doble raíz no solo hace que el dispositivo real sea más resistente, sino que también simplifica el sistema de construcción al construir todos los paquetes de una manera confiable y predecible.
También se requiere una verificación de coherencia para evitar dañar los artefactos actualizados. Debido a problemas de transferencia o de hardware, se deben evitar las roturas de principio a fin, desde el sistema de construcción hasta el dispositivo de destino. Cambiar las actualizaciones aleatoriamente puede hacer que las aplicaciones funcionen mal, evitar que las aplicaciones se inicien correctamente o bloquear su dispositivo.
seguridad
Las preocupaciones de seguridad acompañan naturalmente a la exageración de IoT. Los dispositivos conectados desempeñaron un papel directo en el aumento del 91 % de los ataques DDoS en 2017. Esto se debió a la mala seguridad de IoT, ya que los actores malintencionados crearon grandes ejércitos de botnets utilizando dispositivos IoT inseguros.
Hay dos requisitos de seguridad principales con respecto al mecanismo de actualización. El primero es la firma de código (verificación criptográfica). Esto permite un control estricto sobre quién puede reprogramar componentes sensibles en los dispositivos de destino. Esto a menudo se pasa por alto, como lo demuestran Chevy (2010) y Tesla (2016). Ninguno tenía firma de código en ese momento y ambos estaban comprometidos.
Otro requisito de seguridad es garantizar que solo se use comunicación cifrada entre el servidor de implementación y los dispositivos de destino. Se requiere una comunicación autenticada bidireccional entre el cliente y el servidor para evitar el riesgo de que las actualizaciones se modifiquen en tránsito. Esto permite que los ataques inyecten código malicioso y se apoderen del dispositivo de destino. Este tipo de ataque es particularmente susceptible en redes inalámbricas, ya que puede imitar un servidor de actualización y forzar la instalación de actualizaciones maliciosas.
Referencias
Realizar actualizaciones inalámbricas seguras y sólidas por aire (OTA) requiere la experiencia y la tecnología adecuadas. Para obtener más información, lea el documento técnico original. Costos ocultos de actualizaciones de software y actualizadores locales para IoT.