Visualizza l'origine su GitHub
Alcune funzionalità avanzate sono facoltative, a seconda che siano supportate o meno sulla piattaforma hardware di destinazione.
Frame automatico in attesa
Lo standard IEEE 802.15.4 definisce due tipi di metodi di trasmissione dei dati tra elemento principale e secondario: trasmissione diretta e trasmissione indiretta. Quest'ultimo è progettato principalmente per i dispositivi finali assonnati (SED) che dormono la maggior parte del tempo, svegliati periodicamente per raccogliere i dati in coda ai genitori.
Trasmissione diretta: il genitore invia un frame di dati direttamente al dispositivo finale
Trasmissione indiretta: il genitore conserva i dati fino a quando non viene richiesto dal dispositivo finale previsto.
Nel caso indiretto di un dato dispositivo, quest'ultimo deve prima eseguire il polling del genitore per determinare se sono disponibili dati. Per farlo, il publisher secondario invia una richiesta di dati, che il genitore riconosce. L'elemento principale determina quindi se dispone di dati per il dispositivo secondario; in questo caso, invia un pacchetto di dati al dispositivo secondario, che conferma di aver ricevuto i dati.
Se la radio supporta l'impostazione dinamica del bit In attesa nella conferma di ricezione in uscita per i SED, i driver devono implementare l'API Source address match per abilitare questa funzionalità. OpenThread usa questa API per comunicare alla radio i SED per cui impostare il bit Frame Pending.
Se la radio non supporta l'impostazione dinamica del bit Frame Pending, la radio potrebbe eliminare l'API di corrispondenza dell'indirizzo di origine per restituire OT_ERROR_NOT_IMPLEMENTED.
Scansione/rilevamento energia con radio
La funzionalità Scansione/rilevamento energia richiede al chip radio di campionare l'energia presente sui canali selezionati e restituire il valore energetico rilevato al livello superiore.
Se questa funzionalità non viene implementata, il livello MAC IEEE 802.15.4 invia/riceve un pacchetto di richiesta/risposta di beacon per valutare il valore energetico attuale sul canale.
Se il chip della radio supporta la scansione energetica/rilevamento, 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 di configurazione principale, mbedtls-config.h, per consentire agli utenti di abilitare implementazioni alternative di AES, SHA1, SHA2 e altri moduli, nonché singole funzioni per il modulo Elliptic curva di crittografia (ECC) su GF(p). Per ulteriori informazioni, consulta la pagina relativa all'accelerazione hardware mbedTLS.
OpenThread non abilita tali macro, pertanto gli algoritmi di crittografia simmetrici, gli algoritmi hash e le funzioni ECC utilizzano tutte le implementazioni software per impostazione predefinita. Queste implementazioni richiedono una notevole quantità di memoria e risorse di calcolo. Per prestazioni ottimali e una migliore esperienza utente, ti consigliamo di abilitare l'accelerazione hardware anziché il software per implementare le operazioni sopra indicate.
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 attivate nel file dell'intestazione di configurazione specifico dell'utente per l'accelerazione hardware.
Per una configurazione di esempio 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à AES ECB (Electronic Codebook Book) di base per la chiamata funzionale di base AES CCM.
Per utilizzare un'implementazione alternativa del modulo AES:
- Definisci la macro
MBEDTLS_AES_ALTnel file dell'intestazione di configurazione mbedTLS specifico dell'utente - Indica il percorso del file
aes_alt.hutilizzando la variabileMBEDTLS_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 PSKc in base alla specifica Thread.
Per utilizzare un'implementazione di modulo SHA256 di base alternativa:
- Definisci la macro
MBEDTLS_SHA256_ALTnel file dell'intestazione di configurazione mbedTLS specifico dell'utente - Indica il percorso del file
sha256_alt.hutilizzando la variabileMBEDTLS_CPPFLAGS
Funzioni ECC
Poiché attualmente mbedTLS supporta l'accelerazione hardware solo per parti delle funzioni ECC, anziché per l'intero modulo, puoi scegliere di implementare alcune funzioni 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. Di conseguenza, l'accelerazione hardware dovrebbe supportare almeno l'operazione in curva seierstrass a 256r1. Per un esempio, consulta Accelerazione hardware CRIPTO di SiLabs per mbedTLS.