Selecione suas preferências de cookies

Usamos cookies essenciais e ferramentas semelhantes que são necessárias para fornecer nosso site e serviços. Usamos cookies de desempenho para coletar estatísticas anônimas, para que possamos entender como os clientes usam nosso site e fazer as devidas melhorias. Cookies essenciais não podem ser desativados, mas você pode clicar em “Personalizar” ou “Recusar” para recusar cookies de desempenho.

Se você concordar, a AWS e terceiros aprovados também usarão cookies para fornecer recursos úteis do site, lembrar suas preferências e exibir conteúdo relevante, incluindo publicidade relevante. Para aceitar ou recusar todos os cookies não essenciais, clique em “Aceitar” ou “Recusar”. Para fazer escolhas mais detalhadas, clique em “Personalizar”.

Portando a biblioteca de atualização AWS IoT over-the-air (OTA) - Gratuito RTOS

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Portando a biblioteca de atualização AWS IoT over-the-air (OTA)

Com as atualizações do over-the-air FreeRTOS (OTA), você pode fazer o seguinte:

  • 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 a Assinatura de Código para AWS IoT.

Para obter mais informações, consulte as Atualizações Over-the-Air do FreeRTOS no Guia do Usuário do FreeRTOS junto com a Documentação do O Update.AWS IoT ver-the-air

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 AWS OTA 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 o aplicativo de demonstração FreeRTOS OTA no repositório do FreeRTOS. GitHub 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 AWS IoT Core:

  • AWS IoT Core credenciais do cliente

    • 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 com suas credenciais de cliente. Ota_Over_Mqtt_Demo/demo_config.h 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 do FreeRTOS OTA fornece informações detalhadas sobre como configurar um cliente OTA e AWS IoT Core uma tarefa OTA no simulador de janelas do FreeRTOS. AWS O OTA suporta 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 OTA E2E, você deve usar 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 AWS IoT Core com o mesmo ID de cliente (nome da coisa) e credenciais. AWS IoT Core em seguida, desconecta o dispositivo. Espera-se que o dispositivo detecte que está desconectado e AWS IoT Core, após um período de tempo, passe para um estado suspenso e tente se reconectar 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 OTAE2EDisconnectResume teste, exceto que depois de se conectar ao dispositivo AWS IoT Core, que desconecta o dispositivo, ele cancela a atualização do OTA. Uma nova atualização é criada. Espera-se que o dispositivo se reconecte ao AWS IoT Core, aborte 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 OTA End to End (E2E) com. 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 portado do dispositivo em relação aos grupos de teste OTA PAL e OTA E2E com. AWS IoT Device Tester Siga as instruções em Usando o FreeRTOS no Guia do Usuário do FreeRTOS AWS IoT Device Tester para configurar a validação de portas. AWS IoT Device Tester Para testar a porta de uma biblioteca específica, o grupo de teste correto deve estar habilitado no device.json arquivo na AWS IoT Device Tester configs pasta.

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 definição prática, os AWS IoT dispositivos 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. Cada um é capaz de apoiar o desenvolvimento de um AWS IoT produto seguro e bem-sucedido.

O FreeRTOS oferece atualizações de software OTA over-the-air () 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 que contém 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, uma rede man-in-the-middle destinada a fornecer uma imagem de firmware maliciosa é atenuada pela verificação da confiança no certificado oferecido pelo servidor TLS e no certificado do assinante do código da nova imagem do 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. defense-in-depth

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á na OTP (one-time-programmable memória) 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

PrivacidadeTermos do sitePreferências de cookies
© 2025, Amazon Web Services, Inc. ou suas afiliadas. Todos os direitos reservados.