Come realizzare una rete Bluetooth a basso consumo e sicura di hub e sensori

Di Stephen Evanczuk

Contributo di Editori nordamericani di Digi-Key

Con la sua ampia disponibilità sui dispositivi mobili, Bluetooth è ideale per fornire ai consumatori un facile accesso wireless ai prodotti intelligenti. Tuttavia, per gli sviluppatori IoT, la creazione di reti di sensori Bluetooth connessi presenta sfide quali l'ottimizzazione della durata della batteria, l'ottimizzazione dei protocolli Bluetooth e la garanzia di connettività sicura tra i dispositivi.

Come dimostrerà questo articolo, l'utilizzo di un dispositivo Bluetooth avanzato e di un ambiente di sviluppo associato proposti da Cypress Semiconductor consente agli sviluppatori di risolvere rapidamente questi problemi e di implementare velocemente reti Bluetooth sicure di sensori e hub.

Perché Bluetooth?

Essendo largamente supportato dagli smartphone e da altri dispositivi mobili, Bluetooth è diventata una delle tecnologie wireless preferite per collegare i consumatori ai propri dispositivi elettronici personali, ad esempio quelli indossabili o medicali. Grazie all'affermazione di Bluetooth 5, gli sviluppatori IoT sono in grado di sfruttare questi stessi vantaggi e contemporaneamente di rispondere alle crescenti esigenze in fatto di lunghezza del raggio e di velocità dei dati poste dalle reti di sensori e da altre applicazioni IoT.

Per realizzare progetti per queste applicazioni, gli sviluppatori possono fare affidamento su una gamma crescente di dispositivi abilitati Bluetooth 5. L'associazione tra sottosistemi RF completi e core di un processore consente a questi dispositivi di eseguire le transazioni di basso livello associate alle comunicazioni Bluetooth. La necessità di mantenere il consumo di energia a livelli bassi e di garantire la sicurezza della connettività nelle reti IoT può tuttavia rappresentare un'ulteriore complicazione per l'utilizzo di Bluetooth in queste applicazioni.

Soluzione integrata

CYW20719 di Cypress Semiconductor è stato progettato espressamente per rispondere alla domanda crescente di progetti per la IoT con collegamento Bluetooth alimentati a batteria, di dispositivi elettronici personali e indossabili e di altre applicazioni a basso consumo. I suoi bassi consumi, insieme alla capacità di supportare funzionalità Bluetooth 5 avanzate, tra cui il salto di frequenza adattiva, rappresentano un vantaggio considerevole negli ambienti radio affollati associati a queste applicazioni.

Il dispositivo incorpora un sottosistema radio Bluetooth a basso consumo, un core Arm® Cortex®-M4 con unità a virgola mobile (FPU) e numerosi blocchi di periferiche (Figura 1). Inoltre, un motore di sicurezza su chip fornisce accelerazione alla crittografia a chiave pubblica e funzionalità crittografiche di importanza fondamentale per garantire la sicurezza delle operazioni Bluetooth. Da ultimo, una unità di gestione di potenza (PMU) su chip offre agli sviluppatori un meccanismo flessibile in grado di rispondere ai sempre crescenti requisiti di funzionamento a bassissima potenza associati ai dispositivi abilitati Bluetooth.

Schema del CYW20719 di Cypress Semiconductor

Figura 1: CYW20719 di Cypress Semiconductor associa un Arm® Cortex®-M4, un sottosistema Bluetooth completo e servizi software integrati per ottenere un'unità MCU wireless abilitata al Bluetooth 5 adatta a progetti a bassa potenza. (Fonte dell'immagine: Cypress Semiconductor)

Il sottosistema radio CYW20719 comprende percorsi del segnale RF completi a 2,5 GHz per le operazioni di trasmissione (Tx) e di ricezione (Rx). Relativamente al segnale del percorso Rx, il dispositivo attenua i segnali fuori banda e raggiunge una sensibilità di -95,5 dBm Rx consentendo al contempo agli sviluppatori di usare il dispositivo senza bisogno di ulteriori filtri non su chip quando necessario. Il percorso del segnale Tx include un amplificatore di potenza (PA) integrato progettato per supportare livelli di potenza di trasmissione configurabili variabili tra -24 dBm fino a un massimo di +4 dBm. Oltre a uno strato fisico (PHY) integrato, il dispositivo include uno strato MAC di controllo dell'accesso al mezzo completo su chip Bluetooth 5. Grazie a percorsi di segnale ottimizzati sia Rx sia Tx, il dispositivo utilizza solo 5,9°mA di corrente Rx o 5,6°mA (a 0 dBm) di corrente Tx.

Per ridurre ulteriormente il consumo energetico, il dispositivo offre diversi modi di alimentazione gestiti dall'unità PMU. Pensata per alimentare domini separati di alimentazione RF e digitale, l'unità PMU abbina un regolatore buck integrato, un regolatore a bassa caduta di tensione (LDO) per i circuiti digitali e un LDO separato per i circuiti RF (Figura 2). Inoltre, l'unità PMU include un LDO separato con bypass (BYPLDO) che bypassa automaticamente il regolatore buck per alimentare gli LDO digitali e RF qualora l'alimentazione VBAT sorgente scenda al di sotto dei 2,1 V.

Schema dell'unità PMU CYW20719 di Cypress Semiconductor

Figura 2: La PMU Cypress CYW20719 gestisce due domini separati di alimentazione che possono essere disattivati selettivamente in diverse modalità di bassa potenza per ridurre il consumo di corrente nei progetti a bassa potenza. (Fonte dell'immagine: Cypress Semiconductor)

Quando è in funzione, l'unità PMU regola i domini di alimentazione in relazione alla modalità di alimentazione selezionata, tra cui la modalità completamente attiva, la modalità di inattività e tre diverse modalità di sospensione. Nella modalità di sospensione più profonda (SDS), l'unità PMU spegne tutti i blocchi di dispositivi tranne l'alimentazione I/O, il clock in tempo reale (RTC) e un oscillatore a bassa potenza (LPO) dedicato, che funge da generatore di segnali di clock per alcuni blocchi e la temporizzazione della riattivazione.

Anche disponendo di queste risorse minime, in modalità SDS CYW20719 è in grado di mantenere un collegamento con un dispositivo Bluetooth precedentemente accoppiato, consumando meno di 70 microampere (μA) per il processo. In questa modalità, tuttavia, il dispositivo non conserva la memoria e necessita di un avvio a caldo per ripristinare lo stato prima di poter passare a operazioni più complesse. Nelle altre due modalità di sospensione, power-down sleep (PDS) e sleep, vengono mantenuti livelli crescenti di attività del dispositivo, inclusa la memoria, con aumenti incrementali e commisurati di consumo energetico. Ma anche così, gli sviluppatori che hanno a disposizione potenze molto limitate possono sfruttare la modalità PDS per l'advertising Bluetooth a basso consumo (circa 125 μA) e le connessioni attive (circa 170 μA). Grazie alla gestione delle modalità di alimentazione dei dispositivi, gli sviluppatori sono in grado di ottenere un funzionamento a bassissima potenza senza compromettere la funzionalità.

L'integrazione nel sistema

Nonostante le modalità di funzionamento flessibili e le funzionalità estese, CYW20719 necessita di qualche componente aggiuntivo per realizzare l'integrazione hardware nel progetto di un sistema. Incorporando componenti critici sul chip, gli sviluppatori devono solo aggiungere qualche resistore e condensatore di accoppiamento, un induttore da 2,2 µH come LQH2MCN2R2M52L di Murata e perline di ferrite come le BLM15AG601SN1D di Murata (Figura 3). È tuttavia consigliabile posizionare un filtro passa banda tra CYW20719 e i componenti di accoppiamento dell'antenna per ridurre le armoniche.

Schema di CYW20719 di Cypress (fare clic per ingrandire)

Figura 3: Visto che CYW20719 di Cypress incorpora tutte le funzionalità fondamentali, per realizzare l'integrazione hardware agli sviluppatori servono pochi componenti aggiuntivi, tra cui un filtro passa banda consigliato per ridurre le armoniche. (Immagine per gentile concessione di Cypress Semiconductor)

Il dispositivo contribuisce a semplificare anche l'integrazione software con la sua grande memoria su chip, che comprende 1 megabyte di flash, 512 kilobyte di RAM, e 2 megabyte di ROM. Flash e RAM offrono agli sviluppatori aree di memoria per le loro applicazioni mentre la ROM su chip è riservata al firmware del dispositivo e ai profili Bluetooth. Le patch del firmware che potrebbero essere necessarie vengono gestite dalla RAM per le patch, una zona della RAM collegata tramite la logica di controllo della patch (Figura 1 sopra). Da ultimo, il dispositivo dispone di un'area di memoria sempre on (AON) che consente al dispositivo di immagazzinare dati anche in modalità di basso consumo come la SDS, che altrimenti disattiverebbero la memoria volatile.

Sebbene la RAM e la memoria flash fornita su chip possano sembrare limitate se paragonate ad altri dispositivi allo stato dell'arte, l'ampio supporto software integrato nella ROM garantisce alle applicazioni tipiche memoria in abbondanza. Cypress configura la ROM su chip con uno stack software completo, che va dal livello di astrazione hardware (HAL) più basso fino all'interfaccia di programmazione applicativa (API) per l'ambiente WICED (Wireless Internet Connectivity for Embedded Devices) (Figura 4).

Immagine dei 2 megabyte di firmware su ROM di CYW20719 di Cypress

Figura 4: I 2 megabyte di firmware su ROM di CYW20719 di Cypress offrono uno stack software completo, che include un sistema operativo in tempo reale e riducono la complessità e l'ingombro del codice applicativo dello sviluppatore. (Fonte dell'immagine: Cypress Semiconductor)

Partendo dallo strato HAL, il firmware su ROM esegue un sistema operativo in tempo reale incorporato e gestisce tutte le interazioni con l'hardware di CYW20719. Allo stesso tempo, il firmware su ROM comprende un corredo completo di strati di servizio Bluetooth, compresi quelli che supportano i profili essenziali GATT (Generic Attribute Profile) e GAP (Generic Access Profile).

Per le applicazioni tipiche, il codice degli sviluppatori gira sulla RAM, sfruttando le API WICED per accedere agli RTOS, alle periferiche e ad altre funzionalità del dispositivo. Sebbene i requisiti RAM possano variare in modo significativo, la maggior parte del codice applicativo per CYW20719 lascia in genere RAM libera in abbondanza per i dati o la memoria di lavoro. Ad esempio, l'applicazione hello_sensor descritta di seguito lascia circa 240 kilobyte di RAM libera.

Per le applicazioni con basi di codice particolarmente grandi, tuttavia, gli sviluppatori possono sfruttare la capacità di CYW20719 di lavorare con codice applicativo progettato per l'esecuzione diretta (XIP) dalla flash su chip. Qui, l'ambiente WICED carica il codice designato dallo sviluppatore e sezioni di dati in sola lettura sulla flash su chip e alloca le sezioni rimanenti nella RAM. È un approccio che riduce ovviamente l'ingombro di un'applicazione nella RAM ma che può influire sulle prestazioni. Perciò gli sviluppatori devono essere cauti nella designazione di sezioni di codice XIP e assicurarsi che le funzioni tempo critiche vengano allocate nella RAM.

Sviluppo di applicazioni

Sebbene CYW20719 semplifichi l'integrazione della progettazione, gli sviluppatori focalizzati su applicazioni Bluetooth a basso consumo sicure si possono comunque trovare a fronteggiare ritardi considerevoli nel portare a termine il progetto hardware e lo sviluppo delle applicazioni. Nato per dimostrare le applicazioni basate su CYW20719, il kit di valutazione CYW920719Q40EVB-01 di Cypress fornisce, insieme all'ambiente software WICED di Cypress, un progetto di riferimento e una piattaforma di sviluppo completa per la creazione di applicazioni IoT con conformità Bluetooth 5.0.

Il kit di valutazione è costruito intorno a un modulo portante che include CYW20719 come da progetto della figura 3, con l'aggiunta di un rivelatore di tensione di Torex Semiconductor, XC6119N, collegato al pin RST_N di CYW20719 per il ripristino. Il modulo portante è saldato alla scheda base del kit, che comprende un sensore di movimento a 9 assi LSM9DS1TR di STMicroelectronics, un termistore NTC serie NCU di Murata, le porte GPIO di CYW20719, una connessione di debug, basette compatibili con Arduino per l'espansione e interruttori e LED che fungono da semplice interfaccia utente (Figura 5).

Schema del kit di valutazione CYW920719Q40EVB-01 di Cypress

Figura 5: Il kit di valutazione CYW920719Q40EVB-01 di Cypress abbina un CYW20719 su modulo portante con più componenti di schede base in grado di supportare una tipica applicazione IoT. (Fonte dell'immagine: Cypress Semiconductor)

Il software esemplificativo di Cypress utilizza CYW20719 e altri componenti nell'ambito di una dimostrazione approfondita della sicurezza della connettività Bluetooth in una rete IoT rappresentativa che include diversi sensori e un hub centrale (Figura 6). Grazie a questa applicazione esemplificativa, gli sviluppatori possono esplorare diversi livelli di sicurezza nell'accoppiamento tra un sensore e un hub e valutare l'impatto dei diversi livelli di sicurezza sullo scambio di dati.

Schema dei kit CYW920719Q40EVB-01 e dell'ambiente di sviluppo WICED di Cypress

Figura 6: Progettata per utilizzare numerosi kit CYW920719Q40EVB-01 e l'ambiente di sviluppo WICED di Cypress, un'applicazione esemplificativa Cypress dimostra la sicurezza della connettività Bluetooth in un'applicazione IoT rappresentativa. (Fonte dell'immagine: Cypress Semiconductor)

Per l'hardware dell'applicazione, gli sviluppatori impiegano un kit CYW920719Q40EVB-01 distinto configurato come hub sicuro e kit aggiuntivi configurati come sensori individuali nella rete. Un PC collegato in serie a ciascun kit fornisce una console per l'impostazione dei parametri, la visualizzazione dei dati, la stampa dei messaggi di debug e per altre interazioni con l'applicazione esemplificativa.

Sebbene non lo includa, l'unico elemento rimanente in un'applicazione tipica come questa sarebbe il collegamento a un dispositivo mobile per il monitoraggio e le funzioni di controllo dell'applicazione. In questo caso, Il PC collegato in serie svolge più o meno la stessa funzione.

Cypress allega il software di questa applicazione esemplificativa nel [pacchetto CYW20917 BLE Secure Hub in linguaggio C per il suo ambiente di sviluppo WICED. Il pacchetto in oggetto comprende due progetti per i due ruoli separati nell'applicazione esemplificativa. Un progetto, secure_hub, pensato per girare sul kit designato come hub sicuro, consente all'hub di supportare più ruoli del protocollo Bluetooth. In dettaglio, il software dell'hub è studiato per abilitare l'accoppiamento a livelli di sicurezza separati con svariati kit che fungono da slave.

Sui kit configurati come slave gira il progetto per i sensori (hello_sensor) che ha il compito di fornire una dimostrazione della raccolta di dati e della comunicazione al livello di sicurezza stabilito nel momento dell'accoppiamento. Ogni progetto comprende diversi moduli di codice e di header che supportano ogni ruolo funzionale. Tra questi file, sia il progetto secure_hub sia hello_sensor includono un header GATT (Generic Attribute Profile) (gatt_db.h) e un file di codice (gatt_db.c) .

Nel protocollo Bluetooth, una tabella di consultazione chiamata database GATT (DB) definisce la natura e le capacità di una connessione Bluetooth in base a un insieme di servizi definiti, ciascuno dei quali comprende a sua volta un insieme di caratteristiche supportate. Ad esempio, le specifiche Bluetooth includono servizi GATT predefiniti che vanno dai servizi per le utenze, come avvisi e informazioni sui dispositivi, ad abilità in un ambito specifico come i servizi relativi alla pressione sanguigna o ai pulsossimetri. Alla luce del ruolo più basilare che svolge rispetto ai servizi GATT, il profilo di accesso generico al Bluetooth (GAP) per un dispositivo stabilisce come si rende rilevabile da parte della rete (advertising) e come stabilisce connessioni dopo che ciò è avvenuto.

Il file header gatt_db.h e il file di codice gatt_db.c nei progetti secure_hub e hello_sensor definiscono rispettivamente i servizi GAP e GATT per l'hub sicuro e per i kit configurati per i sensori. Per questa applicazione di dimostrazione, ogni progetto definisce un servizio GATT personalizzato in relazione al suo ruolo. Ad esempio, il file header del progetto hello_sensor comprende un tipo di enumerazione enum in C che fornisce una definizione degli handle obbligatori per i servizi GATT e GAP nonché una definizione personalizzata GATT per il servizio di un sensore (Listato 1a). Dal canto suo, il file gatt_db.c di quel progetto utilizza tali definizione per creare il DB GATT richiesto nel protocollo Bluetooth (Listato 1b).

Copy

typedef enum

{

    HANDLE_HSENS_GATT_SERVICE = 0x1, // service handle

 

    HANDLE_HSENS_GAP_SERVICE = 0x14, // service handle

        HANDLE_HSENS_GAP_SERVICE_CHAR_DEV_NAME, // characteristic handl

        HANDLE_HSENS_GAP_SERVICE_CHAR_DEV_NAME_VAL, // char value handle

 

        HANDLE_HSENS_GAP_SERVICE_CHAR_DEV_APPEARANCE, // characteristic handl

        HANDLE_HSENS_GAP_SERVICE_CHAR_DEV_APPEARANCE_VAL,// char value handle

 

 

    HANDLE_HSENS_SERVICE = 0x28,

        HANDLE_HSENS_SERVICE_CHAR_UART, // characteristic handl

        HANDLE_HSENS_SERVICE_CHAR_UART_VAL, // char value handle

        HANDLE_HSENS_SERVICE_CHAR_CFG_DESC, // charconfig desc handl

 

        HANDLE_HSENS_SERVICE_CHAR_BLINK, // characteristic handl

           HANDLE_HSENS_SERVICE_CHAR_BLINK_VAL, // char value handle

 

           HANDLE_HSENS_SERVICE_CHAR_TEMP, // characteristic handl

                  HANDLE_HSENS_SERVICE_CHAR_TEMP_VAL, // char value handle

                  HANDLE_HSENS_SERVICE_CHAR_TEMP_CFG_DESC, // charconfig desc handl

(A)

Copy

 

/* Permissions for custom characteristics */

#define LED_BLINK_CHAR_PERMISSION LEGATTDB_PERM_WRITE_REQ | LEGATTDB_PERM_AUTH_WRITABLE | LEGATTDB_PERM_READABLE

#define TEMP_CHAR_PERMISSION         LEGATTDB_PERM_READABLE

#define UART_CHAR_PERMISSION         LEGATTDB_PERM_READABLE

 

uint8_t paired_security_level;

 

static void                     temp_notificaition_timeout( uint32_t count );

 

 

const uint8_t hello_sensor_gatt_database[]=

{

    // Declare mandatory GATT service

    PRIMARY_SERVICE_UUID16( HANDLE_HSENS_GATT_SERVICE, UUID_SERVICE_GATT ),

 

    // Declare mandatory GAP service. Device Name and Appearance are mandatory

    // characteristics of GAP service

    PRIMARY_SERVICE_UUID16( HANDLE_HSENS_GAP_SERVICE, UUID_SERVICE_GAP ),

 

        // Declare mandatory GAP service characteristic: Dev Name

        CHARACTERISTIC_UUID16( HANDLE_HSENS_GAP_SERVICE_CHAR_DEV_NAME, HANDLE_HSENS_GAP_SERVICE_CHAR_DEV_NAME_VAL,

            UUID_CHARACTERISTIC_DEVICE_NAME, LEGATTDB_CHAR_PROP_READ, LEGATTDB_PERM_READABLE ),

 

        // Declare mandatory GAP service characteristic: Appearance

        CHARACTERISTIC_UUID16( HANDLE_HSENS_GAP_SERVICE_CHAR_DEV_APPEARANCE, HANDLE_HSENS_GAP_SERVICE_CHAR_DEV_APPEARANCE_VAL,

            UUID_CHARACTERISTIC_APPEARANCE, LEGATTDB_CHAR_PROP_READ, LEGATTDB_PERM_READABLE ),

 

    // Declare proprietary Hello Service with 128 byte UUID

    PRIMARY_SERVICE_UUID128( HANDLE_HSENS_SERVICE, UUID_HELLO_SERVICE ),

        // Declare characteristic used to notify/indicate change

        CHARACTERISTIC_UUID128( HANDLE_HSENS_SERVICE_CHAR_UART, HANDLE_HSENS_SERVICE_CHAR_UART_VAL,

            UUID_HELLO_CHARACTERISTIC_NOTIFY, LEGATTDB_CHAR_PROP_READ | LEGATTDB_CHAR_PROP_NOTIFY | LEGATTDB_CHAR_PROP_INDICATE, UART_CHAR_PERMISSION ),

 

 

            // Declare client characteristic configuration descriptor

            // Value of the descriptor can be modified by the client

            // Value modified shall be retained during connection and across connection

            // for bonded devices.  Setting value to 1 tells this application to send notification

            // when value of the characteristic changes.  Value 2 is to allow indications.

                CHAR_DESCRIPTOR_UUID16_WRITABLE( HANDLE_HSENS_SERVICE_CHAR_CFG_DESC, UUID_DESCRIPTOR_CLIENT_CHARACTERISTIC_CONFIGURATION,

                     LEGATTDB_PERM_READABLE | LEGATTDB_PERM_WRITE_REQ ),

        // Declare characteristic Hello Configuration

        // The configuration consists of 1 bytes which indicates how many times to

       // blink the LED when user pushes the button.

        CHARACTERISTIC_UUID128_WRITABLE( HANDLE_HSENS_SERVICE_CHAR_BLINK, HANDLE_HSENS_SERVICE_CHAR_BLINK_VAL,

                                        UUID_HELLO_CHARACTERISTIC_LED_BLINK,

                                        LEGATTDB_CHAR_PROP_READ | LEGATTDB_CHAR_PROP_WRITE,

                                        LED_BLINK_CHAR_PERMISSION ),

 

        CHARACTERISTIC_UUID128( HANDLE_HSENS_SERVICE_CHAR_TEMP, HANDLE_HSENS_SERVICE_CHAR_TEMP_VAL,

            UUID_HELLO_CHARACTERISTIC_TEMP, LEGATTDB_CHAR_PROP_READ | LEGATTDB_CHAR_PROP_NOTIFY | LEGATTDB_CHAR_PROP_INDICATE, TEMP_CHAR_PERMISSION ),

 

 

// Declare client characteristic configuration descriptor

// Value of the descriptor can be modified by the client

// Value modified shall be retained during connection and across connection

// for bonded devices. Setting value to 1 tells this application to send notification

// when value of the characteristic changes. Value 2 is to allow indications.

                CHAR_DESCRIPTOR_UUID16_WRITABLE( HANDLE_HSENS_SERVICE_CHAR_TEMP_CFG_DESC, UUID_DESCRIPTOR_CLIENT_CHARACTERISTIC_CONFIGURATION,

LEGATTDB_PERM_READABLE | LEGATTDB_PERM_WRITE_REQ ),

(B)

Listato 1: Un file header incluso nel progetto hello_sensor per Cypress BLE Secure Hub definisce un tipo di enumerazione per diverse caratteristiche (A) che vengono utilizzate dal corrispondente modulo di codice per costruire il DB GATT necessario al funzionamento del Bluetooth. (Codice sorgente per gentile concessione di Cypress Semiconductor)

Il servizio GATT per i sensori, incorporato in queste definizioni, stabilisce inoltre se le caratteristiche sottostanti consentono la lettura, la scrittura, la notifica o l'indicazione (tramite la console collegata). La caratteristica per il lampeggiamento del LED (HANDLE_HSENS_SERVICE_CHAR_BLINK dichiarata nel Listato 1a e applicata nel Listato 1b), ad esempio, comprende maschere di bit (LEGATTDB_CHAR_PROP_READ | LEGATTDB_CHAR_PROP_WRITE nel Listato 1b) indicanti che essa è sia di lettura che di scrittura.

Il file gatt_db.c del progetto hello_sensor, tuttavia, combina queste definizioni con codice che implementa l'accesso sicuro a quella caratteristica, vale a dire la possibilità del LED di lampeggiare il numero di volte indicato dal carattere digitato nella console dallo sviluppatore. Ai fini di questa applicazione esemplificativa, l'accesso a tale capacità richiede che la connessione stabilita con quel kit sensori sia stata effettuata con l'accoppiamento man-in-the-middle (MITM) Bluetooth tramite una chiave di accesso fornita dall'utente e immessa dalla console durante l'accoppiamento.

In generale, quando viene fatta una richiesta per richiamare qualche funzionalità, un gestore corrispondente esegue le attività specifiche dell'applicazione, tenendo conto sia delle caratteristiche definite sia dei requisiti per l'accesso sicuro. Nel caso dell'esempio relativo al lampeggiamento del LED, quando viene fatta una richiesta di esecuzione della funzione di lampeggiamento del LED il codice effettivo che garantisce il permesso e autorizza l'accesso è abbastanza semplice.

Per modificare il valore della caratteristica relativa al lampeggiamento del LED (HANDLE_HSENS_SERVICE_CHAR_BLINK_VAL), il codice usa una dichiarazione condizionale che conferma sia i permessi di scrittura sia l'autorizzazione all'accesso (Listato 2). Relativamente ai permessi di scrittura, la dichiarazione condizionale paragona l'autorizzazione richiesta (LEGATTDB_PERM_AUTH_WRITABLE) con l'effettiva impostazione per il lampeggiamento del dispositivo a LED LED_BLINK_CHAR_PERMISSION (definita in cima al Listato 1b). Per l'autorizzazione, l'istruzione condizionale controlla che il livello di sicurezza corrente accoppiato (paired_security_level) sia stato creato con l'accoppiamento MITM (BTM_SEC_LINK_PAIRED_WITH_MITM) (Listato 2).

Copy

/*

 * Process write request or write command from peer device

*/

wiced_bt_gatt_status_t hello_sensor_gatts_req_write_handler( uint16_t conn_id, wiced_bt_gatt_write_t * p_data )

{

    wiced_bt_gatt_status_t result    = WICED_BT_GATT_SUCCESS;

    uint8_t                *p_attr   = p_data->p_val;

 

    uint8_t sec_flag, key_size;

    WICED_BT_TRACE("write_handler: conn_id:%d hdl:0x%x prep:%d offset:%d len:%d\r\n ", conn_id, p_data->handle, p_data->is_prep, p_data->offset, p_data->val_len );

 

    switch ( p_data->handle )

{

 

.

.

.

 

    case HANDLE_HSENS_SERVICE_CHAR_TEMP_CFG_DESC:

           if ( p_data->val_len != 2 )

{

               return WICED_BT_GATT_INVALID_ATTR_LEN;

}

           WICED_BT_TRACE( "Temp Notif Enabled\r\n");

 

           hello_sensor_hostinfo.temp_characteristic_client_configuration = p_attr[0] | ( p_attr[1] << 8 );

break;

 

    case HANDLE_HSENS_SERVICE_CHAR_BLINK_VAL:

 

if ( p_data->val_len != 1 )

{

return WICED_BT_GATT_INVALID_ATTR_LEN;

}

 

 

        if ((!(paired_security_level & BTM_SEC_LINK_PAIRED_WITH_MITM))&& (LED_BLINK_CHAR_PERMISSION & LEGATTDB_PERM_AUTH_WRITABLE))

{

            WICED_BT_TRACE("Write Failed: Insufficient Authentication\r\n");

            return WICED_BT_GATT_INSUF_AUTHENTICATION;

}

 

        hello_sensor_hostinfo.number_of_blinks = p_attr[0];

        if ( hello_sensor_hostinfo.number_of_blinks != 0 )

{

            WICED_BT_TRACE( "hello_sensor_write_handler:num blinks: %d\r\n", hello_sensor_hostinfo.number_of_blinks );

wiced_bt_app_hal_led_blink(250, 250, hello_sensor_hostinfo.number_of_blinks );

}

break;

 

default:

        result = WICED_BT_GATT_INVALID_HANDLE;

break;

}

 

    return result;

}

Listato 2: In questo snippet preso dall'applicazione Cypress BLE Secure Hub, una richiesta di eseguire la caratteristica di lampeggiamento del LED necessita prima di superare un controllo (evidenziato) dei permessi e delle autorizzazioni di sicurezza. (Codice sorgente per gentile concessione di Cypress Semiconductor)

Grazie all'utilizzo delle definizioni del DB GATT e di codice adeguato al progetto dei sensori e dell'hub, questa applicazione esemplificativa fornisce agli sviluppatori i modelli di progettazione fondamentali associati a tre diversi livelli di sicurezza, incluso qualsiasi livello di accoppiamento, accoppiamento MITM descritto qui e Bluetooth LE Secure. Quest'ultimo metodo di accoppiamento offre la massima sicurezza poiché utilizza un metodo di autenticazione basato sullo scambio di chiavi Elliptic Curve Diffie-Hellman. Visto che il motore di sicurezza integrato di CYW20719 include un acceleratore ECDH, gli sviluppatori possono applicare questo approccio senza compromettere le prestazioni.

Conclusione

La disponibilità di MCU wireless integrate abilitate Bluetooth ha contribuito a rendere più veloce l'integrazione di questi dispositivi nei progetti degli sviluppatori. L'implementazione di reti Bluetooth sicure, tuttavia, pone agli sviluppatori numerose sfide che riguardano la creazione di servizi compatibili con il Bluetooth e la scrittura di applicazioni in grado di utilizzare in sicurezza tali dispositivi.

Il kit di valutazione Bluetooth CYW920719Q40EVB-01 e l'ambiente di sviluppo WICED di Cypress Semiconductor, basati sull'unità MCU Bluetooth CYW20719 di Cypress, rappresentano una piattaforma completa per la realizzazione di tali applicazioni. L'utilizzo dei kit e dell'ambiente WICED associati al pacchetto Cypress BLE Secure Hub consente agli sviluppatori di valutare velocemente la sicurezza delle applicazioni Bluetooth e di trasformarle rapidamente in applicazioni personalizzate in grado di sfruttare la maggiore velocità e raggio del Bluetooth 5.

Esonero della responsabilità: le opinioni, le convinzioni e i punti di vista espressi dai vari autori e/o dai partecipanti al forum su questo sito Web non riflettono necessariamente le opinioni, le convinzioni e i punti di vista di Digi-Key Electronics o le sue politiche.

Informazioni su questo autore

Stephen Evanczuk

Stephen Evanczuk ha più di 20 anni di esperienza come autore sull'industria elettronica e ha scritto su una vasta gamma di argomenti tra cui hardware, software, sistemi e applicazioni, incluso l'IoT. Ha ricevuto un Ph.D. in neuroscienze sulle reti neuronali e ha lavorato nel settore aerospaziale su sistemi di sicurezza ampiamente distribuiti e sui metodi di accelerazione algoritmica. Attualmente, quando non scrive articoli su tecnologia e ingegneria, lavora su applicazioni di deep learning per i sistemi di riconoscimento e di raccomandazione.

Informazioni su questo editore

Editori nordamericani di Digi-Key