Portabilidad de la biblioteca de actualizaciones AWS IoT over-the-air (OTA)

Con las actualizaciones de Freertos over-the-air (OTA), puede hacer lo siguiente:

• Implementar nuevas imágenes de firmware en un único dispositivo, grupo de dispositivos o toda la flota.

• Implementar firmware en dispositivos a medida que estos se añaden a grupos, restablecen o reaprovisionan.

• Verificar la autenticidad y la integridad del nuevo firmware una vez implementado en los dispositivos.

• Monitorizar el progreso de una implementación.

• Depurar una implementación infructuosa.

• Firme digitalmente el firmware mediante la firma de código para AWS IoT.

Para obtener más información, consulte las actualizaciones inalámbricas de FreeRTOS en la Guía del usuario de FreeRTOS junto con la documentación de la actualización O.AWS IoT ver-the-air

Puede utilizar la biblioteca de actualizaciones OTA para integrar la funcionalidad OTA en sus aplicaciones de FreeRTOS. Para obtener más información, consulte Biblioteca de actualizaciones OTA de FreeRTOS en la Guía del usuario de FreeRTOS.

Los dispositivos con FreeRTOS deben aplicar la verificación de la firma de código criptográfica de las imágenes de firmware OTA que reciban. Le recomendamos los siguientes algoritmos:

• Algoritmo de firma digital de curva elíptica (ECDSA)

• Curva NIST P256

• Hash SHA-256

Requisitos previos

• Complete las instrucciones que se indican en Configuración del espacio de trabajo y el proyecto para la portabilidad.

• Cree un puerto de interfaz de transporte de red.

  Para obtener más información, consulte Portabilidad de la interfaz de transporte de red.

• Integre la biblioteca coreMQTT. Consulte la Biblioteca coreMQTT en la Guía del usuario de FreeRTOS.

• Cree un cargador de arranque compatible con actualizaciones OTA.

Portabilidad de la plataforma

Debe proporcionar una implementación de la capa de abstracción portátil (PAL) OTA para realizar la portabilidad de la biblioteca OTA a un dispositivo nuevo. Las API PAL se definen en el archivo ota_platform_interface.h, para lo cual se deben proporcionar detalles específicos de la implementación.

Nombre de la función	Descripción
otaPal_Abort	Detiene una actualización OTA.
otaPal_CreateFileForRx	Crea un archivo para almacenar los fragmentos de datos recibidos.
otaPal_CloseFile	Cierra el archivo especificado. Esto puede autenticar el archivo si se utiliza almacenamiento con protección criptográfica.
otaPal_WriteBlock	Escribe un bloque de datos en el archivo especificado en el desplazamiento dado. Si se completa correctamente, la función devuelve el número de bytes escritos. De lo contrario, la función devuelve un código de error negativo. El tamaño del bloque siempre será una potencia de dos y estará alineado. Para obtener más información, consulte Configuración de la biblioteca OTA.
otaPal_ActivateNewImage	Activa o lanza la nueva imagen de firmware. Para algunas portabilidades, si el dispositivo se restablece de forma síncrona mediante programación, esta función podría no retornar.
otaPal_SetPlatformImageState	Hace lo que requiera la plataforma para aceptar o rechazar la imagen (o paquete) de firmware OTA más reciente. Para implementar esta función, consulte los detalles y la arquitectura de la placa (plataforma) en la documentación.
otaPal_GetPlatformImageState	Obtiene el estado de la imagen de actualización OTA.

Implemente las funciones de esta tabla si su dispositivo tiene compatibilidad integrada para ellas.

Nombre de la función	Descripción
otaPal_CheckFileSignature	Verifica la firma del archivo especificado.
otaPal_ReadAndAssumeCertificate	Lee el certificado de firma especificado del sistema de archivos y lo devuelve al intermediario.
otaPal_ResetDevice	Restablece el dispositivo.

nota

Asegúrese de disponer de un cargador de arranque compatible con actualizaciones OTA. Para obtener instrucciones sobre cómo crear el cargador de arranque de AWS IoT , consulte Cargador de arranque del dispositivo con IoT.

Pruebas E2E y PAL

Ejecución de las pruebas OTA PAL y E2E.

Pruebas E2E

La prueba integral (E2E) OTA se utiliza para verificar la capacidad OTA de un dispositivo y simular escenarios a partir de la realidad. Esta prueba incluirá la gestión de errores.

Requisitos previos

Para realizar la portabilidad de esta prueba, necesita lo siguiente:

• Un proyecto con una biblioteca AWS OTA integrada. Consulte la Guía de portabilidad de la biblioteca OTA para obtener información adicional.

• Realice la portabilidad de la aplicación de demostración con la biblioteca OTA para interactuar con AWS IoT Core para realizar las actualizaciones OTA. Consulte Portabilidad de la aplicación de demostración OTA.

• Configure la herramienta de IDT. Esto ejecuta la aplicación host E2E OTA para crear, instalar y supervisar el dispositivo con diferentes configuraciones, y valida la integración de la biblioteca OTA.

Portabilidad de la aplicación de demostración OTA

La prueba E2E OTA debe tener una aplicación de demostración OTA para validar la integración de la biblioteca OTA. La aplicación de demostración debe tener la capacidad de realizar actualizaciones de firmware OTA. Puede encontrar la aplicación de demostración de FreeRTOS OTA en el repositorio de FreeRTOS. GitHub Le recomendamos que utilice la aplicación de demostración como referencia y que la modifique según sus especificaciones.

Pasos de la portabilidad

1. Inicialice el agente de OTA.

2. Implemente la función de devolución de llamada de la aplicación OTA.

3. Cree la tarea de procesamiento de eventos del agente OTA.

4. Inicie el agente OTA.

5. Supervise las estadísticas del agente OTA.

6. Apague al agente OTA.

Consulte FreeRTOS OTA over MQTT - Entry point of the demo para obtener instrucciones detalladas.

Configuración

Se necesitan las siguientes configuraciones para interactuar con: AWS IoT Core

• AWS IoT Core credenciales de cliente

  • Configure democonfigROOT_CA_PEM en Ota_Over_Mqtt_Demo/demo_config.h con los puntos de conexión de Amazon Trust Services. Consulte server-authentication de AWS para obtener más información.

  • Configure DemoConfigClient_Certificate_PEM y DemoConfigClient_Private_KEY_PEM con las credenciales de su cliente. Ota_Over_Mqtt_Demo/demo_config.h AWS IoT Consulte los detalles de client-authentication de AWS para obtener información sobre los certificados de cliente y las claves privadas.

• Versión de la aplicación

• Protocolo de control OTA

• Protocolo de datos OTA

• Credenciales de firma de código

• Otras configuraciones de bibliotecas OTA

Puede encontrar la información anterior en las aplicaciones de demostración OTA de FreeRTOS demo_config.h y ota_config.h. Consulte FreeRTOS OTA over MQTT - Setting up the device para obtener más información.

Verificación de la creación

Ejecute la aplicación de demostración para ejecutar el trabajo OTA. Cuando se complete correctamente, podrá seguir ejecutando las pruebas E2E OTA.

La demostración OTA de FreeRTOS proporciona información detallada sobre la configuración de un cliente OTA y un trabajo de OTA en el AWS IoT Core simulador de Windows de FreeRTOS. AWS OTA es compatible con los protocolos MQTT y HTTP. Consulte los siguientes ejemplos para obtener más detalles:

• Demostración de OTA sobre MQTT en el simulador de Windows

• Demostración de OTA sobre HTTP en el simulador de Windows

Ejecución de pruebas con la herramienta IDT

Para ejecutar las pruebas OTA E2E, debe utilizar AWS IoT Device Tester (IDT) para automatizar la ejecución. Consulte AWS IoT Device Tester para FreeRTOS en la Guía del usuario de FreeRTOS para obtener más información.

Casos de prueba E2E

Caso de prueba	Descripción
OTAE2EGreaterVersion	Prueba de la ruta de Happy para actualizaciones periódicas OTA. Crea una actualización con una versión más reciente, que el dispositivo actualiza correctamente.
OTAE2EBackToBackDownloads	Esta prueba crea 3 actualizaciones OTA consecutivas. Se espera que el dispositivo se actualice 3 veces consecutivas.
OTAE2ERollbackIfUnableToConnectAfterUpdate	Esta prueba verifica que el dispositivo vuelva al firmware anterior si no puede conectarse a la red con el nuevo firmware.
OTAE2ESameVersion	Esta prueba confirma que el dispositivo rechaza el firmware entrante si la versión sigue siendo la misma.
OTAE2EUnsignedImage	Esta prueba verifica que el dispositivo rechaza una actualización si la imagen no está firmada.
OTAE2EUntrustedCertificate	Esta prueba verifica que el dispositivo rechaza una actualización si el firmware está firmado con un certificado que no es de confianza.
OTAE2EPreviousVersion	Esta prueba verifica que el dispositivo rechaza una versión de una actualización anterior.
OTAE2EIncorrectSigningAlgorithm	Los diferentes dispositivos admiten diferentes algoritmos de firma y hash. Esta prueba verifica que el dispositivo no supera la actualización OTA si se creó con un algoritmo no compatible.
OTAE2EDisconnectResume	Esta es la prueba de happy path para la característica de suspensión y reanudación. Esta prueba crea una actualización OTA e inicia la actualización. A continuación, se conecta AWS IoT Core con el mismo ID de cliente (nombre de la cosa) y las mismas credenciales. AWS IoT Core a continuación, desconecta el dispositivo. Se espera que el dispositivo detecte que está desconectado y AWS IoT Core, transcurrido un tiempo, pase a un estado suspendido e intente volver a conectarse AWS IoT Core y reanudar la descarga.
OTAE2EDisconnectCancelUpdate	Esta prueba comprueba si el dispositivo puede recuperarse por sí solo si se cancela el trabajo OTA mientras está suspendido. Hace lo mismo que en la OTAE2EDisconnectResume prueba, excepto que tras conectarse a AWS IoT Core, lo que desconecta el dispositivo, cancela la actualización OTA. Se crea una nueva actualización. Se espera que el dispositivo se vuelva a conectar AWS IoT Core, aborte la actualización actual, vuelva al estado de espera y acepte y finalice la próxima actualización.
OTAE2EPresignedUrlExpired	Cuando se crea una actualización OTA, puede configurar la duración de la URL prefirmada de S3. Esta prueba verifica que el dispositivo puede realizar una OTA, incluso si no puede finalizar la descarga cuando caduca la URL. Se espera que el dispositivo solicite un nuevo documento de trabajo que contenga una nueva URL para reanudar la descarga.
OTAE2E2UpdatesCancel1st	Esta prueba crea dos actualizaciones OTA seguidas. Cuando el dispositivo informa que está descargando la primera actualización, la prueba la cancela forzosamente. Se espera que el dispositivo aborte la actualización actual, recoja la segunda actualización y la complete.
OTAE2ECancelThenUpdate	Esta prueba crea dos actualizaciones OTA seguidas. Cuando el dispositivo informa que está descargando la primera actualización, la prueba la cancela forzosamente. Se espera que el dispositivo aborte la actualización actual, recoja la segunda actualización y la complete.
OTAE2EImageCrashed	Esta prueba comprueba que el dispositivo es capaz de rechazar una actualización cuando la imagen se bloquea.

Pruebas PAL

Requisitos previos

Para realizar la portabilidad de las pruebas de la interfaz de transporte de red, necesita lo siguiente:

• Un proyecto que pueda crear FreeRTOS con un puerto de kernel de FreeRTOS validado.

• Una implementación funcional de PAL OTA.

Portabilidad

• Añada FreeRTOS-Libraries-Integration-Tests como un submódulo al proyecto. La ubicación del submódulo en el proyecto debe ser donde se pueda crear.

• Copie config_template/test_execution_config_template.h y config_template/test_param_config_template.h en una ubicación en la ruta de creación y cámbieles el nombre a test_execution_config.h y test_param_config.h.

• Incluya los archivos relevantes en el sistema creación. Si utiliza CMake, qualification_test.cmake y src/ota_pal_tests.cmake se pueden usar para incluir los archivos relevantes.

• Configure la prueba implementando las siguientes funciones:

  • SetupOtaPalTestParam(): definido en src/ota/ota_pal_test.h. La implementación debe tener el mismo nombre y firma que se definen en ota_pal_test.h. Actualmente, no es necesario configurar esta función.

• Implemente UNITY_OUTPUT_CHAR para que los registros de salida de la prueba no se intercalen con los registros del dispositivo.

• Llame a RunQualificationTest() desde la aplicación. El hardware del dispositivo debe estar correctamente inicializado y la red debe estar conectada antes de la llamada.

Pruebas

En esta sección se describen las pruebas locales de calificación de PAL OTA.

Habilitación de la prueba

Abra test_execution_config.h y defina OTA_PAL_TEST_ENABLED en 1.

En test_param_config.h, actualice las siguientes opciones:

• OTA_PAL_TEST_CERT_TYPE: seleccione el tipo de certificado utilizado.

• OTA_PAL_CERTIFICATE_FILE: ruta al certificado del dispositivo, si corresponde.

• OTA_PAL_FIRMWARE_FILE: nombre del archivo de firmware, si corresponde.

• OTA_PAL_USE_FILE_SYSTEM: se establece en 1 si PAL OTA utiliza la abstracción del sistema de archivos.

Cree e instale la aplicación con la cadena de herramientas que prefiera. Cuando se llame a RunQualificationTest(), se ejecutarán las pruebas PAL OTA. Los resultados de la prueba se envían al puerto serie.

Integración de las tareas OTA

• Añada un agente OTA a su demostración actual de MQTT.

• Realice las pruebas OTA de extremo a extremo (E2E) con. AWS IoT Esto verifica si la integración funciona según lo esperado.

nota

Para calificar oficialmente un dispositivo para FreeRTOS, debes validar el código fuente portado del dispositivo con los grupos de prueba OTA PAL y OTA E2E con. AWS IoT Device Tester Siga las instrucciones de Uso AWS IoT Device Tester para FreeRTOS de la Guía del usuario de FreeRTOS para configurar AWS IoT Device Tester la validación de puertos. Para probar el puerto de una biblioteca específica, debe estar habilitado el grupo de prueba correcto en el device.json archivo de la AWS IoT Device Tester configs carpeta.

Cargador de arranque del dispositivo con IoT

Debe proporcionar su propia aplicación de cargador de arranque seguro. Asegúrese de que el diseño y la implementación mitiguen adecuadamente las amenazas a la seguridad. A continuación se muestra el modelo de amenazas como referencia.

Modelado de amenazas para el cargador de arranque del dispositivo con IoT

Introducción

Como definición práctica, los AWS IoT dispositivos integrados a los que hace referencia este modelo de amenazas son productos basados en microcontroladores que interactúan con los servicios en la nube. Pueden implementarse en entornos industriales, comerciales o de consumo. Los dispositivos con IoT pueden recopilar datos acerca de un usuario, un paciente, una máquina o un entorno y pueden controlarlo todo, desde bombillas y cerraduras hasta maquinaria industrial.

El modelado de amenazas es un enfoque de seguridad desde el punto de vista de un hipotético adversario. Al considerar los objetivos y métodos del adversario, se crea una lista de amenazas. Las amenazas son ataques contra un recurso o activo realizados por un adversario. La lista se prioriza y se utiliza para identificar y crear soluciones de mitigación. A la hora de elegir una solución de mitigación, el costo de implementarlas y mantenerlas debe equilibrarse con el valor de seguridad real que ofrecen. Existen varias metodologías de modelos de amenazas. Cada uno de ellos es capaz de respaldar el desarrollo de un producto seguro y exitoso. AWS IoT

Freertos ofrece actualizaciones de software OTA (over-the-air) para los AWS IoT dispositivos. La función actualizadora combina los servicios en la nube con las bibliotecas de software en el dispositivo y un cargador de arranque proporcionado por el socio. Este modelo de amenazas se centra específicamente en las amenazas contra el cargador de arranque.

Casos de uso del cargador de arranque

• Firmar y cifrar digitalmente el firmware antes de la implementación.

• Implementar nuevas imágenes de firmware en un único dispositivo, grupo de dispositivos o toda una flota.

• Verificar la autenticidad y la integridad del nuevo firmware una vez desplegado en los dispositivos.

• Los dispositivos solo ejecutan software sin modificar desde un origen de confianza.

• Los dispositivos son resistentes a errores en el software recibido mediante OTA.

Diagrama de flujo de datos

Amenazas

Algunos ataques tienen varios modelos de mitigación; por ejemplo, una red man-in-the-middle destinada a entregar una imagen de firmware maliciosa se mitiga verificando la confianza tanto en el certificado ofrecido por el servidor TLS como en el certificado del firmante de código de la nueva imagen de firmware. Para maximizar la seguridad del cargador de arranque, cualquier solución de mitigación no relacionada con el cargador de arranque se considera poco fiable. El cargador de arranque debe tener soluciones de mitigación intrínsecas para cada ataque. Disponer de soluciones de mitigación en capas se conoce como. defense-in-depth

Amenazas:

• Un atacante secuestra la conexión del dispositivo al servidor para entregar una imagen de firmware maliciosa.

  Ejemplo de mitigación

  • Al arrancar, el cargador de arranque verifica la firma criptográfica de la imagen mediante un certificado conocido. Si la verificación falla, el cargador de arranque restaura la imagen anterior.

• Un atacante aprovecha un desbordamiento del búfer para introducir un comportamiento malicioso en la imagen de firmware existente almacenada en flash.

  Ejemplos de mitigación

  • Al arrancar, el cargador de arranque verifica, tal y como se describió anteriormente. Cuando la verificación falla sin ninguna imagen anterior disponible, el cargador de arranque se detiene.

  • Al arrancar, el cargador de arranque verifica, tal y como se describió anteriormente. Cuando la verificación falla sin ninguna imagen anterior disponible, el cargador de arranque entra en modo solo OTA a prueba de errores.

• Un atacante arranca el dispositivo en una imagen almacenada anteriormente que es explotable.

  Ejemplos de mitigación

  • Los sectores flash que almacenan la última imagen se borran tras la instalación correcta y la prueba de una nueva imagen.

  • Con cada actualización correcta, se quema un fusible y cada imagen no se ejecuta a menos que se haya quemado el número correcto de fusibles.

• Una actualización OTA proporciona una imagen defectuosa o maliciosa que bloquea el dispositivo.

  Ejemplo de mitigación

  • El cargador de arranque inicia un temporizador de vigilancia de hardware que activa la reversión a la imagen anterior.

• Un atacante parchea el cargador de arranque para omitir la verificación de imágenes para que el dispositivo acepte imágenes sin firmar.

  Ejemplos de mitigación

  • El cargador de arranque está en ROM (memoria de solo lectura) y no se puede modificar.

  • El gestor de arranque está en OTP (one-time-programmable memoria) y no se puede modificar.

  • El gestor de arranque se encuentra en la zona segura de ARM TrustZone y no se puede modificar.

• Un atacante sustituye el certificado de verificación para que el dispositivo acepte imágenes maliciosas.

  Ejemplos de mitigación

  • El certificado se encuentra en un coprocesador criptográfico y no se puede modificar.

  • El certificado se encuentra en ROM (u OTP o zona segura) y no se puede modificar.

Modelado de amenazas adicionales

Este modelo de amenazas solo tiene en cuenta el cargador de arranque. Un modelado de amenazas adicionales podría mejorar la seguridad general. Un método recomendado consiste en enumerar los objetivos del adversario, los activos a los que se dirigen esos objetivos y los puntos de entrada a los activos. Se puede elaborar una lista de amenazas al tener en cuenta los ataques en los puntos de entrada para obtener control de los activos. A continuación se muestran listas de ejemplos de objetivos, activos y puntos de entrada para un dispositivo con IoT. Estas listas no son exhaustivas y están pensadas para impulsar la reflexión.

Objetivos del adversario

• Obtener dinero

• Arruinar reputaciones

• Falsificar datos

• Desviar recursos

• Espiar de forma remota a un objetivo

• Obtener acceso físico a un sitio

• Provocar el caos

• Infundir terror

Activos clave

• Claves privadas

• Certificado de cliente

• Certificados raíz de CA

• Tokens y credenciales de seguridad

• Información de identificación personal del cliente

• Implementaciones de secretos comerciales

• Datos del sensor

• Almacén de datos de análisis en la nube

• Infraestructura en la nube

Puntos de entrada

• Respuesta de DHCP

• Respuesta de DNS

• MQTT sobre TLS

• Respuesta HTTPS

• Imagen de software OTA

• Otros, según dicte la aplicación, por ejemplo, USB

• Acceso físico al bus

• Circuito integrado no limitado