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 laAWS IoTBiblioteca de actualización transparente
Con las actualizaciones inalámbricas (OTA) de FreeRTOS, 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 cuando se añaden a grupos, se restablecen o se 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.
-
Firmar firmware digitalmente con Code Signing para AWS IoT.
Para obtener más información, consulteActualizaciones inalámbricas de FreeRTOSen laGuía del usuario de FreeRTOSjunto con elAWS IoTDocumentación de actualización transparente
Puede utilizar la biblioteca de actualización OTA para integrar la funcionalidad OTA en sus aplicaciones de FreeRTOS. Para obtener más información, consulteBiblioteca de actualización OTA de FreeRTOSen laGuía del usuario de FreeRTOS.
Los dispositivos FreeRTOS con 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
Actualmente no es necesario un puerto de la biblioteca de actualización OTA de FreeRTOS para la cualificación del dispositivo.
Requisitos previos
-
Complete las instrucciones deConfiguración del código fuente de FreeRTOS para la portabilidad.
-
Cree un puerto de la biblioteca TLS.
Para obtener información, consulte Portabilidad de la biblioteca TLS.
-
Cree un cargador de arranque compatible con actualizaciones OTA.
Para obtener más información sobre el modo de realizar la portabilidad de una aplicación de cargador de arranque de demostración, consulte Portabilidad de la demostración de cargador de arranque.
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. La
contiene elfreertos
/vendors/vendor
/boards/board
/ports/ota_pal_for_aws/ota_pal.h
yota_pal.c
archivos de plantilla. Laota_pal.c
contiene definiciones vacías de un conjunto de funciones de capa de abstracción de plataforma (PAL). Como mínimo, debe implementar el conjunto de funciones indicadas en la tabla siguiente. Para ver un ejemplo de, consulte laImplementación de Windows Simulator OTA
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, por lo tanto, estará alineado. Para obtener más información, consulte laDocumentación de configuración de la biblioteca |
|
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 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 determinar cómo implementar esta función, consulte los detalles y la arquitectura de la tarjeta (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. |
Asegúrese de disponer de un cargador de arranque compatible con actualizaciones OTA. Para obtener instrucciones sobre cómo transferir la aplicación de cargador de arranque de demostración incluida con FreeRTOS o la creación de su cargador de arranque del dispositivo con IoT, consulteCargador de arranque del dispositivo con IoT.
Información adicional
La capa de abstracción portátil (PAL) permite que la biblioteca de actualizaciones OTA sea independiente de cualquier plataforma de hardware específica. La biblioteca OTA depende de las interfaces para permanecer independientes del sistema operativo y de la implementación del protocolo MQTT. Si su aplicación realiza OTA a través de HTTP, también hay una interfaz para la implementación del protocolo HTTP. Las aplicaciones de ejemplo de FreeRTOS utilizan puertos para estas interfaces que son comunes a todas las plataformas. Debido a esto, PAL es la única interfaz que debe portarse antes de que una nueva plataforma pueda utilizar la biblioteca OTA. Puede encontrar información sobre estas interfaces en laDocumentación de FreeRTOS para la biblioteca de actualizaciones OTA
Cargador de arranque del dispositivo con IoT
Portabilidad de la demostración de cargador de arranque
LaVersión v202012.00
Modelado de amenazas para el cargador de arranque del dispositivo con IoT
Introducción
Como una definición práctica, los dispositivos con IoT integrados 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 o crear mitigaciones. A la hora de elegir las mitigaciones, 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 («inalámbricas») para dispositivos con IoT. 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 tendrán varias mitigaciones; 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 mitigación no relacionada con el cargador de arranque se considera poco fiable. El cargador de arranque debe tener mitigaciones intrínsecas para cada ataque. Tener mitigaciones 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
Pruebas
Si va a utilizar un IDE para compilar proyectos de prueba, debe configurar el puerto de la biblioteca en el proyecto del IDE.
Configuración del proyecto de prueba en el IDE
Si va a utilizar el IDE para la portabilidad y las pruebas, ha de añadir algunos archivos de origen al proyecto de prueba del IDE antes de que pueda probar su código transferido. Esto incluye código para la biblioteca OTA, puerto PAL y código de prueba OTA.
En los pasos siguientes, asegúrese de añadir los archivos de origen a su proyecto de IDE desde su ubicación en disco. No cree copias duplicadas de los archivos de código fuente.
En este procedimiento, añadirá archivos para la biblioteca OTA, el puerto OTA y el código de prueba OTA a su proyecto IDE de prueba.
Para configurar el proyecto de prueba del IDE
-
Agregue el código de biblioteca OTA al proyecto:
-
Abra en un editor de texto
para ver varias variables de CMake relacionadas con la creación de la biblioteca OTA.freertos
/libraries/ota_for_aws/otaFilePaths.cmake -
Añadir los archivos enumerados en las variables
OTA_SOURCES
,OTA_OS_FREERTOS_SOURCES
,OTA_HTTP_SOURCES
(para la demostración OTA a través de HTTP), yOTA_MQTT_SOURCES
para el proyecto del IDE. -
Añada las rutas de inclusión enumeradas en las variables
OTA_INCLUDE_PUBLIC_DIRS
,OTA_INCLUDE_PRIVATE_DIRS
, yOTA_INCLUDE_OS_FREERTOS_DIRS
para el proyecto del IDE.
-
-
Añada el código PAL de OTA al proyecto:
-
Añadir
a su ruta de inclusión.freertos
/vendors/vendor
/boards/board
/ports/ota_pal_for_aws/ -
Añada la
ota_pal.c
yota_pal.h
archivos ubicados en el
directorio de tu proyecto.freertos
/vendors/vendor
/boards/board
/ports/ota_pal_for_aws/ -
Agregue archivos específicos de la plataforma o incluya rutas a su proyecto.
-
-
Añada el archivo de código fuente de prueba OTA al proyecto:
-
Añada todos los archivos de código fuente ubicados en
y sus subdirectorios de tu proyecto.freertos
\tests\integration_test\ota_pal -
Añadir
yfreertos
\tests\integration_test\ota_pal
a la ruta de inclusión de su proyecto de prueba.freertos
\tests\integration_test\ota_pal\test_files
-
-
Agregue los archivos de configuración relacionados con OTA al proyecto de prueba:
-
Añada la
ota_config.h
file (para el proyecto aws_demo) y elaws_test_ota_config.h
(para el proyecto aws_test) al directorio config files en
.freertos
/vendors/vendor
/boards/board
/aws_tests/config_filesEncontrará ejemplos de en la
directorio.freertos
/vendors/vendor
/boards/board
/aws_tests/config_files
-
Para ver un ejemplo de un proyecto de prueba IDE para OTA, consulte laGitHub
Configuración del archivo CMakeLists.txt
Si va a utilizar CMake para compilar el proyecto de prueba, ha de definir un destino de capa portátil para la biblioteca en el archivo de lista de CMake.
Para definir el destino de capa portátil de una biblioteca en CMakeLists.txt
, siga las instrucciones de Capas portables FreeRTOS.
El archivo de lista de plantillas CMakeLists.txt
de
contiene ejemplos de las definiciones de destino de la capa portátil. Puede eliminar el comentario de la definición de la biblioteca que vaya a transferir y modificarlo para que se ajuste a su plataforma.freertos
/vendors/vendor
/boards/board
/CMakeLists.txt
A continuación, encontrará un ejemplo de definición de destino de capa portátil para la biblioteca de OTA.
# Over-the-air Updates afr_mcu_port(ota) target_sources( AFR::ota::mcu_port INTERFACE "${afr_ports_dir}/ota_pal_for_aws/ota_pal.c" "${afr_ports_dir}/ota_pal_for_aws/ota_pal.h" # Add platform specific files that are required to build ota_pal.c. ) target_include_directories( AFR::ota::mcu_port INTERFACE "${afr_ports_dir}/ota_pal_for_aws" # Add platform specific include paths that are required to build ota_pal.c. ) target_link_libraries( AFR::ota::mcu_port INTERFACE AFR::crypto AFR::ota # Add platform specific target dependencies that are required to build ota_pal.c. ) # The qualification tests for the OTA PAL port requires this include path to run. if(AFR_ENABLE_TESTS) target_include_directories( AFR::ota::mcu_port INTERFACE "${PROJECT_SOURCE_DIR}/tests/integration_test/ota_pal" ) endif()
Encontrará un ejemplo deCMakeLists.txt
para la plataforma Windows Simulator enGitHub
Pruebas OTA PAL
Configuración del entorno de pruebas locales
Para configurar los archivos de origen y de encabezado para las pruebas de PAL OTA
-
Abra en un editor de texto
y establezca elfreertos
/vendors/vendor
/boards/board
/aws_tests/config_files/aws_test_runner_config.htestrunnerFULL_OTA_PAL_ENABLED
macro para1
para habilitar las pruebas PAL. -
Abra el icono
y configúralo para tu plataforma. Puede encontrar los detalles específicos sobre qué configuraciones existen y cómo configurarlas en el archivo de configuración.freertos
/vendors/vendor
/boards/board
/aws_tests/config_files/aws_test_ota_config.h -
Elija un certificado de firma para el dispositivo en
. Los certificados se utilizan en las pruebas de OTA para la verificación.freertos
/tests/integration_test/ota_pal/test_filesHay disponibles tres tipos de certificados de firma en el código de prueba:
-
RSA/SHA1
-
RSA/SHA256
-
ECDSA/SHA256
RSA/SHA1 y RSA/SHA256 solo están disponibles para las plataformas existentes. ECDSA/SHA256 se recomienda para las actualizaciones OTA. Si tiene un esquema diferente,contacte con el equipo de ingeniería FreeRTOS
. -
Ejecución de las pruebas
Ejecución de las pruebas de PAL OTA
-
Cree el proyecto de prueba y lléguelo en el dispositivo para ejecutar las pruebas.
-
Compruebe los resultados de la prueba en la consola UART.
Su plataforma supera las pruebas OTA PAL si hay 25 pruebas que se ejecutaron con 0 fallos y 0 ignoraciones. En este punto, su plataforma se puede utilizar para ejecutar la demostración de OTA si ha configurado su proyecto de demostración.
Validación
Para cualificar oficialmente un dispositivo para FreeRTOS, debe validar el código fuente portado del dispositivo conAWS IoTDevice Tester. Siga las instrucciones enUso deAWS IoTDevice Tester para FreeRTOSen la Guía del usuario de FreeRTOS para configurar Device Tester para la validación de puertos. Para probar el puerto de una biblioteca concreta, se debe habilitar el grupo de pruebas correcto en el archivo device.json
de la carpeta configs
de Device Tester.
Una vez que haya transferido la biblioteca OTA de FreeRTOS y la demostración del cargador de arranque, puede comenzar a transferir la biblioteca Bluetooth de bajo consumo. Para obtener instrucciones, consulte Portabilidad de la biblioteca de Bluetooth de bajo consumo.
Si su dispositivo no es compatible con la funcionalidad Bluetooth de bajo consumo, ya ha terminado y puede comenzar el proceso de cualificación de FreeRTOS. Para obtener más información, consulte laGuía de cualificación de FreeRTOS.