Implementare le funzionalità avanzate

Visualizza sorgente su GitHub

Alcune funzionalità avanzate sono facoltative, a seconda che siano supportate o meno sulla piattaforma hardware di destinazione.

Frame automatico in attesa

IEEE 802.15.4 definisce due tipi di metodi di trasmissione dati tra padre e secondario: trasmissione diretta e trasmissione indiretta. Quest'ultima è progettata principalmente per i dispositivi finali sonno-veglia attiva (SED) che dormono per la maggior parte del tempo, riattivando periodicamente il sondaggio per individuare dati in coda.

  • Trasmissione diretta: il genitore invia un frame di dati direttamente al dispositivo finale Trasmissione diretta

  • Trasmissione indiretta: il genitore blocca i dati finché non viene richiesto dal dispositivo finale previsto Trasmissione diretta

Nel caso indiretto, un dispositivo finale secondario deve prima interrogare il genitore per determinare se sono disponibili dati. A tal fine, il publisher secondario invia una richiesta di dati, che il genitore riconosce. L'elemento principale determina quindi se sono presenti dati per il dispositivo secondario. In questo caso, invia un pacchetto di dati al dispositivo secondario, che conferma la ricezione dei dati.

Se la radio supporta l'impostazione dinamica del bit Frame Pending nelle conferme in uscita ai SED, i driver devono implementare l'API source address match per attivare questa funzionalità. OpenThread utilizza questa API per indicare alla radio per i SED di impostare il bit Frame in attesa.

Se la radio non supporta l'impostazione dinamica del bit Frame Pending, la radio potrebbe eliminare l'API Match di origine per restituire OT_ERROR_NOT_IMPLEMENTED.

Scansione/rilevazione dell'energia con radio

La funzionalità Energy Scan/Detect richiede il chip radio per campionare l'energia presentata sui canali selezionati e restituire il valore di energia rilevato al livello superiore.

Se questa funzionalità non è implementata, il livello MAC IEEE 802.15.4 invia/riceve un pacchetto di richiesta/risposta beacon per valutare il valore di energia corrente sul canale.

Se il chip radio supporta Scan/Detect di energia, assicurati di disabilitare la logica di scansione energetica del software impostando la macro OPENTHREAD_CONFIG_ENABLE_SOFTWARE_ENERGY_SCAN = 0.

Accelerazione hardware per mbedTLS

mbedTLS definisce diverse macro nel file di intestazione configurazione principale, mbedtls-config.h, per consentire agli utenti di attivare implementazioni alternative di AES, SHA1, SHA2 e altri moduli nonché funzioni individuali per la crittografia ellittica (ECC) rispetto al modulo GF(p). Per ulteriori informazioni, consulta Accelerazione hardware mbedTLS.

OpenThread non abilita tali macro, pertanto gli algoritmi di crittografia simmetrica, gli algoritmi hash e le funzioni ECC utilizzano tutte le implementazioni del software per impostazione predefinita. Queste implementazioni richiedono notevoli risorse di memoria e di calcolo. Per prestazioni ottimali e una migliore esperienza utente, consigliamo di attivare l'accelerazione hardware anziché il software per implementare le operazioni di cui sopra.

Per abilitare l'accelerazione hardware in OpenThread, devi aggiungere i seguenti file di intestazione di configurazione mbedTLS alle definizioni di compilazione ot-config nei file CMake della piattaforma:

  • Configurazione principale, che definisce tutte le macro necessarie utilizzate in OpenThread: /openthread/third-party/mbedtls/mbedtls-config.h
  • Configurazione specifica per l'utente, che definisce le implementazioni alternative di moduli e funzioni: src/platform-name-mbedtls-config.h

Esempio da nrf52811.cmake:

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

Le macro con commenti in mbedtls-config.h non sono obbligatorie e possono essere abilitate nel file di intestazione della configurazione specifica dell'utente per l'accelerazione hardware.

Per un esempio completo di configurazione specifica per l'utente, consulta il file mbedtls_config_autogen.h in ot-efr32.

Modulo AES

OpenThread Security applica la crittografia AES CCM (Counter with CBC-MAC) per criptare/decriptare i messaggi IEEE 802.15.4 o MLE e convalida il codice di integrazione dei messaggi. L'accelerazione hardware dovrebbe supportare almeno la modalità ECB AES (Electronic Codebook Book) di base per le chiamate funzionali di base AES CCM.

Per utilizzare un'implementazione alternativa del modulo AES:

  1. Definisci la macro MBEDTLS_AES_ALT nel file di intestazione mbedTLS specifico dell'utente
  2. Indica il percorso del file aes_alt.h utilizzando la variabile MBEDTLS_CPPFLAGS

Modulo SHA256

OpenThread Security applica algoritmi hash HMAC e SHA256 per calcolare il valore hash per la gestione delle chiavi di rete e la generazione di PSKc in base alla specifica dei thread.

Per utilizzare un'implementazione di base del modulo SHA256 alternativa:

  1. Definisci la macro MBEDTLS_SHA256_ALT nel file di intestazione mbedTLS specifico dell'utente
  2. Indica il percorso del file sha256_alt.h utilizzando la variabile MBEDTLS_CPPFLAGS

Funzioni ECC

Poiché mbedTLS attualmente supporta solo l'accelerazione hardware per parti delle funzioni ECC, anziché l'intero modulo, puoi scegliere di implementare alcune funzionalità definite in path-to-mbedtls/library/ecp.c per accelerare la moltiplicazione dei punti ECC.

La curva secp256r1 viene utilizzata nell'algoritmo di scambio di chiavi della bozza ECJPAKE. L'accelerazione hardware dovrebbe quindi supportare almeno il funzionamento della curva weierstrass breve secp256r1. Per un esempio, vedi la pagina relativa all'accelerazione hardware di CRYPTO di SiLab per mbedTLS.