Le modèle de données (DM) d'un nœud n'est pas pertinent si nous ne pouvons pas effectuer d'opérations sur celui-ci. Le modèle d'interaction (IM) définit la relation entre le DM d'un nœud et le DM d'autres nœuds : un langage commun pour la communication entre les DM.
Les nœuds interagissent entre eux de la manière suivante :
- Lire et s'abonner aux attributs et aux événements
- Écrire dans les attributs
- Appeler des commandes
Chaque fois qu'un nœud établit une séquence de communication chiffrée avec un autre nœud, ils constituent une relation d'interaction. Les interactions peuvent être composées d'une ou de plusieurs transactions, et les transactions sont composées d'une ou de plusieurs actions qui peuvent être comprises comme des messages de niveau messagerie instantanée entre les nœuds.
Plusieurs actions sont acceptées pour les transactions, comme l'action de requête de lecture qui demande un attribut ou un événement à un autre nœud, ou sa réponse, l'action de rapport de données, qui renvoie les informations du serveur au client.
Initiateurs et cibles
Le nœud qui lance une transaction est l'initiateur, tandis que le nœud qui répond est la cible. En règle générale, l'initiateur est un cluster client et la cible est un cluster serveur. Cependant, il existe des exceptions à ce modèle, comme dans les interactions d'abonnement analysées plus loin dans cette section.
Groupes
Les nœuds de Matter peuvent appartenir à un groupe. Un groupe d'appareils est un mécanisme permettant d'adresser et d'envoyer des messages à plusieurs appareils simultanément dans la même action. Tous les nœuds d'un groupe partagent le même ID de groupe, un entier de 16 bits.
Pour permettre la communication au niveau du groupe (Groupcast), Matter exploite les messages Multicast IPv6, et tous les membres du groupe ont la même adresse Multicast.
Chemins d'accès
Chaque fois que nous voulons interagir avec un attribut, un événement ou une commande, nous devons spécifier le chemin d'accès de cette interaction : l'emplacement d'un attribut, d'un événement ou d'une commande dans la hiérarchie du modèle de données d'un nœud. Toutefois, les chemins d'accès peuvent également utiliser des groupes ou des opérateurs génériques pour s'adresser à plusieurs nœuds ou clusters simultanément, ce qui regroupe ces interactions et réduit ainsi le nombre d'actions.
Ce mécanisme est important pour améliorer la réactivité des communications. Par exemple, lorsqu'un utilisateur souhaite éteindre toutes les lumières, un assistant vocal peut établir une seule interaction avec plusieurs lumières d'un groupe au lieu d'une séquence d'interactions individuelles. Si l'initiateur crée des interactions individuelles avec chaque lumière, cela peut générer une latence perceptible par l'humain dans la réactivité de l'appareil. Cet effet entraîne une réaction des différents appareils à une commande avec des délais visibles entre eux. On parle souvent d'"effet pop-corn".
Un chemin d'accès dans Matter peut être assemblé à l'aide de l'une des options ci-dessous :
<path> = <node> <endpoint> <cluster> <attribute | event | command>
<path> = <group ID> <cluster> <attribute | event | command>
Dans ces blocs de construction de chemin d'accès, endpoint et cluster peuvent également inclure des opérateurs génériques pour sélectionner plusieurs instances de nœud.
Chronométré et non chronométré
Il existe deux façons d'effectuer une transaction d'écriture ou d'appel : avec délai et sans délai. Les transactions chronométrées établissent un délai avant expiration maximal pour l'envoi de l'action d'écriture/appel. L'objectif de ce délai avant expiration est d'empêcher une attaque par interception sur la transaction. Cela est particulièrement vrai pour les appareils qui contrôlent l'accès à des biens, tels que les ouvre-portes de garage et les serrures.
Pour comprendre les transactions chronométrées, il est utile de comprendre comment les attaques par interception peuvent se produire et pourquoi les transactions chronométrées sont importantes.
L'attaque d'interception
Une attaque par interception suit le schéma suivant :
- Alice envoie à Bob un message initial, par exemple une action de demande d'écriture.
- Eve, un pirate de type "man-in-the-middle", intercepte le message et empêche Bob de le recevoir, par exemple par le biais d'un brouillage radio.
- Alice, ne recevant pas de réponse de Bob, envoie un deuxième message.
- Eve intercepte à nouveau et empêche Bob de le recevoir.
- Eve envoie le premier message intercepté à Bob, comme s'il provenait d'Alice.
- Bob envoie la réponse à Alice (et à Eve).
- Eve conserve le deuxième message intercepté pour le rejouer plus tard. Comme Bob n'a jamais reçu le deuxième message intercepté d'Alice, il l'acceptera. Ce message représente une faille de sécurité lorsqu'il encode une commande telle que "ouvrir le verrou".
Pour éviter ce type d'attaque, les actions chronométrées définissent un délai avant expiration maximal de la transaction au début de celle-ci. Même si Eve parvient à exécuter les six premières étapes du vecteur d'attaque, elle ne pourra pas rejouer le message à l'étape 7 en raison d'un délai d'expiration de la transaction.
Les transactions chronométrées augmentent la complexité et le nombre d'actions. Elles ne sont donc pas recommandées pour toutes les transactions, mais uniquement pour les opérations critiques sur les appareils qui contrôlent les ressources de sécurité et de confidentialité physiques ou virtuelles.
Abstractions du SDK
Les sections Transactions de lecture, Transactions d'écriture et Transactions d'appel fournissent un aperçu général des actions du modèle d'interaction effectuées par le SDK.
Le développeur qui crée un produit utilisant le SDK Matter n'effectue généralement pas d'appels pour exécuter directement des actions. Les actions sont extraites par des fonctions du SDK qui les encapsulent dans une interaction. Toutefois, il est important de comprendre les actions de messagerie instantanée pour que l'ingénieur maîtrise bien les fonctionnalités de Matter et puisse contrôler précisément l'implémentation du SDK.