Erweiterte Funktionen implementieren

Quelle auf GitHub ansehen

Von Mason Tran

Beitragender von SiLabs

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 Netzwerk: direkte und indirekte Übertragung. Letzteres ist in erster Linie für schläfrige Endgeräte (SEDs) gedacht, die die meiste Zeit schlafen, und in regelmäßigen Abständen wach wird, um das übergeordnete Element in der Warteschlange zu stellen.

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

• Indirekte Übertragung: Der übergeordnete Partner speichert Daten, bis dies vom gewünschten Endgerät angefordert wird.

Im Fall eines indirekten Vorgangs muss ein untergeordnetes Endgerät zuerst das übergeordnete Element abfragen, um festzustellen, ob Daten dafür zur Verfügung stehen. Dazu sendet das untergeordnete Element eine Datenanfrage, die vom übergeordneten Server bestätigt wird. Das übergeordnete Element bestimmt dann, ob es Daten für das untergeordnete Gerät hat. Wenn ja, sendet es ein Datenpaket an das untergeordnete Gerät, das den Empfang der Daten bestätigt.

Wenn das Funkgerät das Frame-Ausstehend-Bit bei ausgehenden Bestätigungen für SEDs dynamisch festlegen kann, müssen die Treiber die API-Abgleichadresse implementieren, um diese Funktion zu aktivieren. OpenThread verwendet diese API, um dem Funkgerät mitzuteilen, für welche SEDs das Frame Ausstehend-Bit gesetzt werden soll.

Wenn das Radio das Festlegen des Frames für „Ausstehend“ nicht unterstützt, kann das Funkgerät die Stub-API für die Quelladresse so aufbereiten, dass OT_ERROR_NOT_IMPLEMENTED zurückgegeben wird.

Energiescans/-erkennung per Funk

Die Funktion „Energy Scan/Detect“ erfordert, dass der Funkchip die auf ausgewählten Kanälen präsentierte Energie abtastet und den erkannten Energiewert auf der oberen Ebene zurückgibt.

Wenn diese Funktion nicht implementiert ist, sendet/empfangen die MAC-Ebenen des IEEE 802.15.4 ein Beacon-Anfrage-/Antwortpaket, um den aktuellen Energiewert im Kanal zu bewerten.

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

Hardwarebeschleunigung für mbedTLS

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

OpenThread aktiviert diese Makros nicht, sodass die symmetrischen kryptografischen Algorithmen, Hash-Algorithmen und ECC-Funktionen standardmäßig Softwareimplementierungen verwenden. Diese Implementierungen erfordern viel Arbeitsspeicher und Rechenressourcen. Für eine optimale Leistung und eine bessere Nutzererfahrung empfehlen wir, die Hardwarebeschleunigung anstelle von Software zu aktivieren, um die oben genannten Vorgänge zu implementieren.

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

• Hauptkonfiguration, in der alle in OpenThread verwendeten Makros definiert sind: /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 für die Hardwarebeschleunigung in der nutzerspezifischen Konfigurationsdatei im Header aktiviert werden.

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

AES-Modul

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

So verwenden Sie eine alternative AES-Modulimplementierung:

1. Definieren Sie das Makro MBEDTLS_AES_ALT in der nutzerspezifischen mbedTLS-Konfigurationsheaderdatei
2. Geben Sie den Pfad der Datei aes_alt.h mit der Variablen MBEDTLS_CPPFLAGS an.

SHA256-Modul

OpenThread Security wendet HMAC- und SHA256-Hash-Algorithmen an, um den Hashwert für die Verwaltung von Netzwerkschlüsseln und die PSKc-Generierung gemäß der Threadspezifikation zu berechnen.

So verwenden Sie eine alternative grundlegende SHA256-Modulimplementierung:

1. Definieren Sie das Makro MBEDTLS_SHA256_ALT in der nutzerspezifischen mbedTLS-Konfigurationsheaderdatei
2. Geben Sie den Pfad der Datei sha256_alt.h mit der Variablen MBEDTLS_CPPFLAGS an.

ECC-Funktionen

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

Die Kurve secp256r1 wird im Schlüsselaustauschalgorithmus des ECJPAKE-Entwurfs verwendet. Daher sollte die Hardwarebeschleunigung zumindest den secp256r1-kurzen Weierstrass-Betrieb unterstützen. Ein Beispiel finden Sie unter SiLabs CRYPTO-Hardwarebeschleunigung für mbedTLS.