Alguns recursos avançados são opcionais, dependendo se são compatíveis ou não na plataforma de hardware de destino.
Frame automático pendente
O IEEE 802.15.4 define dois tipos de métodos de transmissão de dados entre pai e filho: transmissão direta e transmissão indireta. Este último é projetado principalmente para dispositivos de suspensão de sono (SEDs, na sigla em inglês), que dormem na maioria das vezes, acordando periodicamente para pesquisar o pai em busca de dados na fila.
Transmissão direta: o pai envia um frame de dados diretamente para o dispositivo final
Transmissão indireta: o pai mantém os dados até que seja solicitado pelo dispositivo final pretendido.
No caso indireto, um dispositivo final filho precisa primeiro pesquisar o pai para determinar se há dados disponíveis para ele. Para fazer isso, o filho envia uma solicitação de dados, que o pai confirma. O pai determina se tem dados para o dispositivo filho. Nesse caso, ele envia um pacote de dados para o dispositivo filho, que confirma o recebimento dos dados.
Se o rádio for compatível com a configuração dinâmica do bit "Pendente" do frame em confirmações de saída para SEDs, os drivers precisarão implementar a API de correspondência de endereço de origem para ativar esse recurso. O OpenThread usa essa API para informar ao rádio quais SEDs serão definidos como o bit de frame pendente.
Se o rádio não for compatível com a configuração dinâmica do bit de frame pendente, ele
poderá fragmentar a API de correspondência de endereço de origem para retornar
OT_ERROR_NOT_IMPLEMENTED.
Detecção/verificação de energia com rádio
O recurso Verificação de energia/detecção exige que o chip de rádio simule a energia apresentada nos canais selecionados e retorne o valor de energia detectado à camada superior.
Se esse recurso não for implementado, a camada MAC IEEE 802.15.4 enviará/receberá um pacote de solicitação/resposta de beacon para avaliar o valor energia atual no canal.
Se o chip de rádio for compatível com a Detecção/detecção de energia, desative a lógica
de verificação de energia de software configurando a macro
OPENTHREAD_CONFIG_ENABLE_SOFTWARE_ENERGY_SCAN = 0.
Aceleração de hardware para mbedTLS
A mbedTLS define várias macros no arquivo principal de configuração,
mbedtls-config.h,
para permitir que os usuários ativem implementações alternativas do AES, SHA1, SHA2 e
outros módulos, além de funções individuais para a criptografia de curva
elíptica (ECC, na sigla em inglês) no módulo GF(p). Consulte
aceleração de hardware mbedTLS
para mais informações.
O OpenThread não ativa essas macros. Portanto, os algoritmos simétricos de criptografia, algoritmos de hash e funções de ECC usam implementações de software por padrão. Essas implementações exigem recursos computacionais e de memória consideráveis. Para otimizar o desempenho e melhorar a experiência do usuário, recomendamos ativar a aceleração de hardware, em vez de software, para implementar as operações acima.
Para ativar a aceleração de hardware no OpenThread, os seguintes arquivos principais de configuração de mbedTLS precisam ser adicionados às definições de compilação ot-config nos arquivos CMake da plataforma:
- Configuração principal, que define todas as macros necessárias usadas no OpenThread:
/openthread/third-party/mbedtls/mbedtls-config.h - Configuração específica do usuário, que define implementações alternativas de módulos e funções:
src/platform-name-mbedtls-config.h
Exemplo de nrf52811.cmake:
target_compile_definitions(ot-config INTERFACE
"MBEDTLS_USER_CONFIG_FILE=\"nrf52811-mbedtls-config.h\""
)
As macros comentadas em mbedtls-config.h não são obrigatórias e podem ser ativadas no
arquivo de cabeçalho de configuração específico do usuário para a aceleração de hardware.
Para ver um exemplo completo de configuração específica do usuário, consulte o arquivo
mbedtls_config_autogen.h
em ot-efr32.
Módulo AES
O OpenThread Security aplica a criptografia AES CCM (Counter with CBC-MAC) para criptografar/descriptografar as mensagens IEEE 802.15.4 ou MLE e valida o código de integração de mensagens. A aceleração de hardware precisa ser, no mínimo, compatível com o modo básico do AES ECB (Electronic Codebook Book) para chamadas funcionais básicas do AES CCM.
Para utilizar uma implementação alternativa do módulo AES:
- Defina a macro
MBEDTLS_AES_ALTno arquivo principal de configuração do mbedTLS específico do usuário - Indique o caminho do arquivo
aes_alt.husando a variávelMBEDTLS_CPPFLAGS
Módulo SHA256
O OpenThread Security aplica algoritmos de hash HMAC e SHA256 para calcular o valor de hash para o gerenciamento de chaves de rede e a geração de PSKc de acordo com a especificação da linha de execução.
Para utilizar uma implementação alternativa alternativa do módulo SHA256:
- Defina a macro
MBEDTLS_SHA256_ALTno arquivo principal de configuração do mbedTLS específico do usuário - Indique o caminho do arquivo
sha256_alt.husando a variávelMBEDTLS_CPPFLAGS
Funções ECC
Como o mbedTLS atualmente é compatível apenas com a aceleração de hardware para partes das funções de ECC, em vez de todo o módulo, você pode optar por implementar algumas funções definidas em path-to-mbedtls/library/ecp.c para acelerar a multiplicação de pontos de ECC.
A curva secp256r1 é usada no algoritmo de troca de chaves do rascunho ECJPAKE. Portanto, a aceleração de hardware precisa ser, no mínimo, compatível com a operação de curva curta da secp256r1. Consulte SiLabs CRYPTO Hardware Acceleration para mbedTLS para ver um exemplo.