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
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 de sommeil, dont le fonctionnement est la plupart du temps, et qui se réveillent régulièrement pour interroger le parent en file d'attente.
Transmission directe : le parent envoie un cadre de données directement à l'appareil final
Transmission indirecte : le parent conserve les données jusqu'à la demande de l'appareil final auquel il est destiné.
Dans le cas indirect, un appareil final enfant doit d'abord interroger le parent pour déterminer si des données sont disponibles. Pour ce faire, l'enfant envoie une demande 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 accuse réception des données.
Si la radio accepte la définition dynamique du bit de attente dans les accusés de réception sortants des SED, les pilotes doivent implémenter l'API source address match pour activer cette fonctionnalité. OpenThread utilise cette API pour indiquer à la radio pour les SED pour lesquels définir le bit de attente dans le frame.
Si la radio n'est pas compatible avec la définition dynamique du bit de attente Frame, la radio peut bouchonner l'API de correspondance d'adresse source pour renvoyer OT_ERROR_NOT_IMPLEMENTED
.
Analyse/Détection d'énergie avec radio
La fonctionnalité Energy Scan/Detect nécessite que la puce radio échantillonne l'énergie présente 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 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 d'option 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 d'autres mises en œuvre d'AES, SHA1, SHA2 et d'autres modules, ainsi que des fonctions individuelles pour le module de cryptographie à courbe elliptique (ECC) sur GF(p). Pour en savoir plus, consultez la section Accélération matérielle de TLS TLS.
OpenThread n'active pas ces macros. Par conséquent, les algorithmes, les algorithmes de hachage et les fonctions ECC symétriques utilisent tous des implémentations logicielles par défaut. Ces implémentations nécessitent une quantité considérable 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 au lieu du 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 utilisées dans OpenThread :
/openthread/third-party/mbedtls/mbedtls-config.h
- Configuration spécifique à l'utilisateur, qui définit des implémentations alternatives des modules et des fonctions:
src/platform-name-mbedtls-config.h
Exemple à partir de nrf52811.cmake
:
target_compile_definitions(ot-config INTERFACE "MBEDTLS_USER_CONFIG_FILE=\"nrf52811-mbedtls-config.h\"" )
Les macros dans le commentaire 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 à un utilisateur, consultez le fichier mbedtls_config_autogen.h
dans ot-efr32
.
Module AES
OpenThread Security applique la crypte AES CCM (Compteur avec CMAC-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 être compatible avec le mode AES (ECB) de base pour l'appel fonctionnel AES CCM de base.
Pour utiliser une autre configuration AES du module:
- Définir la macro
MBEDTLS_AES_ALT
dans le fichier d'en-tête de configuration mbedTLS spécifique à l'utilisateur - Indiquez le chemin d'accès au fichier
aes_alt.h
à l'aide de la variableMBEDTLS_CPPFLAGS
Module SHA256
OpenThread Security applique les algorithmes de hachage HMAC et SHA256 pour calculer la valeur de hachage de la gestion des clés réseau et de la génération de clé prépartagée, conformément à la spécification Thread.
Pour utiliser une autre implémentation de module SHA256 de base:
- Définir la macro
MBEDTLS_SHA256_ALT
dans le fichier d'en-tête de configuration mbedTLS spécifique à l'utilisateur - Indiquez le chemin d'accès au fichier
sha256_alt.h
à l'aide de la variableMBEDTLS_CPPFLAGS
Fonctions ECC
Pour l'instant, mbedTLS n'accepte que l'accélération matérielle pour certaines parties des fonctions ECC, et non pour l'ensemble du module. Vous pouvez donc 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 être compatible avec la fonction de courbe incurvée weisertrass secp256r1. Pour obtenir un exemple, consultez Accélération du matériel CRYPTO SiLabs.