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 DM d'un nœud avec le DM d'autres nœuds : il s'agit d'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 plusieurs transactions, et les transactions sont composées d'une ou plusieurs actions qui peuvent être comprises comme des messages au niveau de l'IM entre les nœuds.
Plusieurs actions sont compatibles avec les transactions, comme une action de demande de lecture qui demande un attribut ou un événement à un autre nœud, ou sa réponse, l'action de données de rapport, qui transmet les informations du serveur au client.
Initiateurs et cibles
Le nœud qui initie 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. Toutefois, il existe des exceptions à ce modèle, comme dans les interactions avec les abonnements 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 dans la même action simultanément. Tous les nœuds d'un groupe partagent le même ID de groupe, un entier de 16 bits.
Pour communiquer au niveau du groupe (Groupcast), Matter utilise les messages IPv6 Multicast, et tous les membres du groupe ont la même adresse Multicast.
Chemins d'accès
Chaque fois que nous souhaitons interagir avec un attribut, un événement ou une commande, nous devons spécifier le chemin d'accès pour 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 peuvent également utiliser des groupes ou des opérateurs génériques pour cibler plusieurs nœuds ou clusters simultanément, en agrégeant ces interactions et en diminuant 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'homme dans la réactivité de l'appareil. Cet effet entraîne une réaction des appareils multiples à 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 écriture ou d'appeler une transaction : avec délai et sans délai. Les transactions temporisées établissent un délai avant expiration maximal pour l'envoi de l'action d'écriture/d'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 aux biens, comme les ouvre-portes de garage et les serrures.
Pour comprendre les transactions temporisées, il est utile de comprendre comment les attaques par interception peuvent se produire et pourquoi les transactions temporisées sont importantes.
Attaque par interception
Une attaque par interception présente le schéma suivant :
- Alice envoie à Bob un message initial, tel qu'une action de demande d'écriture.
- Eve, un homme au milieu, intercepte le message et empêche Bob de le recevoir, par exemple en brouillant les ondes radio.
- Alice, qui n'a pas reçu de réponse de Bob, lui envoie un deuxième message.
- Eve intercepte à nouveau le message et empêche Bob de le recevoir.
- Ève envoie le premier message intercepté à Bob, comme s'il provenait d'Alice.
- Bob envoie la réponse à Alice (et à Ève).
- 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 la serrure".
Pour éviter ces types d'attaques, les actions programmées définissent un délai d'expiration maximal pour 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 sur la transaction.
Les transactions programmées augmentent la complexité et le nombre d'actions. Elles ne sont donc pas recommandées pour chaque transaction, 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 des actions directement. Les actions sont abstraites par des fonctions SDK qui les encapsulent dans une interaction. Toutefois, il est important de comprendre les actions IM pour fournir à l'ingénieur une bonne maîtrise des capacités de Matter, ainsi qu'un contrôle précis sur l'implémentation du SDK.