Portabilidade da biblioteca de atualização sem fios do AWS IoT - FreeRTOS
Pré-requisitosPortabilidade de plataformaTestes E2E e PALBootloader de dispositivo de IoT

Portabilidade da biblioteca de atualização sem fios do AWS IoT

É possível fazer o seguinte com atualizações sem fios do FreeRTOS:

  • Implante novas imagens de firmware em um único dispositivo, um grupo de dispositivos ou toda a sua frota.

  • Implantar firmware em dispositivos conforme eles são adicionados a grupos, redefinidos ou provisionados novamente.

  • Verifique a autenticidade e a integridade do novo firmware depois da sua implantação nos dispositivos.

  • Monitore o progresso de uma implantação.

  • Depure uma implantação com falha.

  • Assine digitalmente o firmware usando o Code Signing para AWS IoT.

Para obter mais informações, consulte as Atualizações sem fios do FreeRTOS no Guia do usuário do FreeRTOS junto com a Documentação de atualização sem fios do AWS IoT.

Você pode usar a biblioteca de atualização OTA para integrar a funcionalidade OTA nas aplicações do FreeRTOS. Para obter mais informações, consulte Biblioteca de atualização OTA do FreeRTOS no Guia do usuário do FreeRTOS.

Os dispositivos do FreeRTOS devem impor a verificação criptográfica de assinatura de código nas imagens de firmware OTA que recebem. Recomendamos os seguintes algoritmos:

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

  • Curva NIST P256

  • Hash SHA-256

Pré-requisitos

Portabilidade de plataforma

Você deve fornecer uma implementação da camada de abstração portável (PAL) OTA para transferir a biblioteca OTA para um novo dispositivo. As APIs PAL são definidas no arquivo ota_platform_interface.h para o qual devem ser fornecidos detalhes específicos da implementação.

Nome da função

Descrição

otaPal_Abort

Interrompe uma atualização OTA.

otaPal_CreateFileForRx

Cria um arquivo para armazenar os blocos de dados recebidos.

otaPal_CloseFile

Fecha o arquivo especificado. Isso pode autenticar o arquivo se você usar armazenamento que implementa a proteção criptográfica.

otaPal_WriteBlock

Grava um bloco de dados no arquivo especificado no deslocamento determinado. A função retornará o número de bytes gravados quando tiver êxito. Caso contrário, a função retornará um código de erro negativo. O tamanho do bloco sempre será uma potência de dois e será alinhado. Para obter mais informações, consulte Configuração da biblioteca OTA.

otaPal_ActivateNewImage

Ativa ou inicia a nova imagem de firmware. Em algumas portas, se o dispositivo for redefinido programaticamente de forma síncrona, essa função poderá não retornar.

otaPal_SetPlatformImageState

Faz o que é exigido pela plataforma para aceitar ou rejeitar a imagem de firmware (ou pacote) OTA mais recente. Para implementar essa função, consulte a documentação para obter os detalhes e a arquitetura da sua placa (plataforma).

otaPal_GetPlatformImageState

Obtém o estado da imagem de atualização OTA.

Implemente as funções nesta tabela se o dispositivo tiver suporte integrado para elas.

Nome da função

Descrição

otaPal_CheckFileSignature

Verifica a assinatura do arquivo especificado.

otaPal_ReadAndAssumeCertificate

Lê o certificado do assinante especificado no sistema de arquivos e o retorna para o chamador.

otaPal_ResetDevice

Redefine o dispositivo.
nota

Certifique-se de que você tem um bootloader que pode oferecer suporte a atualizações OTA. Para obter instruções sobre como criar o carregador de inicialização do dispositivo do AWS IoT, consulte Bootloader de dispositivo de IoT.

Testes E2E e PAL

Execute testes PAL OTA e E2E.

Testes E2E

O teste de ponta a ponta (E2E) OTA é usado para verificar a capacidade OTA de um dispositivo e simular cenários reais. Esse teste incluirá tratamento de erros.

Pré-requisitos

Para fazer a portabilidade desse teste, é necessário:

  • Um projeto com uma biblioteca OTA da AWS integrada. Visite o Guia de portabilidade da biblioteca OTA para obter informações adicionais.

  • Faça a portabilidade da aplicação de demonstração usando a biblioteca OTA para interagir com o AWS IoT Core e fazer as atualizações OTA. Consulte Portabilidade da aplicação de demonstração OTA.

  • Configure a ferramenta do IDT. Isso executa a aplicação host E2E OTA para compilar, instalar e monitorar o dispositivo em diferentes configurações e valida a integração da biblioteca OTA.

Portabilidade da aplicação de demonstração OTA

O teste E2E OTA deve ter uma aplicação de demonstração OTA para validar a integração da biblioteca OTA. A aplicação de demonstração deve ter a capacidade de realizar atualizações de firmware OTA. Você pode encontrar a aplicação de demonstração OTA do FreeRTOS no repositório GitHub do FreeRTOS. Recomendamos que você use a aplicação de demonstração como referência e a modifique de acordo com suas especificações.

Etapas da portabilidade

  1. Inicialize o agente OTA.

  2. Implemente a função de retorno de chamada da aplicação OTA.

  3. Crie a tarefa de processamento de eventos do agente OTA.

  4. Inicie o agente OTA.

  5. Monitore as estatísticas do agente OTA.

  6. Encerre o agente OTA.

Visite OTA do FreeRTOS por MQTT - Ponto de entrada da demonstração para obter instruções detalhadas.

Configuração

As seguintes configurações são necessárias para interagir com o AWS IoT Core:

  • Credenciais de cliente do AWS IoT Core

    • Configure DemoConfigRoot_CA_PEM em Ota_Over_Mqtt_Demo/demo_config.h com os Endpoints dos serviços de confiança da Amazon. Consulte Autenticação do servidor da AWS para obter mais detalhes.

    • Configure democonfigCLIENT_CERTIFICATE_PEM e democonfigCLIENT_PRIVATE_KEY_PEM em Ota_Over_Mqtt_Demo/demo_config.h com suas credenciais de cliente AWS IoT. Consulte os detalhes da autenticação do cliente da AWS para saber mais sobre certificados e chaves privadas do cliente.

  • Versão da aplicação

  • Protocolo de controle OTA

  • Protocolo de dados OTA

  • Credenciais de assinatura de código

  • Outras configurações da biblioteca OTA

Você pode encontrar as informações anteriores nas aplicações de demonstração OTA do FreeRTOS em demo_config.h e ota_config.h. Visite OTA do FreeRTOS por MQTT - Configuração do dispositivo para obter mais informações.

Verificação de compilação

Execute a aplicação de demonstração para executar o trabalho OTA. Quando isso for concluído com êxito, você poderá continuar executando os testes E2E OTA.

A demonstração OTA do FreeRTOS fornece informações detalhadas sobre como configurar um cliente OTA e um trabalho OTA do AWS IoT Core no simulador do Windows da AWS do FreeRTOS. OTA é compatível com os protocolos MQTT e HTTP. Consulte os exemplos a seguir para obter mais detalhes:

Execução de testes com a ferramenta do IDT

Para executar os testes E2E OTA, você deve usar o AWS IoT Device Tester (IDT) para automatizar a execução. Consulte o AWS IoT Device Tester para o FreeRTOS no Guia do usuário do FreeRTOS para obter mais detalhes.

Casos de teste E2E

Caso de teste

Descrição

OTAE2EGreaterVersion

Teste "caminho feliz" para atualizações regulares do OTA. Ele cria uma atualização com uma versão mais recente, que o dispositivo atualiza com êxito.

OTAE2EBackToBackDownloads

Esse teste cria três atualizações OTA consecutivas. O esperado é que o dispositivo atualize três vezes consecutivas.

OTAE2ERollbackIfUnableToConnectAfterUpdate

Esse teste verifica se o dispositivo é revertido para o firmware anterior se não conseguir se conectar à rede com o novo firmware.

OTAE2ESameVersion

Esse teste confirma que o dispositivo rejeita o firmware de entrada se a versão permanecer a mesma.

OTAE2EUnsignedImage

Esse teste verifica se o dispositivo rejeita uma atualização se a imagem não estiver assinada.

OTAE2EUntrustedCertificate

Esse teste verifica se o dispositivo rejeita uma atualização se o firmware estiver assinado com um certificado não confiável.

OTAE2EPreviousVersion

Esse teste verifica se o dispositivo rejeita uma versão de atualização mais antiga.

OTAE2EIncorrectSigningAlgorithm

Dispositivos diferentes oferecem suporte a algoritmos de assinatura e hashing diferentes. Esse teste verifica se o dispositivo falha na atualização OTA, caso ele seja criado com um algoritmo não compatível.

OTAE2EDisconnectResume

Este é o teste de "caminho feliz" para o recurso de suspensão e retomada. Esse teste cria uma atualização OTA e inicia a atualização. Em seguida, ele se conecta ao AWS IoT Core com o mesmo ID de cliente (nome de coisa) e credenciais. do AWS IoT Core, em seguida, desconecta o dispositivo. O esperado é que o dispositivo detecte que está desconectado do AWS IoT Core e, após um período, passe para um estado suspenso e tente se reconectar ao AWS IoT Core e retomar o download.

OTAE2EDisconnectCancelUpdate

Esse teste verifica se o dispositivo pode se recuperar, caso o trabalho OTA seja cancelado enquanto está em um estado suspenso. Ele faz a mesma coisa que o teste OTAE2EDisconnectResume, exceto que depois de se conectar ao dispositivo do AWS IoT Core, que desconecta o dispositivo, ele cancela a atualização OTA. Uma nova atualização é criada. O esperado é que o dispositivo se reconecte ao AWS IoT Core, anule a atualização atual, volte ao estado de espera e aceite e conclua a próxima atualização.

OTAE2EPresignedUrlExpired

Quando uma atualização OTA é criada, você pode configurar a vida útil do URL pré-assinado do S3. Esse teste verifica se o dispositivo é capaz de realizar um OTA, mesmo que não consiga concluir o download quando o URL expirar. O esperado é que o dispositivo solicite um novo documento de trabalho, que contém um novo URL para retomar o download.

OTAE2E2UpdatesCancel1st

Esse teste cria duas atualizações OTA consecutivas. Quando o dispositivo relata que está baixando a primeira atualização, o teste força o cancelamento da primeira atualização. O esperado é que o dispositivo anule a atualização atual, detecte a segunda atualização e a conclua.

OTAE2ECancelThenUpdate

Esse teste cria duas atualizações OTA consecutivas. Quando o dispositivo relata que está baixando a primeira atualização, o teste força o cancelamento da primeira atualização. O esperado é que o dispositivo anule a atualização atual e detecte a segunda atualização, depois a conclua.

OTAE2EImageCrashed

Esse teste verifica se o dispositivo é capaz de rejeitar uma atualização quando a imagem falha.

Testes PAL

Pré-requisitos

Para transferir os testes da interface de transporte de rede, será necessário:

  • Um projeto que pode compilar o FreeRTOS com uma porta kernel válida do FreeRTOS.

  • Uma implementação funcional do PAL OTA.

Portabilidade

  • Adicione Freertos-Libraries-Integration-Tests como um submódulo em seu projeto. O submódulo deve ser localizado no projeto onde ele possa ser compilado.

  • Copie config_template/test_execution_config_template.h e config_template/test_param_config_template.h para um local no caminho de compilação e renomeie-os para test_execution_config.h e test_param_config.h.

  • Inclua os arquivos relevantes no sistema de compilação. Se estiver usando CMake, qualification_test.cmake e src/ota_pal_tests.cmake podem ser usados para incluir os arquivos relevantes.

  • Configure o teste implementando as seguintes funções:

    • SetupOtaPalTestParam() definido em src/ota/ota_pal_test.h. A implementação deve ter exatamente o mesmo nome e assinatura definidos em ota_pal_test.h. No momento, não é necessário configurar essa função.

  • Implemente UNITY_OUTPUT_CHAR para que os logs de saída do teste não intercalem com os logs do dispositivo.

  • Chame RunQualificationTest() da aplicação. O hardware do dispositivo deve ser inicializado corretamente e a rede deve estar conectada antes da chamada.

Testar

Esta seção descreve os testes locais dos testes de qualificação PAL OTA.

Habilitação do teste

Abra test_execution_config.h e defina OTA_PAL_TEST_ENABLED como 1.

Em test_param_config.h, atualize as seguintes opções:

  • OTA_PAL_TEST_CERT_TYPE: selecione o tipo de certificado usado.

  • OTA_PAL_CERTIFICATE_FILE: caminho para o certificado do dispositivo, se aplicável.

  • OTA_PAL_FIRMWARE_FILE: nome do arquivo de firmware, se aplicável.

  • OTA_PAL_USE_FILE_SYSTEM: defina como 1 se o PAL OTA usar abstração do sistema de arquivos.

Compile e instale a aplicação usando uma cadeia de ferramentas de sua escolha. Quando RunQualificationTest() for chamado, os testes PAL OTA serão executados. Os resultados do teste são enviados para a porta serial.

Integração de tarefas OTA

  • Adicione o agente OTA à demonstração atual do MQTT.

  • Execute testes de ponta a ponta (E2E) OTA com o AWS IoT. Isso verifica se a integração está funcionando conforme esperado.

nota

Para qualificar oficialmente um dispositivo para FreeRTOS, você deve validar o código-fonte transferido do dispositivo nos grupos de teste PAL OTA e E2E OTA com o AWS IoT Device Tester. Siga as instruções em Usar o AWS IoT Device Tester Device Tester para o FreeRTOS no Guia do usuário do FreeRTOS para configurar o AWS IoT Device Tester para validação de porta. Para testar a portabilidade de uma biblioteca específica, o grupo de testes correto deve ser habilitado no arquivo device.json na pasta do AWS IoT Device Tester configs.

Bootloader de dispositivo de IoT

Você deve fornecer a própria aplicação de carregamento de inicialização seguro. Verifique se o design e a implementação fornecem uma mitigação adequada das ameaças à segurança. A seguir confira a modelagem de ameaças para sua referência.

Modelagem de ameaças para o bootloader de dispositivos de IoT

Contexto

Como uma definição de trabalho, os dispositivos do AWS IoT incorporados referenciados por esse modelo de ameaça são produtos baseados em microcontroladores que interagem com serviços em nuvem. Eles podem ser implantados em ambientes de consumo, comerciais ou industriais. Os dispositivos de IoT podem coletar dados sobre um usuário, um paciente, uma máquina ou um ambiente, além de poderem controlar qualquer coisa, desde lâmpadas e fechaduras de porta até máquinas de fábrica.

A modelagem de ameaças é uma abordagem da segurança do ponto de vista de um adversário hipotético. Considerando as metas e os métodos do adversário, uma lista de ameaças é criada. Ameaças são ataques contra um recurso ou ativo executado por um adversário. A lista é priorizada e usada para identificar ou criar soluções de mitigações. Ao escolher uma solução de mitigação, o custo de implementá-la e mantê-la deve ser equilibrado com o valor real de segurança que ela fornece. Existem várias metodologias de modelos de ameaças. Todas elas são capazes de ajudar o desenvolvimento de um produto de AWS IoTseguro e bem-sucedido.

O FreeRTOS oferece atualizações de software OTA (sem fios) para dispositivos AWS IoT. O recurso de atualização combina serviços em nuvem com bibliotecas de software no dispositivo e um bootloader fornecido pelo parceiro. Esse modelo de ameaça se concentra especificamente em ameaças contra o bootloader.

Casos de uso do bootloader

  • Assine e criptografe digitalmente o firmware antes da implantação.

  • Implante novas imagens de firmware em um único dispositivo, um grupo de dispositivos ou toda a frota.

  • Verificar a autenticidade e a integridade do novo firmware depois de implantá-lo nos dispositivos.

  • Os dispositivos só executam software não modificado de uma origem confiável.

  • Os dispositivos são resilientes a software com falha recebido por meio do OTA.

Diagrama de fluxo de dados

Diagrama de fluxo de dados para segurança de dispositivos incorporados, contendo acesso físico, dispositivo incorporado, limite da Internet e outros componentes.

Ameaças

Alguns ataques têm vários modelos de mitigação; por exemplo, um man-in-the-middle da rede destinado a entregar uma imagem de firmware mal-intencionada é atenuado pela verificação da confiança no certificado oferecido pelo servidor TLS e no certificado de verificação de assinatura da nova imagem de firmware. Para maximizar a segurança do carregador de inicialização, toda solução de mitigação que não sejam dele será consideradas não confiável. O carregador de inicialização deve ter soluções de mitigação intrínsecas para cada ataque. Ter soluções de mitigação em camadas é conhecido como defesa completa.

Ameaças:

  • Um invasor sequestra a conexão do dispositivo com o servidor para entregar uma imagem de firmware mal-intencionada.

    Exemplo de atenuação

    • Na inicialização, o bootloader verifica a assinatura criptográfica da imagem usando um certificado conhecido. Se a verificação falhar, o bootloader reverterá para a imagem anterior.

  • Um invasor explora um estouro de buffer para introduzir comportamento mal-intencionado na imagem de firmware existente armazenada em flash.

    Exemplos de atenuação

    • Na inicialização, o bootloader verifica, conforme descrito anteriormente. Quando a verificação falha sem nenhuma imagem anterior disponível, o bootloader é interrompido.

    • Na inicialização, o bootloader verifica, conforme descrito anteriormente. Quando a verificação falha sem nenhuma imagem anterior disponível, o carregador de inicialização entra em um modo somente OTA à prova de falhas.

  • Um invasor inicializa o dispositivo em uma imagem armazenada anteriormente, que é explorável.

    Exemplos de atenuação

    • Os setores flash que armazenam a última imagem são apagados após a instalação e o teste bem-sucedidos de uma nova imagem.

    • Um fusível é queimado a cada atualização bem-sucedida, e cada imagem se recusa a ser executada, a menos que o número correto de fusíveis tenha sido queimado.

  • Uma atualização OTA fornece uma imagem com falha ou mal-intencionada que bloqueia o dispositivo.

    Exemplo de atenuação

    • O bootloader inicia um temporizador de vigilância de hardware que aciona a reversão para a imagem anterior.

  • Um invasor corrige o bootloader para ignorar a verificação de imagem para que o dispositivo aceite imagens não assinadas.

    Exemplos de atenuação

    • O bootloader está em ROM (memória somente leitura) e não pode ser modificado.

    • O bootloader está em OTP (memória programável única) e não pode ser modificado.

    • O bootloader está na zona segura do ARM TrustZone e não pode ser modificado.

  • Um invasor substitui o certificado de verificação para que o dispositivo aceite imagens mal-intencionadas.

    Exemplos de atenuação

    • O certificado está em um coprocessador criptográfico e não pode ser modificado.

    • O certificado está em ROM (ou OTP ou zona segura) e não pode ser modificado.

Modelagem adicional de ameaças

Esse modelo de ameaça considera apenas o bootloader. Uma modelagem de ameaças mais ampla pode melhorar a segurança geral. Um método recomendado é listar as metas do adversário, os ativos visados por essas metas e os pontos de entrada dos ativos. Uma lista de ameaças pode ser feita considerando ataques aos pontos de entrada para ganhar controle dos ativos. Veja a seguir listas de exemplos de metas, ativos e pontos de entrada para um dispositivo IoT. Essas listas não são exaustivas e têm como objetivo estimular uma reflexão mais aprofundada.

Metas do adversário

  • Extorquir dinheiro

  • Arruinar reputações

  • Falsificar dados

  • Desviar recursos

  • Espionar remotamente um alvo

  • Obter acesso físico a um site

  • Causar estragos

  • Incutir terror

Principais ativos

  • Chaves privadas

  • Certificado do cliente

  • Certificados CA raiz

  • Credenciais e tokens de segurança

  • Informações de identificação pessoal do cliente

  • Implementações de segredos comerciais

  • Dados do sensor

  • Armazenamento de dados de análise na nuvem

  • Infraestrutura de nuvem

Pontos de entrada

  • Resposta DHCP

  • Resposta DNS

  • MQTT por TLS

  • Resposta HTTPS

  • Imagem de software OTA

  • Outros, conforme determinado pela aplicação, por exemplo, USB

  • Acesso físico ao barramento

  • IC desanexado