Afficher le code source sur GitHub
Certaines fonctionnalités avancées sont facultatives, selon qu'elles sont compatibles ou non avec la plate-forme matérielle cible.
Cadre 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. La seconde option est principalement conçue pour les appareils de fin de sommeil (SED) qui dorment la plupart du temps et qui s'activent régulièrement pour interroger le parent afin d'obtenir des données en file d'attente.
Transmission directe : le parent envoie une trame de données directement à l'appareil final
Transmission indirecte : le parent conserve les données jusqu'à ce qu'il soit demandé par l'appareil final auquel il est destiné.
Dans le cas indirect, un 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 alors s'il possède des données pour l'appareil enfant. Si tel est le cas, il envoie un paquet de données à l'appareil enfant, qui accuse réception des données.
Si la radio accepte de manière dynamique la définition du bit d'attente d'image dans les accusés de réception sortants pour les SED, les pilotes doivent implémenter l'API de correspondance de l'adresse source pour activer cette fonctionnalité. OpenThread utilise cette API pour indiquer à la radio les SED pour lesquels elle doit définir le bit Frame Pending.
Si le signal radio n'est pas compatible avec la définition dynamique du bit d'attente d'images, il est possible qu'il bouchonne l'API de correspondance d'adresse source pour qu'il renvoie OT_ERROR_NOT_IMPLEMENTED.
Analyse et détection d'énergie avec radio
La fonctionnalité de recherche et de détection d'énergie nécessite que la puce radio échantillonne l'énergie présentée sur les canaux sélectionnés et renvoie la valeur énergétique détectée à la couche supérieure.
Si cette fonctionnalité n'est pas mise en œuvre, la couche MAC de la norme IEEE 802.15.4 envoie/reçoit un paquet de demande de réponse/balise pour évaluer la valeur énergétique actuelle du canal.
Si la puce radio est compatible avec Energy Scan/Detect, désactivez la logique d'analyse énergétique du logiciel en définissant la macro OPENTHREAD_CONFIG_ENABLE_SOFTWARE_ENERGY_SCAN = 0.
Accélération matérielle pour 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 des implémentations alternatives d'AES, SHA1, SHA2 et d'autres modules, ainsi que des fonctions individuelles pour le module de cryptographie sur les courbes elliptiques (ECC) sur GF(p). Pour en savoir plus, consultez la section Accélération matérielle mbedTLS.
OpenThread n'active pas ces macros. Par conséquent, les algorithmes cryptographiques symétriques, les algorithmes de hachage et les fonctions ECC utilisent tous des implémentations logicielles par défaut. Ces implémentations nécessitent des ressources de calcul et de mémoire considérables. Pour des performances optimales et une meilleure expérience utilisateur, nous vous recommandons d'activer l'accélération matérielle plutôt que le logiciel afin de mettre en œuvre 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 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 de nrf52811.cmake :
target_compile_definitions(ot-config INTERFACE
"MBEDTLS_USER_CONFIG_FILE=\"nrf52811-mbedtls-config.h\""
)
Les macros commentées 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 complet de configuration spécifique à un utilisateur, consultez le fichier mbedtls_config_autogen.h dans ot-efr32.
Module AES
OpenThread Security applique la cryptomonnaie CCM (Counter with CBC-MAC) pour chiffrer/déchiffrer les messages IEEE 802.15.4 ou MLE, puis valide le code d'intégration des messages. L'accélération matérielle doit au moins prendre en charge le mode AES ECB (Electronic Codebook Book) de base pour l'appel fonctionnel AES CCM.
Pour utiliser une autre mise en œuvre de module AES:
- Définir la macro
MBEDTLS_AES_ALTdans le fichier d'en-tête de configuration mbedTLS propre à l'utilisateur - Indiquez le chemin d'accès du fichier
aes_alt.hà l'aide de la variableMBEDTLS_CPPFLAGS.
Module SHA256
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 de clés PSKc conformément à la spécification de thread.
Pour utiliser une autre implémentation de base du module SHA256:
- Définir la macro
MBEDTLS_SHA256_ALTdans le fichier d'en-tête de configuration mbedTLS propre à l'utilisateur - Indiquez le chemin d'accès du fichier
sha256_alt.hà l'aide de la variableMBEDTLS_CPPFLAGS.
Fonctions ECC
Étant donné que mbedTLS n'est actuellement compatible qu'avec l'accélération matérielle pour des parties de fonctions ECC, et non pour l'ensemble du module, vous pouvez choisir d'implémenter certaines fonctions définies dans path-to-mbedtls/library/ecp.c pour accélérer la multiplication de 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 incurvée secp256r1. Pour voir un exemple, consultez SiLabs CRYPTO Hardware Acceleration for mbedTLS.