Portabilidad deAWS IoTBiblioteca de actualizaciones inalámbricas

Con las actualizaciones inalámbricas de FreeRTOS (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 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 el AWS 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, consulteActualización de la biblioteca de actualización de FreeRTOSen laGuía del usuario de FreeRTOS.

Los dispositivos con deben requerir 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

nota

Actualmente no es necesario un puerto de la biblioteca de actualización FreeRTOS OTA de OTA para la cualificación del dispositivo.

Prerequisites

• Complete las instrucciones enConfiguración del código fuente 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.

Transferencia de plataformas

Debe proporcionar una implementación de la capa de abstracción portátil (PAL) de OTA para portar la biblioteca OTA a un nuevo dispositivo. Lafreertos/vendors/vendor/boards/board/ports/ota_pal_for_aws/contiene el directorio deota_pal.hyota_pal.cArchivos de plantilla de archivo. Laota_pal.ccontiene definiciones vacías de un conjunto de funciones de la capa de abstracción de plataforma (PAL). Como mínimo, debe implementar el conjunto de funciones que se muestran en la tabla siguiente. Para ver un ejemplo, consulte laImplementación de Windows Simulator OTA.

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. En caso de éxito, 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 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 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 determinar cómo implementar esta función, consulte los detalles y la arquitectura de la tarjeta (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 transferir la aplicación de cargador de arranque de demostración incluida con FreeRTOS o crear 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 actualización de OTA sea independiente de cualquier plataforma de hardware específica. La biblioteca OTA depende de las interfaces para mantenerse independiente del sistema operativo y de la implementación del protocolo MQTT. Si su aplicación realiza OTA sobre HTTP, entonces también hay una interfaz para la implementación del protocolo HTTP. Las aplicaciones de ejemplo en FreeRTOS OS utilizan puertos para estas interfaces que son comunes a todas las plataformas. Debido a esto, el PAL es la única interfaz que se debe portar antes de que una nueva plataforma pueda usar la biblioteca OTA. Puede encontrar información sobre estas interfaces en laDocumentación de FreeRTOS OS 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.00incluye una aplicación de cargador de arranque de demostración para la plataforma Microchip Curiosity PIC32MZEF. Para obtener más información, consulteCargador de arranque de demostración para la placa de desarrollo Curiosity PIC32MZEF de Microchipen laGuía del usuario de FreeRTOS. Puede realizar la portabilidad de esta demostración a otras plataformas. Si no transporta la demostración a su plataforma, puede utilizar su propia aplicación de cargador de arranque. Para obtener más información sobre cómo escribir su propia aplicación de cargador de arranque seguro, consulte.Modelado de amenazas para el cargador de arranque del dispositivo con IoT.

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

Background

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. Cada una es capaz de respaldar el desarrollo de un producto de IoT seguro y exitoso.

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

Threats

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

• 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

Testing

Si va a utilizar el IDE para compilar proyectos de prueba, ha de 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.

importante

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, agregue archivos para la biblioteca OTA, el puerto OTA y el código de prueba OTA al proyecto IDE de prueba.

Para configurar el proyecto de prueba del IDE

1. Agregue el código de la biblioteca OTA al proyecto:

   1. En un editor de texto, abra la ventana defreertos/libraries/ota_for_aws/otaFilePaths.cmakepara ver varias variables CMake relacionadas con la construcción de la biblioteca OTA.

   2. Agregue los archivos enumerados en las variablesOTA_SOURCES,OTA_OS_FREERTOS_SOURCES,OTA_HTTP_SOURCES(para la demostración OTA sobre HTTP), yOTA_MQTT_SOURCESPara su proyecto del IDE.

   3. Agregue las rutas de inclusión enumeradas en las variablesOTA_INCLUDE_PUBLIC_DIRS,OTA_INCLUDE_PRIVATE_DIRS, yOTA_INCLUDE_OS_FREERTOS_DIRSPara su proyecto del IDE.

2. Agregue el código OTA PAL al proyecto:

   1. Addfreertos/vendors/vendor/boards/board/ports/ota_pal_for_aws/a su ruta de inclusión.

   2. Añada la etiquetaota_pal.cyota_pal.hubicados en el archivofreertos/vendors/vendor/boards/board/ports/ota_pal_for_aws/a su proyecto.

   3. Agregue archivos específicos de la plataforma o incluya rutas a su proyecto.

3. Agregue el archivo de código fuente de prueba OTA al proyecto:

   1. Agregue todos los archivos de código fuente ubicados enfreertos\tests\integration_test\ota_paly sus subdirectorios a su proyecto.

   2. Addfreertos\tests\integration_test\ota_palyfreertos\tests\integration_test\ota_pal\test_filesa la ruta de inclusión de su proyecto de prueba.

4. Agregue los archivos de configuración relacionados con OTA al proyecto de prueba:

   1. Añada la etiquetaota_config.h(para el proyecto aws_demo) y el archivo deaws_test_ota_config.h(para el proyecto aws_test) al directorio de archivos de configuración enfreertos/vendors/vendor/boards/board/aws_tests/config_files.

      Puede encontrar ejemplos en lafreertos/vendors/vendor/boards/board/aws_tests/config_filesDirectorio de.

Para obtener un ejemplo de un proyecto de prueba IDE para OTA, consulte laGitHubSitio web de.

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 freertos/vendors/vendor/boards/board/CMakeLists.txt 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.

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() 

Puede encontrar un ejemplo deCMakeLists.txtpara 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 OTA PAL

1. En un editor de texto, abra la ventana defreertos/vendors/vendor/boards/board/aws_tests/config_files/aws_test_runner_config.hy establezca la propiedadtestrunnerFULL_OTA_PAL_ENABLEDa macros de1para habilitar las pruebas PAL.

2. Abra el iconofreertos/vendors/vendor/boards/board/aws_tests/config_files/aws_test_ota_config.hy configurarlo para su plataforma. Puede encontrar los detalles específicos sobre qué configuraciones existen y cómo establecerlas en el archivo de configuración.

3. Elija un certificado de firma para el dispositivo en freertos/tests/integration_test/ota_pal/test_files. Los certificados se utilizan en las pruebas de OTA para la verificación.

   Hay 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,póngase en contacto con el equipo de ingeniería de Free.

Ejecución de las pruebas

Para ejecutar las pruebas de OTA PAL

1. Cree el proyecto de prueba y colóquelo en el dispositivo para ejecutar las pruebas.

2. Compruebe los resultados de la prueba en la consola UART.

   

Su plataforma pasa las pruebas OTA PAL si hay 25 pruebas que se ejecutaron con 0 errores y 0 ignora. En este punto, su plataforma se puede utilizar para ejecutar la demostración de OTA si ha configurado su proyecto de demostración.

Validation

Para calificar 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 FreeRTOS OTA y la demostración del cargador de arranque de demostración, puede comenzar a trasladar 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 de. Para obtener más información, consulte laGuía de cualificación de FreeRTOS.