Portabilidad deAWS IoT over-the-air biblioteca de actualizaciones (OTA) - FreeRTOS

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 deAWS IoT over-the-air biblioteca de actualizaciones (OTA)

Con FreeRTOS over-the-air (OTA) de 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 se añaden a grupos, restablecen o aprovisionan.

  • 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.

  • Firmar firmware digitalmente con Code Signing para AWS IoT.

Para obtener más información, consulteActualizaciones inalámbricas FreeRTOSen laGuía del usuario de FreeRTOSjunto con elAWS IoTDocumentación de actualización inalámbrica.

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

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

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

  • Curva NIST P256

  • Hash SHA-256

Requisitos previos

Portabilidad de plataforma

Debe proporcionar una implementación de la capa de abstracción portátil (PAL) OTA para portar la biblioteca OTA a un nuevo dispositivo. Las API de PAL se definen en laota_platform_interface.harchivo para el que deben proporcionarse 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 utiliza almacenamiento que implementa 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, consulteConfiguración de la biblioteca OTA.

otaPal_ActivateNewImage

Activa o lanza la nueva imagen de firmware. Para algunos puertos, si el dispositivo se restablece de forma síncrona mediante programación, esta función no volverá.

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 la documentación de los detalles y la arquitectura de la placa (plataforma).

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 suAWS IoTgestor de arranque del dispositivo, consulteCargador de arranque del dispositivo con IoT.

Pruebas E2E y PAL

Ejecute pruebas OTA PAL y E2E.

Pruebas E2E

La prueba de extremo a extremo (E2E) de OTA se utiliza para verificar la capacidad OTA de un dispositivo y para simular escenarios 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 conAWSBiblioteca OTA integrada en ella. Visite elGuía de portabilidad de la bibliotecapara obtener información adicional.

  • Portar la aplicación de demostración mediante la biblioteca OTA para interactuar conAWS IoT Corepara hacer las actualizaciones OTA. Consulte Portabilidad de la aplicación demo de OTA.

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

Portabilidad de la aplicación demo de OTA

La prueba OTA E2E 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 demo de FreeRTOS OTA enGitHub FreeRTOS. Le recomendamos que utilice la aplicación de demostración como referencia y la modifique según sus especificaciones.

Pasos para la
  1. Inicialice el agente de OTA.

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

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

  4. Inicie el agente de OTA.

  5. Supervisar las estadísticas del agente OTA.

  6. Apague el agente de OTA.

VisitaFreeRTOS OTA sobre MQTT - Punto de entrada de la demopara obtener instrucciones detalladas.

Configuración

Se necesitan las siguientes configuraciones para interactuar conAWS IoT Core:

  • AWS IoT CoreClient credenciales

    • Configuración deConfigroot_ca_pem de demostraciónenOta_Over_Mqtt_Demo/demo_config.hcon endpoints de Amazon Trust Services. ConsulteAWSautenticación del servidorpara obtener más información.

    • Configuración deDemoconfigClient_Certificate_PEMyDemoconfigclient_private_key_pemenOta_Over_Mqtt_Demo/demo_config.hcon suAWS IoTlas credenciales del cliente. ConsulteAWSdetalles de autenticación de clientepara obtener información sobre los certificados de cliente y las claves privadas.

  • Versión de la aplicación

  • Protocolo de control de OTA

  • Protocolo de datos OTA

  • Credenciales de firma de código

  • Otras configuraciones de biblioteca OTA

Puede encontrar la información anterior endemo_config.hyota_config.hen aplicaciones de demostración de FreeRTOS OTA. VisitaFreeRTOS OTA a través de MQTT - Configuración del dispositivopara obtener más información.

Verificación de creación

Ejecute la aplicación de demostración para ejecutar el trabajo OTA. Cuando se completa correctamente, puede continuar ejecutando las pruebas OTA E2E.

FreeRTOSDemo OTAproporciona información detallada sobre la configuración de un cliente OTA y unaAWS IoT CoreTrabajo OTA en el simulador de Windows FreeRTOS.AWS OTA admite protocolos MQTT y HTTP. Consulte los siguientes ejemplos para obtener más información:

Ejecución de pruebas con la herramienta IDT

Para ejecutar las pruebas OTA E2E, debe utilizarAWS IoT Device Tester(IDT) para automatizar la ejecución. ConsulteAWS IoT Device Testerpara FreeRTOSen laGuía del usuario de FreeRTOSpara obtener más información.

Casos de prueba E2E

Caso de prueba

Descripción

OTAE2EGreaterVersion

Prueba de ruta feliz para actualizaciones periódicas de 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 retroceda 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 actualización anterior.

OTAE2EIncorrectSigningAlgorithm

Diferentes dispositivos admiten diferentes algoritmos de firma y hash. Esta prueba verifica que el dispositivo falla la actualización OTA si se crea con un algoritmo no compatible.

OTAE2EDisconnectResume

Esta es la prueba de ruta feliz para la función de suspensión y reanudación. Esta prueba crea una actualización OTA e inicia la actualización. A continuación, se conecta aAWS IoT Corecon el mismo ID de cliente (nombre de la cosa) y credenciales.AWS IoT Coreluego desconecta el dispositivo. Se espera que el dispositivo detecte que está desconectado deAWS IoT Core, y después de un período de tiempo, se mueva a un estado suspendido e intente volver a conectarse aAWS IoT Corey reanuda la descarga.

OTAE2EDisconnectCancelUpdate

Esta prueba comprueba si el dispositivo puede recuperarse solo si el trabajo OTA se cancela mientras está suspendido. Hace lo mismo que laOTAE2EDisconnectResumeprueba, excepto que después de conectarse aAWS IoT Core, que desconecta el dispositivo, cancela la actualización OTA. Se crea una nueva actualización. Se espera que el dispositivo se vuelva a conectar alAWS IoT Core, anule 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 vida útil de la url prefirmada de S3. Esta prueba verifica que el dispositivo puede realizar una OTA, incluso si no puede finalizar la descarga cuando caduque la url. Se espera que el dispositivo solicite un nuevo documento de trabajo, que contiene una nueva URL para reanudar la descarga.

OTAE2E2UpdatesCancel1st

Esta prueba crea dos actualizaciones OTA seguidas. Cuando el dispositivo informa de que está descargando la primera actualización, la fuerza de prueba cancela la primera actualización. Se espera que el dispositivo cancele la actualización actual y retome la segunda actualización y la complete.

OTAE2ECancelThenUpdate

Esta prueba crea dos actualizaciones OTA seguidas. Cuando el dispositivo informa de que está descargando la primera actualización, la fuerza de prueba cancela la primera actualización. Se espera que el dispositivo cancele la actualización actual y recoja la segunda actualización y, a continuación, la complete.

OTAE2EImageCrashed

Esta prueba comprueba que el dispositivo puede 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 puede crear FreeRTOS con un puerto kernel FreeRTOS válido.

  • Una implementación funcional de OTA PAL.

Portabilidad

  • AñadirBibliotecas gratuitas - Pruebas de integracióncomo submódulo de tu proyecto. La ubicación del submódulo en el proyecto debe ser donde se puede construir.

  • Copiaconfig_template/test_execution_config_template.hyconfig_template/test_param_config_template.ha una ubicación de la ruta de compilación y cámbiele el nombre atest_execution_config.hytest_param_config.h.

  • Incluya los archivos relevantes en el sistema de compilación. Si se utilizaCMake,qualification_test.cmakeysrc/ota_pal_tests.cmakese puede utilizar para incluir 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.

  • ImplementarUNITY_OUTPUT_CHARpara que los registros de salida de prueba no se entrelacen con los registros de dispositivos.

  • LlamadaRunQualificationTest()desde la aplicación. El hardware del dispositivo debe inicializarse correctamente y la red debe estar conectada antes de la llamada.

Pruebas

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

Habilitar la prueba

Abiertotest_execution_config.hy definirOTA_PAL_TEST_ENABLEDa 1.

Entest_param_config.h, actualiza las siguientes opciones:

  • OTA_PAL_TEST_CERT_TYPE: Seleccione el tipo de certificado utilizado.

  • OTA_PAL_CERTIFICATE_FILE: Ruta del certificado de dispositivo, si procede.

  • OTA_PAL_FIRMWARE_FILE: Nombre del archivo de firmware, si procede.

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

Cree y flashee la aplicación utilizando la cadena de herramientas de su elección. Cuando laRunQualificationTest()se llama, se ejecutarán las pruebas OTA PAL. Los resultados de la prueba se envían al puerto de serie.

Integración de tareas de OTA

  • Agregue un agente OTA a su demo actual de MQTT.

  • Ejecute pruebas OTA End to End (E2E) conAWS IoT. Esto verifica si la integración funciona como se esperaba.

nota

Para certificar oficialmente un dispositivo para FreeRTOS, debe validar el código fuente transferido del dispositivo con los grupos de pruebas OTA PAL y OTA E2E conAWS IoT Device Tester. Siga las instrucciones enUso deAWS IoT Device Testerpara FreeRTOSen laGuía del usuario de FreeRTOSpara configurarAWS IoT Device Testerpara validación de puertos. Para probar el puerto de una biblioteca concreta, se debe habilitar el grupo de pruebas correcto en ladevice.jsonen el archivoAWS IoT Device Tester configsfolder.

Cargador de arranque del dispositivo con IoT

Debe proporcionar su propia aplicación de gestor de arranque seguro. Asegúrese de que el diseño y la implementación proporcionen una mitigación adecuada de las amenazas de seguridad. A continuación se muestra el modelado de amenazas para su referencia.

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

Introducción

Como definición de trabajo, la incrustaciónAWS IoTLos dispositivos a los que este modelo de amenazas hace referencia son productos con 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 implementarla y mantenerla debe equilibrarse con el valor de seguridad real que proporciona. Existen varias metodologías de modelos de amenazas. Cada una es capaz de respaldar el desarrollo de una solución segura y exitosaAWS IoTproducto de.

FreeRTOS ofrece actualizaciones de software OTA (por aire) paraAWS IoTDispositivos. 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 implementado 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 diseñada para entregar una imagen de firmware maliciosa se mitigará verificando la confianza en el certificado ofrecido por el servidor TLS y en el certificado de firma del 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. Tener soluciones de mitigación en capas se conoce como «defensa en profundidad».

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 cargador de arranque está en OTP (memoria programable una sola vez) y no se puede modificar.

    • El cargador 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