Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
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
Nombre de la función |
Descripción |
|---|---|
|
Detiene una actualización OTA. |
|
Crea un archivo para almacenar los fragmentos de datos recibidos. |
|
Cierra el archivo especificado. Esto puede autenticar el archivo si se utiliza almacenamiento con protección criptográfica. |
|
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 |
|
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. |
|
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. |
|
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 |
|---|---|
|
Verifica la firma del archivo especificado. |
|
Lee el certificado de firma especificado del sistema de archivos y lo devuelve al intermediario. |
|
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
Pasos de la portabilidad
Inicialice el agente de OTA.
Implemente la función de devolución de llamada de la aplicación OTA.
Cree la tarea de procesamiento de eventos del agente OTA.
Inicie el agente OTA.
Supervise las estadísticas del agente OTA.
Apague al agente OTA.
Consulte FreeRTOS OTA over MQTT - Entry point of the demo
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.hcon 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.hAWS 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
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
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 |
|---|---|
|
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. |
|
Esta prueba crea 3 actualizaciones OTA consecutivas. Se espera que el dispositivo se actualice 3 veces consecutivas. |
|
Esta prueba verifica que el dispositivo vuelva al firmware anterior si no puede conectarse a la red con el nuevo firmware. |
|
Esta prueba confirma que el dispositivo rechaza el firmware entrante si la versión sigue siendo la misma. |
|
Esta prueba verifica que el dispositivo rechaza una actualización si la imagen no está firmada. |
|
Esta prueba verifica que el dispositivo rechaza una actualización si el firmware está firmado con un certificado que no es de confianza. |
|
Esta prueba verifica que el dispositivo rechaza una versión de una actualización anterior. |
|
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. |
|
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. |
|
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 |
|
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. |
|
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. |
|
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. |
|
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.hyconfig_template/test_param_config_template.hen una ubicación en la ruta de creación y cámbieles el nombre atest_execution_config.hytest_param_config.h.Incluya los archivos relevantes en el sistema creación. Si utiliza
CMake,qualification_test.cmakeysrc/ota_pal_tests.cmakese pueden usar para incluir los archivos relevantes.Configure la prueba implementando las siguientes funciones:
SetupOtaPalTestParam(): definido ensrc/ota/ota_pal_test.h. La implementación debe tener el mismo nombre y firma que se definen enota_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
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
