Konzepte des Interaktionsmodells

Das Datenmodell eines Knotens ist nicht relevant, wenn wir keine Vorgänge darauf ausführen können. Das Interaktionsmodell (IM) definiert die DM-Beziehung eines Knotens mit dem DM anderer Knoten: eine gemeinsame Sprache für die Kommunikation zwischen DMs.

Knoten interagieren miteinander, indem sie:

  • Attribute und Ereignisse lesen und abonnieren
  • In Attribute schreiben
  • Befehle aufrufen

Wenn ein Knoten eine verschlüsselte Kommunikationssequenz mit einem anderen Knoten herstellt, bilden sie eine Interaktionsbeziehung. Interaktionen können aus einer oder mehreren Transaktionen bestehen. Transaktionen bestehen aus einer oder mehreren Aktionen, die als Nachrichten auf IM-Ebene zwischen Knoten verstanden werden können.

Hierarchie des Interaktionsmodells
Abbildung 1: Hierarchie des Interaktionsmodells

Für Transaktionen werden mehrere Aktionen unterstützt, z. B. eine Leseanfrageaktion, die ein Attribut oder Ereignis von einem anderen Knoten anfordert, oder die Antwort darauf, die Berichtsdatenaktion, die die Informationen vom Server an den Client zurückgibt.

Initiatoren und Ziele

Der Knoten, der eine Transaktion initiiert, ist der Initiator, während der Knoten, der antwortet, das Ziel ist. In der Regel ist der Initiator ein Client-Cluster und das Ziel ein Server-Cluster. Es gibt jedoch Ausnahmen von diesem Muster, z. B. bei den Abo-Interaktionen, die weiter unten in diesem Abschnitt analysiert werden.

Gruppen

Knoten in Matter können zu einer Gruppe gehören. Eine Gerätegruppe ist ein Mechanismus, mit dem mehrere Geräte gleichzeitig in derselben Aktion adressiert und Nachrichten an sie gesendet werden können. Alle Knoten in einer Gruppe haben dieselbe Gruppen-ID, eine 16-Bit-Ganzzahl.

Für die Kommunikation auf Gruppenebene (Groupcast) nutzt Matter IPv6-Multicast-Nachrichten. Alle Gruppenmitglieder haben dieselbe Multicast-Adresse.

Pfade

Wenn wir mit einem Attribut, Ereignis oder Befehl interagieren möchten, müssen wir den Pfad für diese Interaktion angeben: den Speicherort eines Attributs, Ereignisses oder Befehls in der Datenmodellhierarchie eines Knotens. Der Vorbehalt ist, dass Pfade auch Gruppen oder Platzhalteroperatoren verwenden können, um mehrere Knoten oder Cluster gleichzeitig anzusprechen, diese Interaktionen zu aggregieren und so die Anzahl der Aktionen zu verringern.

Dieser Mechanismus ist wichtig, um die Reaktionsfähigkeit der Kommunikation zu verbessern. Wenn ein Nutzer beispielsweise alle Lichter ausschalten möchte, kann ein Sprachassistent eine einzelne Interaktion mit mehreren Lichtern innerhalb einer Gruppe herstellen, anstatt eine Abfolge einzelner Interaktionen auszuführen. Wenn der Initiator einzelne Interaktionen mit jeder Leuchte erstellt, kann dies zu einer für den Menschen wahrnehmbaren Latenz bei der Reaktionsfähigkeit des Geräts führen. Dieser Effekt führt dazu, dass die verschiedenen Geräte mit sichtbaren Verzögerungen auf einen Befehl reagieren. Dies wird oft als „Popcorn-Effekt“ bezeichnet.

Ein Pfad in Matter kann mit einer der folgenden Optionen zusammengestellt werden:

<path> = <node> <endpoint> <cluster> <attribute | event | command>
<path> = <group ID>        <cluster> <attribute | event | command>

Innerhalb dieser Pfadbausteine können endpoint und cluster auch Platzhalteroperatoren enthalten, um mehr als eine Knoteninstanz auszuwählen.

Mit und ohne Zeitlimit

Es gibt zwei Möglichkeiten, eine Schreib- oder Aufruftransaktion auszuführen: Zeitgesteuert und Nicht zeitgesteuert. Zeitgesteuerte Transaktionen legen ein maximales Zeitlimit für das Senden der Schreib-/Aufrufaktion fest. Mit diesem Zeitlimit soll ein Abfangangriff auf die Transaktion verhindert werden. Dies gilt insbesondere für Geräte, die den Zugang zu Assets steuern, z. B. Garagentoröffner und Schlösser.

Um zeitgesteuerte Transaktionen zu verstehen, ist es hilfreich zu wissen, wie Intercept-Angriffe ablaufen können und warum zeitgesteuerte Transaktionen wichtig sind.

Der Intercept-Angriff

Ein Intercept-Angriff hat das folgende Muster:

  1. Alice sendet Bob eine erste Nachricht, z. B. eine Schreibanfrageaktion.
  2. Eve, ein Man-in-the-Middle, fängt die Nachricht ab und verhindert, dass Bob sie empfängt, z. B. durch eine Art Funkstörung.
  3. Alice erhält keine Antwort von Bob und sendet eine zweite Nachricht.
  4. Eve fängt die Nachricht wieder ab und verhindert, dass Bob sie erhält.
  5. Eve sendet die erste abgefangene Nachricht an Bob, als käme sie von Alice.
  6. Bob sendet die Antwort an Alice (und Eve).
  7. Eve behält die zweite abgefangene Nachricht für eine spätere Wiederholung. Da Bob die ursprüngliche zweite abgefangene Nachricht von Alice nie erhalten hat, wird er sie akzeptieren. Diese Nachricht stellt eine Sicherheitsverletzung dar, wenn sie einen Befehl wie „Schloss öffnen“ codiert.

Um diese Arten von Angriffen zu verhindern, wird bei zeitgesteuerten Aktionen zu Beginn der Transaktion ein maximales Transaktionszeitlimit festgelegt. Selbst wenn Eve die ersten sechs Schritte des Angriffsvektors ausführen kann, kann sie die Nachricht in Schritt 7 nicht wiederholen, da das Zeitlimit für die Transaktion abgelaufen ist.

Zeitgesteuerte Transaktionen erhöhen die Komplexität und Anzahl der Aktionen. Daher werden sie nicht für jede Transaktion empfohlen, sondern nur für kritische Vorgänge auf Geräten, die die Kontrolle über physische oder virtuelle Sicherheits- und Datenschutz-Assets haben.

SDK-Abstraktionen

Die Abschnitte Transaktionen lesen, Transaktionen schreiben und Transaktionen aufrufen bieten einen allgemeinen Überblick über die vom SDK ausgeführten Interaktionsmodellaktionen.

Der Entwickler, der ein Produkt mit dem Matter SDK erstellt, führt in der Regel keine Aufrufe aus, um Aktionen direkt auszuführen. Die Aktionen werden durch SDK-Funktionen abstrahiert, die sie in einer Interaktion kapseln. Es ist jedoch wichtig, IM-Aktionen zu verstehen, damit der Entwickler die Funktionen von Matter gut beherrscht und die SDK-Implementierung genau steuern kann.