Erweiterte Funktionen implementieren

Quelle auf GitHub ansehen

Einige erweiterte Funktionen sind optional, je nachdem, ob sie auf der Zielhardwareplattform unterstützt werden oder nicht.

Automatischer Frame ausstehend

IEEE 802.15.4 definiert zwei Arten von Datenübertragungsmethoden zwischen übergeordnetem und untergeordnetem Element: direkte Übertragung und indirekte Übertragung. Das letztere ist hauptsächlich für schläfrige Endgeräte (SEDs) vorgesehen, die die meiste Zeit inaktiv sind und in regelmäßigen Abständen den übergeordneten Dienst nach Daten in der Warteschlange fragen.

  • Direkte Übertragung: Ein Elternteil sendet einen Datenframe direkt an das Endgerät Direkte Übertragung

  • Indirekte Übertragung – übergeordnete Daten werden so lange aufbewahrt, bis sie vom beabsichtigten Endgerät angefordert werden Direkte Übertragung

Im indirekten Fall muss ein untergeordnetes Endgerät zuerst das übergeordnete Netzwerk abfragen, um festzustellen, ob Daten dafür verfügbar sind. Dazu sendet das untergeordnete Element eine Datenanfrage, die der Elternteil bestätigt. Das übergeordnete Element legt dann fest, ob Daten für das untergeordnete Gerät vorhanden sind. Falls ja, wird ein Datenpaket an das untergeordnete Gerät gesendet, das den Empfang der Daten bestätigt.

Wenn das Radio das FrameFrame Pending“-Bit in ausgehenden Bestätigungen für SEDs dynamisch festlegt, müssen die Treiber die Source Address Match API implementieren, um diese Funktion zu aktivieren. OpenThread nutzt diese API, um dem Radio mitzuteilen, für welche SEDs das Frame-Bit gesetzt werden soll.

Wenn das Radio das Bits FrameFrame Pending“ nicht dynamisch unterstützt, kann das Radio die Quelladressen-Übereinstimmungs-API kürzen, um OT_ERROR_NOT_IMPLEMENTED zurückzugeben.

Energiescan/-detektor mit Funkanlage

Bei der Funktion "Energiescan/Erkennung" muss der Funkchip Strom von den ausgewählten Kanälen abtasten und den erkannten Energiewert an die obere Ebene zurückgeben.

Ist dieses Feature nicht implementiert, sendet die MAC-Ebene IEEE 802.15.4 ein Beacon-Anfrage-/Antwort-Paket, um den aktuellen Energiewert des Kanals zu bewerten.

Wenn der Funkchip Energy Scan/Detect unterstützt, müssen Sie die Software-Energiescan-Logik deaktivieren, indem Sie das Makro OPENTHREAD_CONFIG_ENABLE_SOFTWARE_ENERGY_SCAN = 0 festlegen.

Hardwarebeschleunigung für mbedTLS

mbedTLS definiert in der Hauptkonfigurationsdatei mbedtls-config.h mehrere Makros, damit Nutzer alternative Implementierungen von AES, SHA1, SHA2 und anderen Modulen aktivieren können. sowie einzelne Funktionen für die Elliptische-Kurven-Kryptografie (ECC) über das GF(p)-Modul. Weitere Informationen finden Sie unter mbedTLS-Hardwarebeschleunigung.

OpenThread aktiviert diese Makros nicht. Daher verwenden alle symmetrischen Kryptoalgorithmen, Hash-Algorithmen und ECC-Funktionen standardmäßig Softwareimplementierungen. Diese Implementierungen benötigen erheblichen Speicher und Rechenressourcen. Für eine optimale Leistung und Nutzerfreundlichkeit empfehlen wir die Aktivierung der Hardwarebeschleunigung anstelle der Software zur Implementierung der oben genannten Vorgänge.

Um die Hardwarebeschleunigung in OpenThread zu aktivieren, sollten die folgenden mbedTLS-Konfigurationsheaderdateien den ot-config-Kompildefinitionen in den CMake-Dateien der Plattform hinzugefügt werden:

  • Hauptkonfiguration, die alle erforderlichen Makros in OpenThread definiert: /openthread/third-party/mbedtls/mbedtls-config.h
  • Nutzerspezifische Konfiguration, die alternative Implementierungen von Modulen und Funktionen definiert: src/platform-name-mbedtls-config.h

Beispiel aus nrf52811.cmake:

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

Kommentierte Makros in mbedtls-config.h sind nicht obligatorisch und können in der nutzerspezifischen Konfigurationsheader-Datei für die Hardwarebeschleunigung aktiviert werden.

Eine vollständige beispielhafte nutzerspezifische Konfiguration finden Sie in der Datei mbedtls_config_autogen.h in ot-efr32.

AES-Modul

OpenThread Security wendet AES-CCM (Crypto mit CBC-MAC) an, um IEEE 802.15.4- oder MLE-Nachrichten zu verschlüsseln/entschlüsseln und den Nachrichtenintegrationscode zu validieren. Die Hardwarebeschleunigung sollte mindestens den einfachen AES ECB-Modus (Electronic Codebook Book) für den einfachen AES CCM-Funktionsaufruf unterstützen.

So verwenden Sie eine alternative Implementierung für AES-Module:

  1. Definieren Sie das Makro MBEDTLS_AES_ALT in der nutzerspezifischen Headerdatei der mbedTLS-Konfiguration.
  2. Geben Sie den Pfad der Datei aes_alt.h mithilfe der Variable MBEDTLS_CPPFLAGS an.

SHA256-Modul

OpenThread Security wendet HMAC- und SHA256-Hash-Algorithmen an, um den Hash-Wert für die Netzwerkschlüsselverwaltung und die PSKc-Generierung gemäß der Thread-Spezifikation zu berechnen.

So verwenden Sie eine alternative grundlegende SHA256-Modulimplementierung:

  1. Definieren Sie das Makro MBEDTLS_SHA256_ALT in der nutzerspezifischen Headerdatei der mbedTLS-Konfiguration.
  2. Geben Sie den Pfad der Datei sha256_alt.h mithilfe der Variable MBEDTLS_CPPFLAGS an.

ECC-Funktionen

Da mbedTLS derzeit nur für Teile von ECC-Funktionen Hardwarebeschleunigung und nicht das gesamte Modul unterstützt, können Sie einige in path-to-mbedtls/library/ecp.c definierte Funktionen implementieren, um die ECC-Punktmultiplikation zu beschleunigen.

Kurve secp256r1 wird im Schlüsselaustauschalgorithmus des ECJPAKE-Entwurfs verwendet. Daher sollte die Hardwarebeschleunigung mindestens die Secp256r1-Kurzweisungskurve unterstützen. Ein Beispiel finden Sie unter SiLabs CRYPTO Hardware Acceleration for mbedTLS.