Aufbau eines sicheren, stromsparenden Bluetooth-Hubs und Sensornetzwerks

Von Stephen Evanczuk

Zur Verfügung gestellt von Nordamerikanische Fachredakteure von Digi-Key

Mit seiner weit verbreiteten Verfügbarkeit auf mobilen Geräten ist Bluetooth gut dafür geeignet, Verbrauchern einen einfachen drahtlosen Zugang zu intelligenten Produkten zu ermöglichen. Für IoT-Entwickler bedeutet der Aufbau von mit Bluetooth verbundenen Sensornetzwerken jedoch Herausforderungen wie die Maximierung der Akkulaufzeit, die Optimierung von Bluetooth-Protokollen und die Gewährleistung einer sicheren Netzwerkverbindung zwischen den Geräten.

Dieser Artikel wird zeigen, dass Entwickler mit einer fortschrittlichen Bluetooth-Komponente samt zugehöriger Entwicklungsumgebung von Cypress Semiconductor diese Probleme im Handumdrehen meistern und sichere Hubs und Sensornetzwerke mit Bluetooth-Konnektivität bereitstellen können.

Warum Bluetooth?

Aufgrund der umfassenden Unterstützung durch Smartphones und anderen Mobilgeräten hat sich Bluetooth zu einer bevorzugten drahtlosen Technologie entwickelt, um Verbraucher mit ihren personenbezogenen, elektronischen Geräten wie etwa Wearables und medizinischen Geräten zu verbinden. Mit der Einführung von Bluetooth 5 können IoT-Entwickler neben der Nutzung all dieser Vorteile die höheren Reichweiten und Datenraten im Zusammenhang mit Sensornetzwerken und anderen IoT-Anwendungen bereitstellen, die immer häufiger gefordert werden.

Um Designs für diese Anwendungen zu bauen, steht den Entwicklern eine wachsende Auswahl an Bluetooth-5-fähigen Komponenten zur Verfügung. Diese Komponenten mit einem vollständigen HF-Subsystem und Prozessorkern sind in der Lage, die Low-Level-Transaktionen im Zusammenhang mit der Bluetooth-Kommunikation auszuführen. Dennoch kann die Erfordernis, den Stromverbrauch niedrig zu halten und sichere Konnektivität in IoT-Netzwerken zu gewährleisten, für weitere Komplikationen bei der Bereitstellung von Bluetooth in diesen Anwendungen sorgen.

Integrierte Lösung

Die Komponente CYW20719 von Cypress Semiconductor wurde speziell für die steigende Nachfrage nach batteriebetriebenen Bluetooth-Designs für das IoT, Wearables, personenbezogene Elektronik und andere Anwendungen mit geringer Leistungsaufnahme entwickelt. Neben ihren energiesparenden Funktionen stellt die Unterstützung fortschrittlicher Bluetooth-5-Funktionen wie beispielsweise des adaptiven Frequenzsprungverfahrens einen bedeutenden Vorteil bei den stark ausgelasteten Funkumgebungen im Zusammenhang mit diesen Anwendungen dar.

Die Komponente verfügt über ein Bluetooth-Funksubsystem mit geringer Leistungsaufnahme, eine ARM®-Cortex®-M4-CPU mit Gleitkommaeinheit (FPU, Floating Point Unit) sowie mehrere Peripherieblöcke (Abbildung 1). Des Weiteren beschleunigt eine im Chip integrierte Sicherheits-Engine die Verschlüsselung mit öffentlichen Schlüsseln und bietet Verschlüsselungsfunktionen, die für sichere Bluetooth-Vorgänge unerlässlich sind. Eine ebenfalls im Chip integrierte Energieverwaltung (PMU, Power Management Unit) schließlich sorgt dafür, dass die Entwickler den Anforderungen hinsichtlich eines extrem energieeffizienten Betriebs gerecht werden können, der für Bluetooth-fähige Komponenten in zunehmendem Maße gefordert wird.

Blockdiagramm der CYW20719 von Cypress Semiconductor

Abbildung 1: Der CYW20719 von Cypress Semiconductor vereint eine Arm®-Cortex®-M4-CPU, ein vollständiges Bluetooth-Subsystem und integrierte Softwaredienste und stellt somit eine komplette, Bluetooth-5-fähige Wireless-MCU für energieeffizente Designs dar. (Bildquelle: Cypress Semiconductor)

Das Funksubsystem des CYW20719 umfasst vollständige 2,5-GHz-HF-Signalpfade zum Senden (Tx) und Empfangen (Rx). Für den Rx-Signalpfad dämpft die Komponente bandexterne Signale. Auf diese Weise erreicht sie eine Rx-Empfindlichkeit von -95,5 dBm und ermöglicht den Entwicklern gegebenenfalls die Verwendung der Komponente ohne zusätzliche Filter. Im Tx-Signalpfad befindet sich ein integrierter Leistungsverstärker (PA, Power Amplifier), der für konfigurierbare Sendeleistungspegel von -24 dBm bis zu einem Maximum von +4 dBm entwickelt wurde. Neben dem integrierten physischen Layer (PHY) verfügt die Komponente auf dem Chip über einen Bluetooth-5-MAC-Layer (Medium-Access-Control). Dank der optimierten Rx- und Tx-Signalpfade nimmt die Komponente lediglich 5,9 mA Rx-Strom bzw. 5,6 mA (bei 0 dBm) Tx-Strom auf.

Um den Stromverbrauch weiter zu minimieren, bietet die Komponente mehrere Stromverbrauchsmodi, die von der integrierten PMU verwaltet werden. Die PMU, die zur Versorgung separater HF- und digitaler Stromversorgungskreise entwickelt wurde, umfasst einen integrierten Abwärtsregler, einen Regler mit geringem Spannungseinbruch (LDO-Regler) für digitale Schaltungen und einen separaten LDO-Regler für HF-Schaltungen (Abbildung 2). Zusätzlich bietet die PMU einen separaten Bypass-LDO-Regler (BYPLDO), der automatisch den Abwärtsregler umgeht und die LDO-Regler für die digitalen und HF-Schaltungen versorgt, falls die Versorgungsspannung VBAT unter 2,1 Volt fällt.

Blockdiagramm der PMU der Cypress CYW20719

Abbildung 2: Die PMU der Cypress CYW20719 verwaltet separate Stromversorgungskreise, die in verschiedenen Energiesparmodi selektiv deaktiviert werden können, um den Stromverbrauch in energiesparenden Designs zu senken. (Bildquelle: Cypress Semiconductor)

Im Betrieb passt die PMU die Stromversorgungskreise entsprechend dem ausgewählten Modus an. Verfügbare Modi sind der vollständig aktive Modus, der Leerlaufmodus sowie drei verschiedene Ruhemodi. Im Modus mit dem geringsten Stromverbrauch, dem SDS-Modus (Shut-Down-Sleep-Modus), schaltet die PMU alle Komponentenblöcke mit Ausnahme des I/O-Stroms, der Echtzeituhr (RTC, Real-Time Clock) und einem dedizierten energiesparenden Oszillator (LPO) ab, der für manche Blöcke und den Wakeup-Timer als Quelle verwendet wird.

Selbst mit diesen minimalen Ressourcen kann die CYW20719 im SDS-Modus eine Verbindung zu einer anderen, zuvor gekoppelten Bluetooth-Komponente aufrechterhalten, wobei hierfür weniger als 70 Mikroampere (μA) verbraucht werden. In diesem Modus kann jedoch der Speicher nicht verwendet werden. Daher ist ein Warmstart der Komponente erforderlich, bevor wieder komplexere Vorgänge ausgeführt werden können. In den zwei weiteren Ruhemodi, dem Power-Down-Sleep- (PDS-) und dem Schlafmodus, ist die Komponente etwas aktiver. Unter anderem wird in diesen Modi der Speicher weiterhin verwendet. Dies ist mit einem entsprechenden schrittweisen Anstieg des Stromverbrauchs verbunden. Selbst dann können Entwickler mit sehr begrenzten Leistungsbudgets den PDS-Modus für die Advertising-Kanäle von Bluetooth Low Energy (etwa 125 μA) und aktive Verbindungen (etwa 170 μA) nutzen. Durch eine Verwaltung der Stromverbrauchsmodi der Komponente können Entwickler einen überaus energiesparenden Betrieb ermöglichen, ohne dabei Abstriche bei der Funktionalität machen zu müssen.

Systemintegration

Selbst mit ihren flexiblen Betriebsmodi und dem enormen Funktionsumfang benötigt die CYW20719 einige wenige zusätzliche Komponenten, um die Hardwareintegration in ein Systemdesign abzuschließen. Da wichtige Komponenten bereits auf dem Chip integriert sind, müssen die Entwickler lediglich einige wenige Widerstände, Kopplungskondensatoren, einen 2,2-µH-Induktor wie den Murata LQH2MCN2R2M52L und Ferritperlen wie die Murata BLM15AG601SN1D hinzufügen (Abbildung 3). Nach wie vor ist es ratsam, einen Bandpassfilter zwischen der CYW20719 und den Anpassungskomponenten für die Antenne zu platzieren, um Oberschwingungen zu verringern.

Schaltbild der Cypress CYW20719 (zum Vergrößern anklicken)

Abbildung 3: Da alle wichtigen Funktionen auf der Cypress CYW20719 bereits integriert sind, können Entwickler die Hardwareintegration mit wenigen zusätzlichen Komponenten wie etwa einem empfohlenen Bandpassfilter zur Verringerung von Oberschwingungen abschließen. (Bildquelle: Cypress Semiconductor)

Auf ähnliche Weise erleichtert die Komponente die Softwareintegration durch ihren umfangreichen On-Chip-Speicher inklusive 1 MB Flash, 512 KB RAM und 2 MB ROM. Während Flash und ROM den Entwicklern Speicherbereiche für ihre Anwendungen bieten, ist der On-Chip-ROM für die Firmware der Komponente sowie Bluetooth-Profile reserviert. Zur Unterstützung erforderlicher Firmware-Updates verfügt die Komponente über einen Patch-RAM. Hierbei handelt es sich um einen Bereich im RAM, der über eine Patch-Steuerlogik verbunden ist (siehe Abbildung 1 oben). Schließlich verfügt die Komponente noch über einen permanent aktiven Speicherbereich (AON, Always-On), der selbst in den Energiesparmodi (z. B. im SDS-Modus), die ansonsten den flüchtigen Speicher deaktivieren würden, die Speicherung von Daten ermöglicht.

Obwohl die auf dem Chip integrierten RAM- und Flash-Speicher im Vergleich zu anderen modernen Komponenten nicht unbedingt üppig erscheinen, sorgt die umfangreiche, in den ROM integrierte Softwareunterstützung dafür, dass für typische Anwendungen stets genügend Speicher zur Verfügung steht. Cypress konfiguriert den On-Chip-ROM mit einem umfassenden Software-Stack, der vom niedrigsten Hardware Abstraction Layer (HAL) bis hinauf zur Schnittstelle zur Anwendungsprogrammierung (API) für die WICED-Umgebung (Wireless Internet Connectivity for Embedded Devices) alles abdeckt (Abbildung 4).

Darstellung der 2-MB-ROM-Firmware der Cypress CYW20719

Abbildung 4: Die 2-MB-ROM-Firmware der Cypress CYW20719 bietet einen vollständigen Software-Stack inklusive Echtzeit-Betriebssystem, wodurch Komplexität und Footprint des Anwendungscodes des Entwicklers verringert werden. (Bildquelle: Cypress Semiconductor)

Aufbauend auf dem HAL führt die ROM-Firmware ein integriertes Echtzeit-Betriebssystem aus und übernimmt sämtliche Interaktionen mit der Hardware der CYW20719. Gleichzeitig umfasst die ROM-Firmware eine breite Palette an Bluetooth-Service-Layern, inklusive derjenigen, die das für Bluetooth unentbehrliche Generic Attribute Profile (GATT) sowie das Generic Access Profile (GAP) unterstützen.

Für typische Anwendungen wird der Entwicklercode aus dem RAM heraus ausgeführt, wobei die WICED-APIs verwendet werden, um auf das Echtzeit-Betriebssystem, Peripheriegeräte und weitere Komponentenfunktionen zuzugreifen. Obwohl die RAM-Anforderungen erheblich variieren können, lässt der Großteil des Anwendungscodes für die CYW20719 üblicherweise noch ausreichend freien RAM für Daten- oder Arbeitsspeicher. So stehen beispielsweise bei der weiter unten beschriebenen Anwendung „hello_sensor“ noch etwa 240 KB freier RAM zur Verfügung.

Jedoch können Entwickler für Anwendungen mit besonders großen Codebasen die Fähigkeit der CYW20719 zur Verarbeitung von Anwendungscode nutzen, der zur direkten Ausführung (XiP, eXecute-in-Place) im On-Chip-Flash entwickelt wurde. In diesem Fall lädt die WICED-Umgebung den vom Entwickler angegebenen Code und schreibgeschützte Datenbereiche in den On-Chip-Flash und die verbleibenden Abschnitte in den RAM. Dieser Ansatz verringert selbstverständlich den RAM-Footprint einer Anwendung, kann sich aber auf die Leistung auswirken. Folglich müssen Entwickler bei der Angabe von XIP-Codebereichen vorsichtig sein und dafür sorgen, dass zeitkritische Funktionen in den RAM geladen werden.

Anwendungsentwicklung

Obwohl der CYW20719 die Designintegration vereinfacht, können sich für Entwickler, die auf sichere, energieeffiziente Bluetooth-Anwendungen setzen, auch weiterhin erhebliche Verzögerungen bei der Fertigstellung des Hardwaredesigns und der Anwendungsentwicklung ergeben. Das zur Demonstration von auf dem CYW20719 basierenden Anwendungen entwickelte Evaluierungskit CYW920719Q40EVB-01 von Cypress Semiconductor nutzt die Cypress WICED-Softwareumgebung, um ein Referenzdesign und eine umfassende Entwicklungsplattform zur Erstellung von Bluetooth-5.0-kompatiblen IoT-Anwendungen bereitzustellen.

Das Evaluierungskit ist um ein Trägermodul herum aufgebaut, das den CYW20719 (im Design aus Abbildung 3) sowie einen Torex Semiconductor XC6119N-Spannungsdetektor umfasst, der mit dem RST_N-Pin der CYW20719 verbunden ist, um einen Reset durchzuführen. Das Trägermodul ist auf die Basiskarte des Kits aufgelötet, auf der sich ein 9-achsiger Bewegungssensor von STMicroelectronics (der LSM9DS1TR), ein NTC-Thermistor aus der NCU-Serie von Murata, die GPIO-Ports der CYW20719, ein Debugging-Anschluss, Arduino-kompatible Steckleisten für Erweiterungen sowie Schalter und LEDs als einfache Benutzerschnittstelle befinden (Abbildung 5).

Blockdiagramm des Evaluierungskits Cypress CYW920719Q40EVB-01

Abbildung 5: Das Evaluierungskit CYW920719Q40EVB-01 kombiniert einen CYW20719 auf einem Trägermodul mit mehreren Basiskartenkomponenten zur Unterstützung einer typischen IoT-Anwendung. (Bildquelle: Cypress Semiconductor)

Die Beispielsoftware von Cypress verwendet den CYW20719 und weitere Komponenten für die umfassende Demonstration von sicherer Bluetooth-Konnektivität in einem repräsentativen IoT-Netzwerk, das mehrere Sensorkomponenten und einen zentralen Hub umfasst (Abbildung 6). Mit dieser Beispielanwendung können Entwickler verschiedene Sicherheitsstufen für die Kopplung einer Sensorkomponente und dem Hub untersuchen und die Auswirkungen dieser verschiedenen Sicherheitsstufen auf den Datenaustausch evaluieren.

Schaubild: CYW920719Q40EVB-01-Kits und die Cypress WICED-Entwicklungsumgebung

Abbildung 6: Eine Beispielanwendung von Cypress, die für mehrere CYW920719Q40EVB-01-Kits und die Cypress WICED-Entwicklungsumgebung konzipiert ist, demonstriert sichere Bluetooth-Konnektivität in einer repräsentativen IoT-Anwendung. (Bildquelle: Cypress Semiconductor)

Für die Hardware der Anwendung verwenden die Entwickler ein separates CYW920719Q40EVB-01-Kit, das als sicherer Hub konfiguriert ist, sowie zusätzliche Kits, die als individuelle Sensoren im Netzwerk konfiguriert sind. Ein PC, der über eine serielle Verbindung mit den einzelnen Kits verbunden ist, fungiert als Konsole zum Einstellen von Parametern, zum Anzeigen von Daten, zum Ausdrucken von Debugging-Meldungen sowie für anderweitige Interaktionen mit der Beispielanwendung.

Das einzige weitere Element in einer typischen Anwendung wie dieser, das in dieser Beispielanwendung fehlt, wäre eine Verbindung zu einem Mobilgerät, um die Anwendung zu überwachen und die Funktionen zu steuern. In diesem Beispiel übernimmt der seriell verbundene PC in etwa dieselbe Funktion.

Cypress bündelt die Software für diese Beispielanwendung in seinem C-Sprachpaket CYW20917 BLE Secure Hub für seine WICED-Entwicklungsumgebung. In diesem Fall enthält das Paket zwei Projekte für die zwei separaten Rollen in der Beispielanwendung. Ein Projekt (secure_hub), das auf dem als sicherer Hub angegebenen Kit ausgeführt werden soll, ermöglicht dem Hub die Unterstützung mehrerer Bluetooth-Protokollrollen. Insbesondere soll die Hub-Software die Kopplung auf separaten Sicherheitsebenen mit verschiedenen als Slaves ausgeführten Kits ermöglichen.

Auf den als Slaves konfigurierten Kits wird das Sensorprojekt (hello_sensor) ausgeführt, das die Datenerfassung und -kommunikation auf der Sicherheitsebene veranschaulichen soll, die während der Kopplung eingerichtet wurde. Jedes Projekt umfasst mehrere Header- und Codemodule, die zur Unterstützung der einzelnen funktionalen Rollen benötigt werden. Unter diesen Dateien enthalten die Projekte „secure_hub“ und „hello_sensor“ jeweils eine Generic Attribute Profile (GATT) Header-Datei (gatt_db.h) und eine Codedatei (gatt_db.c).

Im Bluetooth-Protokoll definiert eine Lookup-Tabelle, die sogenannte GATT-Datenbank (DB), Art und Funktionen einer Bluetooth-Verbindung über einen Satz definierter Dienste, von denen jeder einzelne einen Satz unterstützter Merkmale umfasst. Die Bluetooth-Spezifikation enthält beispielsweise vordefinierte GATT-Dienste, die von Dienstprogrammfunktionen wie Warnmeldungen und Komponenteninformationen bis hin zu anwendungsspezifischen Funktionen wie Blutdruckmessungen und Pulsoximetern reichen. Das eine grundlegendere Rolle als die GATT-Dienste spielende Bluetooth Generic Access Profile (GAP) einer Komponente definiert, wie sie sich selbst dem Netzwerk gegenüber zu erkennen gibt und wie sie Verbindungen herstellt, sobald sie erkannt wurde.

Die Header-Datei „gatt_db.h“ und die Codedatei „gatt_db.c“ in den Projekten „secure_hub“ und „hello_sensor“ definieren GAP- und GATT-Dienste für die als sicherer Hub respektive Sensor konfigurierten Kits. Die für diese Demonstrationszwecke dienende Anwendung definiert jedes Projekt als einen benutzerdefinierten GATT-Dienst gemäß seiner Rolle. Die Header-Datei des Projekts „hello_sensor“ beispielsweise enthält einen enum-Typ in C, der verpflichtende GATT- und GAP-Dienst-Handles definiert, sowie eine benutzerdefinierte GATT-Definition für einen Sensordienst (Listing 1a). Die Datei „gatt_db.c“ dieses Projekts wiederum verwendet diese Definitionen zum Aufbau der GATT-DB, die im Bluetooth-Protokoll erforderlich ist (Listing 1b).

Kopieren

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)

Kopieren

 

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

Listing 1: Eine im Projekt „hello_sensor“ der Anwendung „BLE Secure Hub“ von Cypress enthaltene Header-Datei definiert einen Aufzählungstyp für verschiedene Merkmale (A), die vom entsprechenden Code-Modul zum Aufbau der GATT-Datenbank verwendet wird, die für den Bluetooth-Betrieb erforderlich ist. (Code-Quelle: Cypress Semiconductor)

Eingebettet in diese Definitionen definiert der GATT-Sensordienst außerdem, ob die ihm zugrunde liegenden Dienstmerkmale lesen, schreiben, benachrichtigen oder anzeigen können (über die verbundene Konsole). Das Merkmal für das Blinken der LED beispielsweise (HANDLE_HSENS_SERVICE_CHAR_BLINK, deklariert im Listing 1a und angewendet im Listing 1b) enthält Bitmasken (LEGATTDB_CHAR_PROP_READ | LEGATTDB_CHAR_PROP_WRITE im Listing 1b), die angeben, dass dieses Merkmal sowohl lesbar als auch schreibbar ist.

Die Datei „gatt_db.c“ des Projekts „hello_sensor“ jedoch kombiniert diese Definitionen mit Code, der sicheren Zugriff auf dieses Merkmal implementiert. Das ist die Funktion, dass die LED so oft blinken kann, wie es durch ein vom Entwickler über die Konsole eingegebenes Zeichen angezeigt wird. Für diese Beispielanwendung erfordert der Zugriff auf diese Funktion, dass die Verbindung zu diesem Sensorkit per Bluetooth-Kopplung in Man-in-the-Middle-Form (MITM) mit einem vom Benutzer bereitgestellten Hauptschlüssel hergestellt wurde, der während der Kopplung über die Konsole eingegeben wurde.

Im Allgemeinen gilt, dass, wenn der Aufruf einer Funktion angefordert wird, ein entsprechender Handler die anwendungsspezifische Aufgabe ausführt, wobei sowohl die definierten Merkmale als auch die Anforderungen für sicheren Zugriff berücksichtigt werden. Wenn im Beispiel der blinkenden LED die Ausführung der LED-Blinkfunktion angefordert wird, ist der tatsächliche Code zur Gewährleistung der Berechtigung und Autorisierung des Zugriffs einfach genug.

Um den Wert des Merkmals für die blinkende LED (HANDLE_HSENS_SERVICE_CHAR_BLINK_VAL) zu ändern, verwendet der Code eine bedingte Anweisung, die sowohl die Schreibberechtigung als auch die Zugriffsautorisierung bestätigt (Listing 2). Für die Schreibberechtigung vergleicht die bedingte Anweisung die angeforderte Berechtigung (LEGATTDB_PERM_AUTH_WRITABLE) mit der tatsächlichen Einstellung für die Blinkberechtigung der LED-Komponente, LED_BLINK_CHAR_PERMISSION (definiert am Anfang von Listing 1b). Für die Autorisierung überprüft die bedingte Anweisung, ob die aktuell gekoppelte Sicherheitsstufe (paired_security_level) per MITM-Kopplung (BTM_SEC_LINK_PAIRED_WITH_MITM) erstellt wurde (Listing 2).

Kopieren

/*

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

}

Listing 2: In diesem Snippet aus der Anwendung „BLE Secure Hub“ von Cypress muss eine Anforderung zur Ausführung des Merkmals „LED Blink“ für die Berechtigung und Sicherheitsautorisierung zuerst eine Prüfung (markiert) bestehen. (Code-Quelle: Cypress Semiconductor)

Mit den GATT-DB-Definitionen und dem unterstützenden Code für das Sensor- und das Hub-Projekt stellt diese Beispielanwendung Entwicklern die grundlegenden Designmuster für drei verschiedene Sicherheitsstufen zur Verfügung, inklusive aller Kopplungsstufen, MITM-Kopplung (hier beschrieben) und Bluetooth LE Secure-Kopplung. Letztgenannte Kopplungsmethode bietet die höchste Sicherheit, da sie eine Authentifizierungsmethode verwendet, die auf dem ECDH-Schlüsselaustausch (Elliptic Curve Diffie-Hellman) basiert. Da die integrierte Sicherheits-Engine des CYW20719 einen ECDH-Beschleuniger beinhaltet, können Entwickler diesen Ansatz ohne Kompromisse bei der Leistung anwenden.

Fazit

Die Verfügbarkeit integrierter, Bluetooth-fähiger MCUs für drahtlose Netzwerke hat dazu beigetragen, dass Entwickler diese Komponenten schneller in ihre Designs integrieren können. Bei der Implementierung sicherer Bluetooth-Netzwerke sehen sich die Entwickler jedoch mit verschiedenen Herausforderungen hinsichtlich der Erstellung von Bluetooth-kompatiblen Diensten und dem Programmieren von Anwendungen konfrontiert, die diese Komponenten sicher nutzen können.

Basierend auf der Bluetooth-MCU Cypress CYW20719 stellen das Bluetooth-Evaluierungskit CYW920719Q40EVB-01 und die WICED-Entwicklungsumgebung von Cypress Semiconductor eine umfassende Plattform zur Erstellung dieser Anwendungen zur Verfügung. Die Verwendung der Kits und der WICED-Umgebung zusammen mit dem Paket „BLE Secure Hub“ von Cypress Semiconductor ermöglicht Entwicklern die schnelle Evaluierung sicherer Bluetooth-Anwendungen und ihre rasche Integration in kundenspezifische Anwendungen, die in der Lage sind, die höhere Geschwindigkeit und Reichweite von Bluetooth 5 zu nutzen

Haftungsausschluss: Die Meinungen, Überzeugungen und Standpunkte der verschiedenen Autoren und/oder Forumsteilnehmer dieser Website spiegeln nicht notwendigerweise die Meinungen, Überzeugungen und Standpunkte der Digi-Key Electronics oder offiziellen Politik der Digi-Key Electronics wider.

Über den Autor

Stephen Evanczuk

Stephen Evanczuk hat mehr als 20 Jahre Erfahrung im Schreiben für und über die Elektronikindustrie zu einem breiten Spektrum von Themen wie Hardware, Software, Systeme und Anwendungen einschließlich des IoT. Er promoviertein Neurowissenschaften über neuronale Netzwerke und arbeitete in der Luft- und Raumfahrtindustrie an massiv verteilten sicheren Systemen und Methoden zur Beschleunigung von Algorithmen. Derzeit, wenn er nicht gerade Artikel über Technologie und Ingenieurwesen schreibt, arbeitet er an Anwendungen des tiefen Lernens (Deep Learning) zu Erkennungs- und Empfehlungssystemen.

Über den Verlag

Nordamerikanische Fachredakteure von Digi-Key