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
-
Complete las instrucciones deConfiguración del espacio de trabajo y el proyecto para portar.
-
Cree un puerto de interfaz de transporte de red.
Para obtener información, consulte Portación de la interfaz de transporte de red.
-
Integra la biblioteca CoreMQTT. ConsulteBiblioteca CoreMQTTen la Guía del usuario de FreeRTOS.
-
Cree un cargador de arranque compatible con actualizaciones OTA.
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.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 utiliza almacenamiento que implementa 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, consulteConfiguración de la biblioteca OTA |
|
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á. |
|
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). |
|
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. |
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 biblioteca
para 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
Pasos para la
Inicialice el agente de OTA.
Implemente la función de devolución de llamada de aplicación OTA.
Cree la tarea de procesamiento de eventos del agente OTA.
Inicie el agente de OTA.
Supervisar las estadísticas del agente OTA.
Apague el agente de OTA.
VisitaFreeRTOS OTA sobre MQTT - Punto de entrada de la demo
Configuración
Se necesitan las siguientes configuraciones para interactuar conAWS IoT Core:
AWS IoT CoreClient credenciales
Configuración deConfigroot_ca_pem de demostraciónen
Ota_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_pemen
Ota_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 dispositivo
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 OTA
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 |
|---|---|
|
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. |
|
Esta prueba crea 3 actualizaciones OTA consecutivas. Se espera que el dispositivo se actualice 3 veces consecutivas. |
|
Esta prueba verifica que el dispositivo retroceda 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 actualización anterior. |
|
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. |
|
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. |
|
Esta prueba comprueba si el dispositivo puede recuperarse solo si el trabajo OTA se cancela mientras está suspendido. Hace lo mismo que la |
|
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. |
|
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. |
|
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. |
|
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ón
como submódulo de tu proyecto. La ubicación del submódulo en el proyecto debe ser donde se puede construir. Copia
config_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 utiliza
CMake,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.
Llamada
RunQualificationTest()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.
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
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
