Il modello di dati (DM) di un nodo non è pertinente se non possiamo eseguire operazioni su di esso. Il Modello di interazione (IM) definisce la relazione tra il modello di dati di un Nodo con il modello di dati di altri Nodi: un linguaggio comune per la comunicazione tra i modelli di dati.
I nodi interagiscono tra loro:
- Lettura e sottoscrizione di attributi ed eventi
- Scrittura negli attributi
- Richiamo dei comandi
Ogni volta che un Nodo stabilisce una sequenza di comunicazione criptata con un altro Nodo, i due Nodi costituiscono una relazione di interazione. Le interazioni possono essere costituite da una o più transazioni, che a loro volta sono costituite da una o più azioni, che possono essere considerate come messaggi a livello di IM tra i nodi.
Nelle transazioni sono supportate diverse azioni, ad esempio un'azione di richiesta di lettura che richiede un attributo o un evento da un altro nodo o la relativa risposta, l'azione Report Data, che restituisce le informazioni dal server al client.
Iniziatori e target
Il Nodo che avvia una transazione è l'iniziatore, mentre il Nodo che risponde è il target. In genere, l'iniziatore è un cluster di client e la destinazione è un cluster di server. Tuttavia, ci sono delle eccezioni a questo modello, come nel caso delle interazioni con gli abbonamenti analizzate più avanti in questa sezione.
Gruppi
I nodi in Matter possono appartenere a un gruppo. Un gruppo di dispositivi è un meccanismo per indirizzare e inviare messaggi a più dispositivi contemporaneamente nella stessa azione. Tutti i nodi di un gruppo condividono lo stesso ID gruppo, un numero intero a 16 bit.
Per realizzare la comunicazione a livello di gruppo (Groupcast), Matter sfrutta i messaggi Multicast IPv6 e tutti i membri del gruppo hanno lo stesso Multicast indirizzo.
Percorsi
Ogni volta che vogliamo interagire con un attributo, un evento o un comando, dobbiamo specificare il percorso per questa interazione: la posizione di un attributo, un evento o un comando nella gerarchia del modello di dati di un nodo. Il problema è che i percorsi possono anche utilizzare gruppi o operatori jolly per indirizzare contemporaneamente più nodi o cluster, aggregando queste interazioni e diminuendo così il numero di azioni.
Questo meccanismo è importante per migliorare la reattività delle comunicazioni. Ad esempio, quando un utente vuole spegnere tutte le luci, un assistente vocale può stabilire una singola interazione con più luci all'interno di un gruppo anziché una sequenza di singole interazioni. Se l'iniziatore crea singole interazioni con ogni luce, può generare una latenza percettibile dall'uomo nella reattività del dispositivo. Questo effetto fa sì che i vari dispositivi reagiscano a un comando con ritardi visibili tra loro. Questo fenomeno è spesso definito "effetto popcorn".
Un percorso in Matter può essere assemblato utilizzando una delle opzioni riportate di seguito:
<path> = <node> <endpoint> <cluster> <attribute | event | command>
<path> = <group ID> <cluster> <attribute | event | command>
All'interno di questi elementi costitutivi del percorso, endpoint e cluster possono includere anche operatori di caratteri jolly per selezionare più istanze di nodi.
A tempo e senza tempo
Esistono due modi per eseguire una transazione di scrittura o di chiamata: con timer e senza timer. Le transazioni temporizzate stabiliscono un timeout massimo per l'invio dell'azione di scrittura/richiesta. Lo scopo di questo timeout è impedire un attacco di intercettazione sulla transazione. È particolarmente valido per i dispositivi che controllano l'accesso alle risorse, come serrature e aprigarage.
Per comprendere le transazioni con timer, è utile capire come possono verificarsi gli attacchi di intercettazione e perché le transazioni con timer sono importanti.
Attacco di intercettazione
Un attacco di intercettazione ha il seguente pattern:
- Alice invia a Bob un messaggio iniziale, ad esempio un'azione di richiesta di scrittura.
- Eva, un malintenzionato, intercetta il messaggio e impedisce a Bob di riceverlo, ad esempio tramite un qualche tipo di jamming radio.
- Alice, non ricevendo una risposta da Bob, invia un secondo messaggio.
- Eva intercetta di nuovo il messaggio e impedisce a Bob di riceverlo.
- Eva invia il primo messaggio intercettato a Bob, come se provenisse da Alice.
- Bob invia la risposta ad Alice (e a Eva).
- Eva conserva il secondo messaggio intercettato per riprodurlo in un secondo momento. Poiché Bob non ha mai ricevuto il secondo messaggio originale intercettato da Alice, lo accetterà. Questo messaggio rappresenta una violazione della sicurezza quando codifica un comando come "apri serratura".
Per impedire questi tipi di attacchi, le azioni a tempo impostano un timeout massimo per la transazione all'inizio della transazione. Anche se Eva riesce a eseguire i primi sei passaggi del vettore di attacco, non potrà riprodurre il messaggio nel passaggio 7 a causa di un timeout scaduto nella transazione.
Le transazioni a tempo aumentano la complessità e il numero di azioni. Pertanto, non sono consigliati per ogni transazione, ma solo per le operazioni critiche sui dispositivi che hanno il controllo delle risorse di sicurezza e privacy fisiche o virtuali.
Astratti SDK
Le sezioni Transazioni di lettura, Transazioni di scrittura e Transazioni di chiamata forniscono una panoramica generale delle azioni del modello di interazione eseguite dall'SDK.
Lo sviluppatore che crea un prodotto che utilizza l'SDK Matter typically non esegue chiamate per eseguire direttamente le azioni; le azioni sono astratti dalle funzioni dell'SDK che le incapsulano in un'interazione. Tuttavia, è importante comprendere le azioni IM per fornire all'ingegnere una buona conoscenza delle funzionalità di Matter, nonché un controllo fine sull'implementazione dell'SDK.