Développer un réseau sécurisé de capteurs et de concentrateurs Bluetooth basse consommation

Par Stephen Evanczuk

Avec la contribution de Rédacteurs nord-américains de Digi-Key

Grâce à sa disponibilité généralisée sur les dispositifs mobiles, la technologie Bluetooth est idéale pour fournir aux consommateurs un accès sans fil simplifié aux produits intelligents. Pour les développeurs IoT, cependant, la création de réseaux de capteurs connectés Bluetooth présente des défis tels que l'optimisation de la durée de vie des batteries, l'optimisation des protocoles Bluetooth et la sécurisation de la connectivité entre les dispositifs.

Comme cet article le démontre, en utilisant un dispositif Bluetooth avancé et un environnement de développement associé de Cypress Semiconductor, les développeurs peuvent résoudre ces problèmes et implémenter rapidement des réseaux sécurisés de capteurs et de concentrateurs Bluetooth.

Pourquoi choisir la technologie Bluetooth ?

La prise en charge étendue de Bluetooth dans les smartphones et autres dispositifs mobiles en fait une technologie sans fil privilégiée pour connecter les consommateurs et leurs appareils électroniques personnels, par exemple les dispositifs corporels et médicaux, entre autres. Avec l'émergence de la technologie Bluetooth 5, les développeurs IoT peuvent tirer parti de ces mêmes avantages tout en répondant aux exigences croissantes en termes de portée et de débits de données plus élevés associés aux réseaux de capteurs et aux autres applications IoT.

Pour développer des conceptions pour ces applications, les développeurs peuvent se tourner vers un nombre croissant de dispositifs compatibles avec la technologie Bluetooth 5. Combinant un sous-système RF complet et un cœur de processeur, ces dispositifs permettent d'effectuer les transactions de bas niveau associées aux communications Bluetooth. Cependant, la nécessité de maintenir une basse consommation et de garantir une connectivité sécurisée dans les réseaux IoT peut représenter une autre complication dans le déploiement de la technologie Bluetooth dans les applications en question.

Solution intégrée

Le CYW20719 de Cypress Semiconductor est spécialement conçu pour répondre aux exigences croissantes des conceptions connectées par Bluetooth et alimentées par batterie pour l'IoT, les dispositifs corporels, les appareils électroniques personnels et d'autres applications basse consommation. Outre ses capacités basse consommation, sa prise en charge des fonctionnalités Bluetooth 5 avancées, notamment les sauts de fréquence adaptatifs, constitue un avantage majeur dans les environnements radio très chargés associés à ces applications.

Le dispositif intègre un sous-système radio Bluetooth basse consommation, un cœur Arm® Cortex®-M4 avec unité en virgule flottante et plusieurs blocs périphériques (Figure 1). En outre, un moteur de sécurité intégré accélère la cryptographie à clé publique et fournit des fonctionnalités de cryptographie essentielles pour garantir la sécurité des opérations Bluetooth. Enfin, une unité de gestion de l'alimentation (PMU) intégrée fournit aux développeurs un mécanisme flexible permettant de répondre aux exigences du fonctionnement ultrabasse consommation, de plus en plus nécessaire pour les dispositifs compatibles Bluetooth.

Schéma du CYW20719 de Cypress Semiconductor

Figure 1 : Le CYW20719 de Cypress Semiconductor associe un cœur Arm® Cortex®-M4, un sous-système Bluetooth complet et des services logiciels intégrés pour fournir un microcontrôleur sans fil compatible Bluetooth 5 complet, pour les conceptions basse consommation. (Source de l'image : Cypress Semiconductor)

Le sous-système radio CYW20719 comprend des trajets de signaux RF 2,5 GHz complets pour le fonctionnement en transmission (Tx) et en réception (Rx). Pour le trajet du signal Rx, le dispositif atténue les signaux hors bande, atteignant une sensibilité Rx de -95,5 dBm, tout en permettant aux développeurs d'utiliser le dispositif sans filtres hors puce supplémentaires, si nécessaire. Le trajet de signal Tx inclut un amplificateur de puissance intégré conçu pour prendre en charge des niveaux de puissance de transmission configurables compris entre -24 dBm et +4 dBm maximum. Outre les capacités de couche physique (PHY) intégrées, le dispositif inclut une couche MAC Bluetooth 5 complète sur puce. Avec ses trajets de signaux Rx et Tx optimisés, le dispositif utilise uniquement un courant Rx de 5,9 mA ou un courant Tx de 5,6 mA (à 0 dBm).

Pour réduire davantage la consommation d'énergie, le dispositif fournit plusieurs modes d'alimentation gérés par l'unité de gestion de l'alimentation (PMU) intégrée. Conçue pour alimenter des domaines de puissance RF et numériques distincts, l'unité PMU combine un régulateur abaisseur intégré, un régulateur à faible chute de tension (LDO) pour les circuits numériques et un dispositif LDO séparé pour les circuits RF (Figure 2). De plus, l'unité PMU comprend un LDO de dérivation séparé (BYPLDO) qui contourne automatiquement le régulateur abaisseur pour alimenter les LDO numériques et RF si l'alimentation VBAT source tombe en dessous de 2,1 V.

Schéma de l'unité PMU CYW20719 de Cypress

Figure 2 : L'unité PMU CYW20719 de Cypress sert à gérer des domaines d'alimentation distincts pouvant être désactivés de manière sélective dans différents modes basse consommation afin de réduire la consommation de courant dans les conceptions basse consommation. (Source de l'image : Cypress Semiconductor)

En termes de fonctionnement, l'unité PMU ajuste les domaines d'alimentation en fonction du mode d'alimentation sélectionné : mode entièrement actif, mode inactif et trois modes de veille différents. En mode veille-arrêt (SDS) présentant la plus basse consommation, l'unité PMU désactive tous les blocs du dispositif, à l'exception de l'alimentation E/S, de l'horloge temps réel et d'un oscillateur basse consommation dédié, utilisé comme source d'horloge pour certains blocs et pour l'activation.

Même en utilisant ces ressources minimales, le CYW20719 en mode SDS peut gérer une connexion avec un autre périphérique Bluetooth précédemment appairé, et ce en consommant moins de 70 µA. Dans ce mode, cependant, le dispositif ne conserve pas la mémoire et nécessite un démarrage à chaud pour restaurer l'état avant de procéder à des opérations plus complexes. Les deux autres modes de veille, à savoir la veille hors tension (PDS) et l'état de veille, gèrent des niveaux croissants d'activité du dispositif, notamment la conservation de mémoire, avec des augmentations proportionnelles de la consommation d'énergie. Malgré tout, les développeurs travaillant avec des budgets d'alimentation très limités peuvent tirer parti du mode PDS pour les annonces (environ 125 µA) et les connexions actives (environ 170 µA) par Bluetooth basse consommation. En gérant les modes d'alimentation des dispositifs, les développeurs peuvent facilement profiter d'un fonctionnement ultrabasse consommation sans compromettre les fonctionnalités.

Intégration système

Même avec ses modes de fonctionnement flexibles et ses fonctionnalités étendues, le CYW20719 nécessite peu de composants supplémentaires pour l'intégration matérielle dans une conception système. Étant donné qu'il intègre des composants essentiels sur la puce, les développeurs ont seulement besoin d'ajouter quelques résistances, des condensateurs de liaison, une inductance de 2,2 µH  comme LQH2MCN2R2M52L de Murata, et des perles de ferrite comme BLM15AG601SN1D de Murata (Figure 3). Cependant, il est judicieux de placer un filtre passe-bande entre le CYW20719 et les composants d'adaptation d'antenne pour réduire les harmoniques.

Schéma du CYW20719 de Cypress (cliquez pour agrandir l'image)

Figure 3 : Étant donné que le CYW20719 de Cypress intègre toutes les fonctionnalités essentielles, les développeurs peuvent effectuer l'intégration matérielle avec seulement quelques composants supplémentaires, notamment un filtre passe-bande recommandé pour réduire les harmoniques. (Source de la figure : Cypress Semiconductor)

Le dispositif contribue également à simplifier l'intégration logicielle grâce à sa mémoire sur puce étendue incluant 1 Mo de mémoire Flash, 512 Ko de RAM et 2 Mo de ROM. Tandis que la mémoire Flash et la RAM fournissent aux développeurs des zones de mémoire pour leurs applications, la ROM sur puce est réservée aux micrologiciels du dispositif et aux profils Bluetooth. Pour prendre en charge les correctifs du micrologiciel lorsque cela s'avère nécessaire, le dispositif fournit une RAM dédiée aux correctifs. Il s'agit d'une zone de RAM connectée via une logique de contrôle de correctif (voir la Figure 1 ci-dessus). Enfin, le dispositif fournit une zone de mémoire toujours active (AON), qui lui permet de stocker des données, même dans des modes basse consommation comme le mode SDS qui, sans cette fonctionnalité, désactiverait la mémoire volatile.

Bien que la RAM et la mémoire Flash fournies sur la puce puissent sembler limitées par rapport à d'autres dispositifs de pointe, le support logiciel étendu intégré à la ROM garantit une mémoire importante pour les applications classiques. Cypress configure la ROM sur puce avec une pile logicielle complète s'étendant de la couche d'abstraction matérielle (HAL) la plus basse jusqu'à l'interface de programmation d'applications (API) pour l'environnement WICED (Wireless Internet Connectivity for Embedded Devices) (Figure 4).

Schéma du micrologiciel ROM de 2 Mo du CYW20719 de Cypress

Figure 4 : Le micrologiciel ROM de 2 Mo du CYW20719 de Cypress fournit une pile logicielle complète comprenant un système d'exploitation en temps réel, ce qui permet de réduire la complexité et l'empreinte du code d'application du développeur. (Source de l'image : Cypress Semiconductor)

En s’appuyant sur la couche HAL, le micrologiciel ROM exécute un système d'exploitation en temps réel intégré et gère toutes les interactions avec le matériel CYW20719. En même temps, le micrologiciel ROM inclut un ensemble complet de couches de services Bluetooth, notamment celles qui prennent en charge le profil d'attributs génériques (GATT) Bluetooth et le profil d'accès génériques (GAP).

Pour les applications classiques, le code développeur s'exécute à partir de la RAM, en utilisant les API WICED pour accéder au système RTOS, aux périphériques et aux autres fonctionnalités du dispositif. Bien que les exigences en matière de RAM puissent varier de manière significative, la plupart du code d'application du CYW20719 laisse généralement beaucoup de RAM disponible pour les données ou la mémoire de travail. Par exemple, l'application hello_sensor décrite plus loin laisse environ 240 Ko de RAM disponible.

Cependant, pour les applications avec des bases de code particulièrement étendues, les développeurs peuvent tirer parti de la capacité du CYW20719 à utiliser le code d'application conçu pour une exécution sur place (XIP) à partir de la mémoire Flash intégrée. Ici, l'environnement WICED charge le code désigné par le développeur et les sections de données en lecture seule dans la mémoire Flash intégrée et place les sections restantes dans la RAM. Cette approche réduit bien entendu l'empreinte de la RAM pour une application, mais elle peut avoir un impact sur les performances. Par conséquent, les développeurs doivent faire preuve de prudence dans la désignation des sections de code XIP et s'assurer que les fonctions critiques sont placées dans la RAM.

Développement d'applications

Bien que le CYW20719 simplifie l'intégration de conception, les développeurs qui cherchent à se concentrer sur les applications Bluetooth sécurisées et basse consommation peuvent néanmoins faire face à des retards importants dans la conception matérielle et le développement d'applications. Conçu pour démontrer les applications basées sur le CYW20719, le kit d'évaluation CYW920719Q40EVB-01 de Cypress est compatible avec l'environnement logiciel WICED de Cypress et permet de fournir une conception de référence et une plateforme de développement complète pour créer des applications IoT compatibles avec Bluetooth 5.0.

Le kit d'évaluation est conçu autour d'un module porteur qui inclut le CYW20719 dans la conception de la Figure 3, avec l'ajout d'un détecteur de tension XC6119N de Torex Semiconductor connecté à la broche RST_N du CYW20719 pour effectuer une réinitialisation. Le module porteur est soudé à la carte de base du kit, qui comprend un détecteur de mouvement à 9 axes LSM9DS1TR de STMicroelectronics, une thermistance CTN série NCU de Murata, les ports GPIO du CYW20719, une connexion de débogage, des embases compatibles Arduino pour l'extension, et des commutateurs et LED comme interface utilisateur simple (Figure 5).

Schéma du kit d'évaluation CYW920719Q40EVB-01 de Cypress

Figure 5 : Le kit d'évaluation CYW920719Q40EVB-01 de Cypress associe un CYW20719 sur un module porteur avec plusieurs composants de la carte de base pouvant prendre en charge une application IoT classique. (Source de l'image : Cypress Semiconductor)

Le logiciel d'exemple de Cypress utilise le CYW20719 et d'autres composants dans le cadre d'une démonstration étendue de la connectivité Bluetooth sécurisée dans un réseau IoT représentatif comprenant plusieurs dispositifs de détection et un concentrateur central (Figure 6). Avec cette application d'exemple, les développeurs peuvent explorer différents niveaux de sécurité pour l'appairage entre un dispositif de détection et le concentrateur, et évaluer l'impact de ces différents niveaux de sécurité sur l'échange de données.

Schéma des kits CYW920719Q40EVB-01 et de l'environnement de développement WICED de Cypress

Figure 6 : Conçue pour fonctionner avec plusieurs kits CYW920719Q40EVB-01 et l'environnement de développement WICED de Cypress, l'application d'exemple de Cypress démontre la connectivité Bluetooth sécurisée dans une application IoT représentative. (Source de l'image : Cypress Semiconductor)

Pour le matériel de l'application, les développeurs utilisent un kit CYW920719Q40EVB-01 distinct configuré comme concentrateur sécurisé et des kits supplémentaires configurés en tant que capteurs individuels sur le réseau. Un PC relié à chaque kit via une connexion série fournit une console permettant de définir les paramètres, d'afficher les données, d'imprimer les messages de débogage et d'interagir avec l'application.

Bien qu'il ne soit pas inclus dans cette application d'exemple, le seul élément restant dans une application classique comme celle-ci serait une connexion à un dispositif mobile pour les fonctions de surveillance et de contrôle des applications. Ici, le PC connecté en série remplit sensiblement la même fonction.

Cypress intègre le logiciel pour cette application d'exemple dans son pack en langage C CYW20917 BLE Secure Hub pour son environnement de développement WICED. Dans ce cas, le pack inclut deux projets pour les deux rôles distincts dans l'application d'exemple. Conçu pour fonctionner avec le kit désigné comme concentrateur sécurisé, l'un des projets (secure_hub) permet au concentrateur de prendre en charge plusieurs rôles de protocole Bluetooth. Plus particulièrement, le logiciel du concentrateur est conçu pour permettre l'appairage à des niveaux de sécurité distincts avec différents kits fonctionnant en tant qu'esclaves.

Les kits configurés en tant qu'esclaves exécutent le projet de capteur (hello_sensor) conçu pour illustrer la collecte de données et la communication au niveau de sécurité établi lors de l'appairage. Chaque projet comprend plusieurs modules d'en-tête et de code nécessaires pour prendre en charge chaque rôle fonctionnel. Parmi ces fichiers, les projets secure_hub et hello_sensor incluent chacun un fichier GATT d'en-tête (gatt_db.h) et de code (gatt_db.c).

Dans le protocole Bluetooth, une table de correspondance, appelée base de données (DB) GATT, définit la nature et les capacités d'une connexion Bluetooth via un ensemble de services définis comprenant chacun un ensemble de caractéristiques prises en charge. Par exemple, la spécification Bluetooth inclut des services GATT prédéfinis, allant des capacités utilitaires comme les notifications d'alerte et les informations sur les dispositifs, aux capacités spécifiques à l'application, comme les services de pression artérielle et d'oxymètre de pouls. Jouant un rôle plus fondamental que les services GATT, le profil d'accès générique (GAP) Bluetooth d'un dispositif définit la manière dont il s'annonce pour la découverte par le réseau et la manière dont il établit les connexions une fois découvert.

L'en-tête gatt_db.h et le code gatt_db.c du projet secure_hub et du projet hello_sensor définissent les services GAP et GATT pour les kits configurés de concentrateur sécurisé et de capteur, respectivement. Pour cette application de démonstration, chaque projet définit un service GATT personnalisé en fonction de son rôle. Par exemple, l'en-tête du projet hello_sensor inclut un type C enum qui définit les descripteurs de services GATT et GAP obligatoires, et une définition GATT personnalisée pour un service de capteur (Liste 1a). À son tour, le fichier gatt_db.c de ce projet utilise ces définitions pour créer la base de données GATT requise dans le protocole Bluetooth (Liste 1b).

Copier 

typedef enum

{

HANDLE_HSENS_GATT_SERVICE = 0x1, // service handle

<e> 

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

<e> 

HANDLE_HSENS_GAP_SERVICE_CHAR_DEV_APPEARANCE, // characteristic handl

HANDLE_HSENS_GAP_SERVICE_CHAR_DEV_APPEARANCE_VAL,// char value handle

<e> 

<e> 

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

<e> 

HANDLE_HSENS_SERVICE_CHAR_BLINK, // characteristic handl

HANDLE_HSENS_SERVICE_CHAR_BLINK_VAL, // char value handle

<e> 

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)

Copier 

<e> 

/* 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

<e> 

uint8_t paired_security_level;

<e> 

static void                     temp_notificaition_timeout( uint32_t count );

<e> 

<e> 

const uint8_t hello_sensor_gatt_database[]=

{

// Declare mandatory GATT service

PRIMARY_SERVICE_UUID16( HANDLE_HSENS_GATT_SERVICE, UUID_SERVICE_GATT ),

<e> 

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

// characteristics of GAP service

PRIMARY_SERVICE_UUID16( HANDLE_HSENS_GAP_SERVICE, UUID_SERVICE_GAP ),

<e> 

// 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 ),

<e> 

// 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 ),

<e> 

// 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 ),

<e> 

<e> 

// 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 ),

<e> 

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 ),

<e> 

<e> 

// 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)

Liste 1 : Inclus dans le projet hello_sensor de l'application BLE Secure Hub de Cypress, un fichier d'en-tête définit un type enum pour différentes caractéristiques (A) utilisées par le module de code correspondant pour générer la base de données GATT requise pour les opérations Bluetooth. (Source du code : Cypress Semiconductor)

Intégré dans ces définitions, le service de détection GATT définit également si ses caractéristiques de service sous-jacentes permettent des tâches de lecture, d'écriture, de notification ou d'indication (à l'aide de la console connectée). Par exemple, la caractéristique de clignotement des LED (HANDLE_HSENS_SERVICE_CHAR_BLINK déclarée dans la Liste 1a et appliquée dans la Liste 1b) inclut les masques de bits (LEGATTDB_CHAR_PROP_READ | LEGATTDB_CHAR_PROP_WRITE dans la Liste 1b) indiquant que la caractéristique est accessible en lecture et en écriture.

Le fichier gatt_db.c du projet hello_sensor combine cependant ces définitions avec le code qui implémente un accès sécurisé à cette caractéristique. En l'occurrence, il s'agit de la capacité à faire clignoter les LED le nombre de fois indiqué par un caractère saisi dans la console par le développeur. Pour les besoins de cette application d'exemple, l'accès à cette capacité requiert que la connexion à ce kit de capteurs ait été effectuée avec l'appairage Bluetooth MITM (Man-in-the-Middle) via une clé d'accès fournie par l'utilisateur et entrée dans la console lors de l'appairage.

En général, lors d'une requête pour invoquer certaines fonctionnalités, un gestionnaire correspondant exécute les tâches spécifiques à l'application, en tenant compte à la fois des caractéristiques définies et des exigences d'accès sécurisé. Pour l'exemple de clignotement LED, lors de la requête d'exécution de la fonction de clignotement des LED, le code réel permettant d'assurer la permission et l'autorisation d'accès est assez simple.

Pour modifier la valeur de caractéristique de clignotement LED (HANDLE_HSENS_SERVICE_CHAR_BLINK_VAL), le code utilise une instruction conditionnelle qui confirme à la fois la permission d'écriture et l'autorisation d'accès (Liste 2). Pour la permission d'écriture, l'instruction conditionnelle compare la permission demandée (LEGATTDB_PERM_AUTH_WRITABLE) avec le paramètre réel de permission de clignotement LED du dispositif, LED_BLINK_CHAR_PERMISSION (défini au début de la Liste 1b). Pour l'autorisation, l'instruction conditionnelle vérifie que le niveau de sécurité associé (paired_security_level) a été créé avec l'appairage MITM (BTM_SEC_LINK_PAIRED_WITH_MITM) (Liste 2).

Copier 

/*

* 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;

<e> 

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 );

<e> 

switch ( p_data->handle )

{

<e> 

.

.

.

<e> 

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");

<e> 

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

break;

<e> 

case HANDLE_HSENS_SERVICE_CHAR_BLINK_VAL:

<e> 

if ( p_data->val_len != 1 )

{

return WICED_BT_GATT_INVALID_ATTR_LEN;

}

<e> 

<e> 

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;

}

<e> 

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;

<e> 

default:

result = WICED_BT_GATT_INVALID_HANDLE;

break;

}

<e> 

return result;

}

Liste 2 : Dans cet extrait de l'application BLE Secure Hub de Cypress, une requête pour exécuter la caractéristique de clignotement des LED doit d'abord être validée (surlignée en jaune) pour obtenir la permission et l'autorisation de sécurité. (Source du code : Cypress Semiconductor)

Cette application d'exemple, qui utilise des définitions de la base de données GATT et qui prend en charge le code approprié pour le projet de capteur et le projet de concentrateur, fournit aux développeurs les modèles de conception de base associés à trois niveaux de sécurité différents, notamment tout niveau d'appairage, l'appairage MITM décrit ici et l'appairage Bluetooth LE sécurisé. Cette dernière méthode d'appairage offre la plus haute sécurité grâce à une méthode d'authentification basée sur l'échange de clés ECDH (Elliptic Curve Diffie-Hellman). Étant donné que le moteur de sécurité intégré du CYW20719 comprend un accélérateur ECDH, les développeurs peuvent déployer cette approche sans compromettre les performances.

Conclusion

La disponibilité de microcontrôleurs sans fil intégrés compatibles Bluetooth a permis aux développeurs d'accélérer l'intégration de ces dispositifs dans leurs conceptions. Cependant, pour implémenter des réseaux Bluetooth sécurisés, les développeurs sont confrontés à de nombreux défis en matière de création de services compatibles Bluetooth et d'écriture d'applications capables d'utiliser ces dispositifs en toute sécurité.

Basés sur le microcontrôleur Bluetooth CYW20719 de Cypress, le kit d'évaluation Bluetooth CYW920719Q40EVB-01 de Cypress Semiconductor et l'environnement de développement WICED constituent une plateforme complète pour la création de ces applications. Grâce aux kits et à l'environnement WICED associés au pack BLE Secure Hub de Cypress, les développeurs peuvent évaluer rapidement les applications Bluetooth sécurisées et les étendre rapidement à des applications personnalisées, capables de tirer parti de la vitesse et de la portée supérieures du Bluetooth 5.

Avertissement : les opinions, convictions et points de vue exprimés par les divers auteurs et/ou participants au forum sur ce site Web ne reflètent pas nécessairement ceux de Digi-Key Electronics ni les politiques officielles de la société.

À propos de l'auteur

Stephen Evanczuk

Stephen Evanczuk affiche plus de 20 ans d'expérience dans la rédaction de contenu pour et sur l'industrie électronique, couvrant un large éventail de sujets, notamment le matériel, les logiciels, les systèmes et les applications, y compris l'IoT. Il a obtenu son doctorat (Ph.D.) en neurosciences sur les réseaux neuronaux et a travaillé dans l'industrie aérospatiale sur les systèmes sécurisés massivement distribués et les méthodes d'accélération par algorithmes. Actuellement, lorsqu'il n'écrit pas d'articles techniques, il travaille sur l'application de l'apprentissage approfondi pour les systèmes de reconnaissance et de recommandation.

À propos de l'éditeur

Rédacteurs nord-américains de Digi-Key