Vereinheitlichung von Smart Home IoT mit einem allgegenwärtigen, IP-basierten Protokoll

Die Entmystifizierung von Matter 1.0 und seine Bedeutung für die IoT-Konnektivität

Von Jean-Jacques DeLisle für Mouser Electronics

Einleitung

Die Matter 1.0-Spezifikation ist der Höhepunkt einer umfassenden Zusammenarbeit zwischen Hunderten zentralen Akteuren im Bereich IoT-Konnektivität. Die Connectivity Standards Alliance (CSA) hat vor Kurzem den Standard und das Zertifizierungsprogramm veröffentlicht, die eine neue Ära der IoT-Konnektivität einleiten sollen, die sich auf die gesamte vertikale Smart-Home-IoT-Branche auswirkt, vom Silizium bis zum Point-of-Sale. Matter 1.0 stellt ein einziges, IP-basiertes Protokoll bereit, das die Smart-Home-IoT-Konnektivität weltweit vereinheitlichen kann.
Dieser Artikel diskutiert die grundlegende Architektur, die Sicherheit, den Transport und das Interaktionsmodell von Matter 1.0 und was dies für die Zukunft des Smart Home bedeutet. Zum Schluss stellt der Artikel ideale Entwicklungsoptionen für die Entwicklung von Matter 1.0 über Wi-Fi vor, vom schnellen Prototyping bis hin zu vollständigen Entwicklungsanwendungen.

Zentrale Matter 1.0-Spezifikationen

Bei Matter 1.0 handelt es sich im Wesentlichen um eine Interoperabilitätslösung für die Anwendungsschicht, die die Konnektivität zwischen Smart-Home-Geräten über das Internetprotokoll (IP) ermöglicht. Dies umfasst eine Anwendungsschicht und einen Transportschichtstapel. Die Spezifikation soll ein vollständiger Standard sein, aber dieser Artikel verweist auf andere Referenzen, die für die Spezifikation von Bedeutung sind. Ein wichtiger Hinweis ist, dass die Matter-Spezifikation R1.0 Vorrang vor dem Matter-SDK hat, das auf github.com verfügbar ist.

Architektur
Matter basiert auf IPv6 und wurde als Kommunikationsprotokoll eigens für Smart-Home-Geräte entwickelt. Es besteht aus einer Anwendungsebene und einer Netzwerkebene (Abbildung 1). Die Netzwerkebene besteht ihrerseits aus einer Transportebene (TCP und UDP), einer Netzwerkebene (IPv6) und einer Link-/Medienebene (Ethernet, WLAN, Thread und IEEE 802.15.4). Dieser Ansatz ermöglicht die effiziente Aufteilung von Verantwortlichkeiten und dient dazu, eine ausreichende Abkapselung zwischen den Protokollstapelebenen zu gewährleisten.

Abbildung 1: Anwendungs- und Netzwerkebenen von Matter R1.0 (Quelle: Connectivity Standards Alliance)

Die Spezifikation wurde ausgehend von der Überlegung entworfen, dass die meisten Interaktionen dem in Tabelle 1 dargestellten Ablauf des Stapels folgen.

Tabelle 1: Beschreibungen geschichteter Architekturen (Quellen: Connectivity Standards Alliance und Mouser Electronics)

Da Matter 1.0 auf IPv6 basiert, ist nahezu jedes IPv6-fähige Netzwerk mit der Spezifikation kompatibel, sofern es mehrere zentrale IPv6-Core-Standards unterstützt. Diese erste Version des Standards konzentriert sich jedoch auf die Unterstützung der Verbindungsschichten Ethernet, Wi-Fi und Thread und ist daher auf diese drei Verbindungsschichten beschränkt.

Die Matter 1.0-Spezifikation ermöglicht den Betrieb außerhalb einer global routbaren IPv6-Infrastruktur, um unvernetzten bzw. durch Firewall geschützten Intranets die Unterstützung eines Matter-Netzwerks zu ermöglichen. Dies ist wichtig für Situationen, in denen ein Internetanbieter IPv6 mit den von ihm zur Verfügung gestellten Endgeräten nicht ausreichend unterstützt. Da Matter 1.0 Netze als gemeinsam genutzte Ressourcen behandelt, können mehrere Matter-Netze in denselben IP-Netzen vorhanden sein.

Dieses Protokoll kann lokale Kommunikationen unterstützen, die sich über ein oder mehrere IPv6-Subnetze erstrecken, darunter kanonische Netzwerke, Ethernet-/WLAN-Subnetze und Low Power- und Lossy Networks (LLN)-Subnetze wie Thread. Matter kann als Einzelnetzwerk betrieben werden (z. B. als einzelnes WLAN- oder Thread-Netzwerk) oder mit der Topologie eines Sternnetzwerks, bei der multiple periphere Netzwerke durch ein zentrales Hub-Netzwerk verbunden sind (z. B. ein Ethernet-/WLAN-Heimnetzwerk). Damit Kommunikationen Netzwerkgrenzen überschreiten können, ist ein Border-Router notwendig.

Sicherheit und Kryptografie
Das Matter-Protokoll unterstützt multiple Administratoren (Multi-Admin) ohne gemeinsame Vertrauensanker. Matter führt zudem ein Konzept namens „Fabric“ ein – eine Ansammlung von Matter-Geräten, die sich einen Vertrauensanker teilen. Dementsprechend werden Multi-Admin-Abläufe durch multiple Fabrics angesprochen und sind ein zentraler Bestandteil des Benennungsumfangs. Onboarding, sichere Kommunikationen und Fabric-bezogene Datenportionen des Datenmodells ermöglichen die Funktionalität multipler Fabrics. Als Teil multipler Fabrics können Matter-Geräte über multiple Knoten-IDs verfügen. Das ist möglich, weil sich Matter auf einen operationellen Vertrauensanker bzw. eine Root-Zertifizierungsstelle (CA) stützt, die durch einen öffentlichen Schlüssel (Root PK) bestimmt werden, der dazu dient, die korrekten Fabric-bezogenen Identifikatoren zuzuweisen. Neben anderen Datenspeichern benutzt Matter einen administrativen Domain Manager, der die Zusammenarbeit mit dem Bevollmächtigten und seine Root CA enthält. Der private Schlüssel der CA ist geschützt, nicht erratbar, unerreichbar und impliziert einen weltweit einzigartigen öffentlichen Schlüssel. Innerhalb einer Root CA kommt ein einzigartiger 64 Bit-Identifikator zum Einsatz. Darüber hinaus zieht eine reservierte ursprüngliche Fabric-ID eine Reihe initialer Zugangskontrollprivilegien nach sich, die zusammen mit der initialen Inbetriebnahme verwendet werden. Das bedeutet, dass Matter-Geräte vor einer primären Inbetriebnahme über keinerlei im Vorfeld zugewiesene, operative Vertrauensanker bzw. operative IDs verfügen.

Die Kryptographie mit öffentlichem Schlüssel und die digitalen Signaturen werden mit einem elliptischen Kurvenverschlüsselungsansatz auf der Grundlage der NIST P-256-Kurve (Secp256r1) gesichert. Kryptografische Operationen mit gemeinsamem Schlüssel werden mit etablierten AES-Modi geschützt, und SPAKE2+ wird für die Out-of-Band-Authentifizierung mit Passcode verwendet. Darüber hinaus sind alle Unicast Node-to-Node (N2N)-Nachrichten mit einem Wiederholungsschutz versehen, authentifiziert und gesichert.

Matter nutzt eine Vielzahl an kryptografischen Protokollbausteinen, Algorithmen und Primitiven. Zudem erhöhen symmetrische Blockverschlüsselungen in diesem Protokoll die Nachrichtensicherheit. Um sämtliche Unicast- und Multicast-Nachrichten, die einen Vertraulichkeitsschutz und die Authentifizierung ihrer Ursprungsintegrität benötigen, zwischen Knoten zu schützen, muss Authenticated Encryption with Associated Data (AEAD) als Primitiv verwendet werden.

Darüber hinaus verwendet das Protokoll Certificate-Authenticated Session Establishment (CASE) oder Password-Authenticated Connection Establishment (PASE), um das sichere Erstellen von Sitzungen zu gewährleisten, mit deren Hilfe Secure Channel and Message Layer (Abbildung 2) die sichere Kommunikation zwischen Knoten ermöglicht. Das Erstellen des Kontrollplans für sichere Kanalfunktionen erfolgt mittels Secure Channel Protocol. Zudem verwendet Matter Device Attestation-Maßnahmen, um das Vertrauen zwischen Entitäten herzustellen, bevor sensible Informationen (z. B. Berechtigungen oder Schlüssel) geteilt werden. Device Attestation Certificate und Certification Declaration sind Teil des Device Attestation-Mechanismus von Matter.  

Abbildung 2: Stapel der Nachrichtenebene. (Quelle: Connectivity Standards Alliance)

Datenmodell
Bei der Spezifikation des Matter-Datenmodells handelt es sich um eine Gruppe an Spezifikationen, die aus dem Dotdot-Architekturmodell und Kapitel 2 der Spezifikation der Zigbee Cluster Library (ZCL) hervorging und in Bezug auf die zugrundeliegenden Kodierungs-, Benachrichtigungs-, Netzwerk-, Transport- und sonstigen Ebenen als unabhängig entworfen wurde. Das Datenmodell für Matter soll eine Datenmodellarchitektur erweitern und detaillierter festlegen, ohne die durch die ZCL festgelegten zertifizierbaren Cluster-Spezifizierungen in Mitleidenschaft zu ziehen. Das Datenmodell wurde in die Anwendungsebene des Kommunikationsstapels implementiert und legt primär die Elemente der ersten Ordnung und den Namensbereich des Datenmodells fest. Aus diesem Grund wird es als Metamodell des Datenmodells bezeichnet.

Der Datenmodell-Abschnitt der Matter-Spezifikation definiert Fabric als einen Satz von Knoten, die durch Zugriff auf Datenmodellelemente, die durch das Interaktionsmodell definiert sind, interagieren. Dieser Abschnitt legt auch fest, dass „ein Knoten eine adressierbare, eindeutige Ressource im Netz kapselt, die über eine Reihe von Funktionen und Fähigkeiten verfügt, die ein Benutzer eindeutig als funktionales Ganzes erkennt.“ Weiter heißt es, dass ein Knoten typischerweise ein physisches Gerät oder eine logische Instanz eines physischen Geräts ist. Ein Endpunkt wird auch als eine Instanz definiert, entweder ein Dienst oder ein virtuelles Gerät, das durch einen Gerätetyp gekennzeichnet ist. Weitere Definitionen innerhalb des Datenmodells umfassen Cluster, Befehle, Attribute, globale Elemente, Ereignisse, Gerätetypen, Nicht-Standard, Datenfelder, Datentypen und herstellerspezifische Erweiterungen.

Interaktionsmodell
Wie das Datenmodell wird auch das Matter-Interaktionsmodell unabhängig gepflegt, ist von den unteren Schichten unabhängig/entkoppelt und definiert Interaktionen, Transaktionen und Aktionen zwischen Knoten. Wie das Datenmodell hat auch das Interaktionsmodell seine Wurzeln in Kapitel 2 der ZCL, das sich mit ZCL-Befehlen und -Interaktionen befasst. Matter 1.0 behebt die folgenden Lücken in der ZCL:

• Unterstützung von Nachrichten mit mehreren Elementen
• Synchronisiertes Reporting
• Reduzierung der Nachrichtentypen (Befehle und Maßnahmen)
• Unterstützung komplexer Datentypen in sämtlichen Nachrichten
• Ereignisse
• Abfangangriff

Das Interaktionsmodell wurde entworfen, um gegenwärtigen ZCL-Clusterspezifizierungen zu entsprechen und die laufende Unterstützung der Cluster-Entwicklung fortzusetzen. Insbesondere das Interaktionsmodell legt eine Abstraktionsebene fest, die Interaktionen der übrigen Ebenen abstrahieren soll (d. h. Sicherheit, Transport, Benachrichtigungsformat und Codierung). Dieser Abschnitt beschreibt Maßnahmen als „einzelne logische Kommunikationen ausgehend von einem Quellknoten hin zu einem oder mehreren Zielknoten. Eine einzelne Maßnahme wird dabei von einer oder mehreren Nachrichten übermittelt.“ Eine Transaktion wird definiert als eine Reihe an Maßnahmen und eine Interaktion als eine Reihe an Transaktionen. Innerhalb des Kontextes eines zugreifenden Fabric kann es zu Austauschen kommen oder nicht. Eine Interaktion zwischen einem Initiator und einem Ziel kann ein Knoten oder eine Gruppe sein. Die vier Interaktionstypen sind Lesen, Abonnieren, Schreiben und Aufrufen (Tabelle 2).

Tabelle 2: Vier Interaktionstypen (Quelle: Connectivity Standards Alliance)

Eine Transaktion kann Teil der Gesamtheit einer Interaktion sein. Eine Maßnahme innerhalb einer Transaktion ist entweder die erste Maßnahme, die durch einen einzelnen Knoten initiiert wird, oder verfügt über einen einzelnen Knoten oder eine Gruppe an Knoten als Zieldestination (entweder Unicast oder Gruppencast). Zur Kommunikation einer Maßnahme können eine oder multiple Matter-Nachrichten verwendet werden.

Systemmodell
Die Spezifikation des Matter-Systemmodells definiert ein System als „ein Set an Knoten und beständigen Beziehungen, die den Datenfluss ausgehend von einem lokalen oder externen Stimulus automatisieren bzw. steuern.“ Darüber hinaus schlägt das Systemmodell eine Brücke für Matter-unabhängige IoT-Geräte in einem Fabric, um Benutzern die Verwendung ihrer alten, Matter-unabhängigen Geräte zusammen mit Matter-Geräten (Abbildung 3) zu ermöglichen.
 
Abbildung 3: Prinzip der Überbrückung zwischen Matter-Geräten und Matter-unabhängigen Geräten. (Quelle: Connectivity Standards Alliance)

Die Entwicklung von Matter 1.0-konformer Hardware

Mit der Entwicklung von Matter 1.0 sind unzählige Zielsetzungen verbunden, darunter rasche Prototypisierungen unter Verwendung vorgefertigter Kits, das Erstellen von Machbarkeitsnachweisen mit einzigartigen Eigenschaften oder umfassende Entwicklungsmaßnahmen samt vollständigem HF-System, das beinahe einem endgültigen Produktionsmodell gleicht. Bei der Entwicklung von Matter-Geräten darf nicht vergessen werden, dass Matter 1.0 unmittelbar auf kabellosen IP-Netzwerkprotokollen basiert (z. B. entweder Thread oder WLAN). Aus diesem Grund sind Entwickler gezwungen, das jeweils angemessenste Protokoll für bestimmte Projekte auszuwählen. Besteht das Ziel in der Entwicklung ausgeklügelter und leistungsstarker drahtloser Mesh-Netzwerke mit Schwerpunkt auf stabiler Drahtlos-Konnektivität, dann ist Thread der geeignete Kandidat. Besteht das Ziel jedoch in einem Drahtlos-Netzwerk mit Fokus auf sowohl Niedrigenergie als auch optimaler Konnektivität, dann ist höchstwahrscheinlich WLAN die beste Wahl.

Die meisten Haushalte haben bereits einen WLAN-Router für das Internet zu Hause. Wir werden daher einige Optionen für Development Kits, Plattformen und drahtlose Module diskutieren, die sich gut für die Entwicklung von Matter 1.0 via WLAN eignen. Häuser, die bereits mit kompatiblen WLAN-Routern ausgestattet sind, verfügen bereits über einen Matter-over-Wi-Fi-Controller, was die Einführung von Matter-over-Wi-Fi-Endprodukten erleichtern sollte. Für Matter-over-Thread-Anwendungen wird ein Matter Border-Router (d. h. ein spezieller Matter-Hub, der Matter-over-Thread-Nachrichten übersetzen kann) benötigt.

Entwicklung von Matter 1.0 via WLAN
Um sehr viel Entwicklungszeit einzusparen und repetitive Entwicklungsoptionen möglichst rasch zu bewältigen, sollten Sie sich für ein Development Kit entscheiden, das gut zu den unterschiedlichen WLAN-zertifizierten Modulen passt. Die Anschaffung eines Development Kits und WLAN-Moduls von gängigen Erstausrüstern bzw. Herstellern führt höchstwahrscheinlich zu relativ kurzen Entwicklungsfristen, da derartige Erstausrüster bzw. Hersteller für gewöhnlich gut vernetzt sind und über ausreichend Supportmaterial verfügen, um Entwicklern bei Hindernissen bzw. Problemen schnell und unkompliziert zu helfen.

Eines dieser Kits ist das Infineon Technologies CY8CEVAL-062S2 PSoC™ 62S2 Evaluierungskit (Abbildung 4), das den Infineon PSoC 62 Mikrocontroller (MCU) verwendet. Das PSoC 62 verfügt über einen 150 MHz Arm® Cortex®-M4 Core, 100 MHz Arm Cortex-M0+ Core, 1 MB Flashspeicher, 288 KB SRAM, Hardware-Crypto-Beschleuniger und verschiedenste analoge sowie digitale Peripheriegeräte (Abbildung 5). Das Evaluierungskit verfügt über einen M.2-Schnittstellen-Steckverbinder für die immer beliebteren M.2-Funkmodule, einen Infineon OPTIGA™ Trust-M-Sicherheitscontroller und eine mikroBUS-Schnittstelle.

 
Abbildung 4: Board-Layout des Infineon Technologies CY8CEVAL-062S2 PSoC 62S2 Evaluierungskits, einschließlich M.2-Schnittstelle für den Anschluss von M.2-Hochgeschwindigkeitsfunkmodulen. (Quelle: Infineon Technologies)

 
Abbildung 5: Ein Blockdiagramm der Infineon Technologies PSoC 6 Mikrocontroller-Familie. (Quelle: Mouser Electronics)

Das Evaluierungskit ist Teil des IoT-Ökosystems von Infineon Technologies, zu dem mehrere wichtige Hardware-Modulpartner gehören, die das Ökosystem in die Lage versetzen, leistungsstarke und hochgradig interoperable Digital- und HF-Hardware anzubieten. Zu den Modulpartnern des Ökosystems gehören Laird Connectivity, Murata und Lantronix, die eine Reihe von WLAN-, Bluetooth®- und kombinierten WLAN-/Bluetooth-fähigen Modulen anbieten, die sich nahtlos in die MCU-Lösungen und Evaluierungskits von Infineon integrieren lassen und ideal für die Entwicklung von Matter 1.0 via WLAN sind.

Das CY8CEVAL-062S2 PSoC 62S2 Evaluierungskit wird mit einem vorinstallierten Laird Connectivity Sterling-LWB5+ Funkmodul und einer Laird Connectivity FlexPIFA Antenne geliefert. Das LWB5+ Modul basiert auf dem Infineon AIROC™ CYW4373E Chipsatz, unterstützt Wi-Fi 5 mit Bluetooth 5.0 Kommunikation und wurde speziell für die Anforderungen von medizinischen und industriellen IoT (IIoT)-Applikationen entwickelt. Ein Hauptvorteil dieses drahtlosen Moduls besteht darin, dass es auf einer Plattform mit drahtloser IP aufgebaut ist, die eine maximale Interoperabilität ermöglicht.

Eine weitere Bluetooth- und WLAN-fähige Option mit geringem Stromverbrauch ist das Murata Typ 1LV-Modul, das die Bluetooth 5.0 Low Energy-Spezifikation und Wi-Fi 802.11a/b/g/n/ac (d. h. nur 20 MHz-Kanal) bis zu einer Datenrate von 72,2 Mbps PHY unterstützt. Dieses Modul ist sowohl mit 2,4 GHz als auch mit 5 GHz WLAN kompatibel und umfasst den Infineon CYW43012 Chipsatz (Abbildung 6). Der WLAN-Abschnitt des Moduls kommuniziert mithilfe der AP und STA Dual Mode-Netzwerktopologie. WLAN unterstützt die SDIO v2.0 SDR25 Schnittstelle, während der Bluetooth-Abschnitt eine vierdrahtige UART-Hochgeschwindigkeitsschnittstelle unterstützt. Alternativ zum Typ 1LV-Modul gibt es das Murata Typ 1YN-Modul, das auf dem Infineon CYW43439 Kombi-Chipsatz basiert.
 

 
Abbildung 6: Ein Blockdiagramm des Infineon AIROC CYW43012 Dual-Band Wi-Fi 4 und Bluetooth 5.2 Kombinationsgeräts. (Quelle: Infineon Technologies)

Die Lösungen von Infineon für Matter via WLAN, die den Matter-Vorzertifizierungsprozess durchliefen und auf den zuvor erwähnten Hardware-Plattformen entwickelt wurden, wurden in ModusToolbox™ eingebaut. ModusToolbox™ ist die moderne, erweiterbare Entwicklungsumgebung von Infineon, die sowohl die Infineon PSoC™ Mikrocontroller und als auch die AIROC™ Bluetooth/WLAN-Kombigeräte unterstützt. Um viel Entwicklungszeit einzusparen und repetitive Entwicklungsoptionen möglichst rasch zu bewältigen, finden Sie unter https://www.infineon.com/matter hilfreiche Infomaterialien für die Entwicklung von Matter-via-WLAN-Produkten.

Fazit

Dieser Artikel hebt verschiedene Abschnitte und Details der kürzlich veröffentlichten Matter 1.0-Spezifikation hervor. In naher Zukunft werden Geräte von Herstellern, die bereits Matter 1.0-kompatibel sind, neue und verbesserte Interoperabilität erhalten. Mit der branchenweiten Akzeptanz und Unterstützung der Matter 1.0-Spezifikation werden praktisch alle zukünftigen Smart-Home-IoT-Geräte mit Matter 1.0 kompatibel und/oder zertifiziert sein. Die Spezifikation enthält auch Bestimmungen, die es ermöglichen, dass Nicht-Matter-Geräte über eine Brücke neben Matter-Geräten in einer Matter-Fabric funktionieren können. Das bedeutet, dass bestehende Smart-Home-IoT-Geräte, die nicht Matter-kompatibel sind, nicht unbedingt ersetzt werden müssen, und dass die Nutzer ein neues Maß an Interoperabilität, Sicherheit und Benutzerfreundlichkeit genießen werden.