Mettre en œuvre des fonctionnalités avancées

Afficher la source sur GitHub

Certaines fonctionnalités avancées sont facultatives, selon qu'elles sont compatibles ou non sur la plate-forme matérielle cible.

Frame automatique en attente

La norme IEEE 802.15.4 définit deux types de méthodes de transmission de données entre le parent et l'enfant: la transmission directe et la transmission indirecte. Le second est conçu principalement pour les appareils finaux endormis (SED), qui se réveillent la plupart du temps afin d'interroger régulièrement le parent pour rechercher des données en file d'attente.

  • Transmission directe : le parent envoie une trame de données directement à l'appareil final Transmission directe

  • Transmission indirecte : le parent conserve les données jusqu'à ce que l'appareil final auquel elle est destinée soit demandé.Transmission directe

Dans le cas indirect, l'appareil enfant doit d'abord interroger le parent pour déterminer si des données sont disponibles. Pour ce faire, l'enfant envoie une requête de données, que le parent confirme. Le parent détermine ensuite s'il dispose de données pour l'appareil enfant. Si tel est le cas, il envoie un paquet de données à l'appareil enfant, qui en accuse réception.

Si la radio permet de définir de manière dynamique le bit de trame en attente dans les accusés de réception sortants des SED, les pilotes doivent mettre en œuvre l'API de correspondance d'adresse source pour activer cette fonctionnalité. OpenThread utilise cette API pour indiquer à la radio les SED pour lesquels le bit de trame en attente est défini.

Si la radio n'accepte pas le paramétrage dynamique du bit de trame en attente, elle peut bouchonner l'API de correspondance d'adresse source pour renvoyer OT_ERROR_NOT_IMPLEMENTED.

Énergie/Détection avec la radio

La fonctionnalité de détection d'énergie nécessite que la puce radio échantillonne la quantité d'énergie présente sur les canaux sélectionnés et renvoie la valeur d'énergie détectée à la couche supérieure.

Si cette fonctionnalité n'est pas mise en œuvre, la couche MAC IEEE 802.15.4 envoie/reçoit un paquet de requête/réponse de balise pour évaluer la valeur énergétique actuelle sur le canal.

Si la puce radio est compatible avec la détection d'énergie, veillez à désactiver la logique de recherche d'énergie logicielle en définissant la macro OPENTHREAD_CONFIG_ENABLE_SOFTWARE_ENERGY_SCAN = 0.

Accélération matérielle de mbedTLS

mbedTLS définit plusieurs macros dans le fichier d'en-tête de configuration principal, mbedtls-config.h, pour permettre aux utilisateurs d'activer d'autres implémentations d'AES, de SHA1 et de SHA2, ainsi que d'autres modules. et des fonctions individuelles pour le module de cryptographie sur les courbes elliptiques (ECC) via le module GF(p). Pour plus d'informations, consultez la page Accélération matérielle de mbedTLS.

OpenThread n'active pas ces macros. Par conséquent, les algorithmes de chiffrement symétriques, les algorithmes de hachage et les fonctions ECC utilisent tous des mises en œuvre logicielles par défaut. Ces mises en œuvre nécessitent une quantité importante de mémoire et de ressources de calcul. Pour des performances optimales et une meilleure expérience utilisateur, nous vous recommandons d'activer l'accélération matérielle plutôt que logicielle afin d'effectuer les opérations ci-dessus.

Pour activer l'accélération matérielle dans OpenThread, les fichiers d'en-tête de configuration mbedTLS suivants doivent être ajoutés aux définitions de compilation ot-config dans les fichiers CMake de la plate-forme:

  • Configuration principale, qui définit toutes les macros nécessaires utilisées dans OpenThread : /openthread/third-party/mbedtls/mbedtls-config.h
  • Configuration spécifique à l'utilisateur, qui définit d'autres implémentations de modules et de fonctions: src/platform-name-mbedtls-config.h

Exemple pour nrf52811.cmake:

target_compile_definitions(ot-config INTERFACE
    "MBEDTLS_USER_CONFIG_FILE=\"nrf52811-mbedtls-config.h\""
)

Les macros avec commentaires dans mbedtls-config.h ne sont pas obligatoires et peuvent être activées dans le fichier d'en-tête de configuration spécifique à l'utilisateur pour l'accélération matérielle.

Pour obtenir un exemple de configuration spécifique à l'utilisateur, consultez le fichier mbedtls_config_autogen.h dans ot-efr32.

Module AES

OpenThread Security applique le chiffrement AES CCM (compteur avec CBC-MAC) pour chiffrer/déchiffrer les messages IEEE 802.15.4 ou MLE, et valide le code d'intégration. L'accélération matérielle doit au moins être compatible avec le mode AES ECB de base (Electronic Codebook Book) pour l'appel fonctionnel AES CCM de base.

Pour utiliser une autre mise en œuvre de module AES, procédez comme suit:

  1. Définir la macro MBEDTLS_AES_ALT dans l'en-tête de configuration mbedTLS spécifique à l'utilisateur
  2. Indiquez le chemin d'accès au fichier aes_alt.h à l'aide de la variable MBEDTLS_CPPFLAGS.

Module SHA-256

OpenThread Security applique des algorithmes de hachage HMAC et SHA256 pour calculer la valeur de hachage pour la gestion des clés réseau et la génération PSKc conformément à la spécification Thread.

Pour utiliser une autre implémentation de base du module SHA256:

  1. Définir la macro MBEDTLS_SHA256_ALT dans l'en-tête de configuration mbedTLS spécifique à l'utilisateur
  2. Indiquez le chemin d'accès au fichier sha256_alt.h à l'aide de la variable MBEDTLS_CPPFLAGS.

Fonctions ECC

Comme mbedTLS n'est actuellement compatible qu'avec l'accélération matérielle pour certaines parties des fonctions ECC, et non pour l'ensemble du module, vous pouvez choisir de mettre en œuvre certaines fonctions définies dans path-to-mbedtls/library/ecp.c pour accélérer la multiplication des points ECC.

La courbe secp256r1 est utilisée dans l'algorithme d'échange de clés du brouillon ECJPAKE. Par conséquent, l'accélération matérielle doit au moins prendre en charge l'opération de courbe courtisée secp256r1. Pour obtenir un exemple, consultez SiLabs CRYPTO Hardware Acceleration for mbedTLS.