Matter: architettura, sicurezza e interoperabilità

Matter: lo standard IP che unifica davvero la smart home (e l’IoT domestico)

Matter è uno standard applicativo, aperto e interoperabile, che porta un modello dati comune e un interaction model uniforme sopra reti IPv6 (Wi-Fi, Ethernet, Thread). L’obiettivo: far parlare tra loro dispositivi e piattaforme di brand diversi — in locale, in modo sicuro — riducendo i costi d’integrazione e di manutenzione lungo il ciclo di vita del prodotto. A livello di rete, discovery e controllo avvengono su DNS-SD/mDNS, con operazioni esposte da un set di cluster standard (attributi, comandi, eventi) e sessioni sicure end-to-end. Il servizio pubblicato per i nodi operativi è _matter._tcp e la porta ufficiale è 5540 (TCP/UDP).

Dal 2024 alla metà 2025, lo standard ha esteso in modo deciso i casi d’uso: Intermittently Connected Devices (ICD) più efficienti, energy management end-to-end e — con la release 1.4.2 (agosto 2025) — un focus su affidabilità/stabilità, scene certificabili e onboarding solo Wi-Fi (senza BLE) per prodotti esclusivamente Wi-Fi. L’adozione pratica dipende dai singoli ecosistemi, ma la direzione è chiara.

Perché Matter conta per chi progetta prodotti

• Interoperabilità multi-ecosistema: stesso linguaggio applicativo verso Apple, Google, Amazon, SmartThings e Home Assistant.
• Riduzione varianti firmware: lo stesso device type e gli stessi cluster valgono per più piattaforme.
• Onboarding standard: pairing prevedibile (QR/manual code), discovery DNS-SD/mDNS, credenziali operative comuni.
• Sicurezza end-to-end e OTA standardizzato: meno soluzioni ad-hoc, più manutenzione “di piattaforma”.

Architettura in 3 strati

1) Trasporto IP

Matter gira su IPv6 (Wi-Fi, Ethernet, Thread). Le sessioni applicative possono usare UDP con Message Reliability (ritrasmissioni, ack, anti-duplicati) o TCP dove opportuno. La multicast IPv6 è cruciale per gruppi e scene.

2) Service Discovery

Il discovery avviene tramite DNS-SD/mDNS (RFC 6763). In fase operativa i nodi pubblicano il servizio _matter._tcp e dialogano sulla porta ufficiale 5540 (TCP/UDP) registrata presso IANA.

3) Data Model & Interaction Model

Il Data Model definisce node, endpoint, cluster (attributi, comandi, eventi) e device type. L’Interaction Model standardizza le operazioni Read, Write, Invoke, Subscribe (anche in multicast per azioni di gruppo). Introduzioni utili: Google Developers – Device Data Model e Silicon Labs – Matter Fundamentals.

Sicurezza: catena di fiducia, fabric e ACL

Commissioning iniziale

Il pairing usa PASE (SPAKE2+ con passcode da QR/NFC o codice manuale) per creare il canale sicuro e trasferire i parametri iniziali. Il commissioner verifica l’identità del device tramite Device Attestation (catena DAC → PAI → PAA e Certification Declaration). I certificati root PAA pubblici risiedono nel Distributed Compliance Ledger (DCL).

Operatività

In esercizio, le sessioni sono CASE (mutua autenticazione a certificati) e il nodo entra in una fabric (dominio di sicurezza). Il multi-admin consente a uno stesso device di far parte di più fabric/ ecosistemi. Approfondimenti pratici su attestazione: Silicon Labs – Device Attestation e DigiCert – Issuing CSA Matter Certificates.

Operatività: CASE, fabric e multi-admin

In esercizio le sessioni sono CASE (mutua autenticazione con certificati); la fabric è il dominio di sicurezza che raggruppa nodi, ID e trust anchor condivisi. Un device può appartenere a più fabric (multi-admin) e quindi convivere su più ecosistemi (es. Home, Alexa, Google, SmartThings) senza firmware diverso.

Autorizzazioni: Access Control Cluster (ACL)

I permessi sono dichiarativi e per-cluster: View, Operate, Manage, Administer (privilegi standard). In assenza di privilegio adeguato un’operazione è negata.

Rete e discovery: note progettuali

• mDNS/Multicast: assicurarsi che 5353/UDP e la multicast IPv6 non vengano filtrate su LAN/VLAN (IGMP snooping troppo aggressivo può rompere il discovery).
• Porta 5540: aprire 5540 TCP/UDP tra controller e device per il traffico Matter operativo (IANA).
• IPv6 locale: è sufficiente link-local per le operazioni in LAN; non serve IPv6 pubblico.

Wi-Fi, Thread, Ethernet: quando scegliere cosa

Wi-Fi/Ethernet: throughput alto e bassa latenza (luci evolute, bridge, grandi elettrodomestici). Thread: mesh IPv6 a basso consumo per sensori/attuatori a batteria; richiede un Thread Border Router per interfacciarsi all’IP di casa (molti hub consumer lo integrano).

Novità recenti dello standard

• Matter 1.4: estensioni per energy management (nuovi device type come pannelli solari, batterie, pompe di calore, scaldacqua) e miglioramenti multi-ecosistema. Fonte: CSA Newsroom.
• Matter 1.4.2: focus su affidabilità/stabilità e commissioning solo Wi-Fi tramite Wi-Fi USD (senza obbligo BLE), oltre a scene più coerenti tra ecosistemi. Fonte: CSA Newsroom.

Dispositivi, cluster e funzioni “di sistema”

• Cluster applicativi: On/Off, Level/Color Control, Thermostat, Door Lock, Window Covering, Robot Vacuum, ecc.
• Gruppi & Binding: multicast efficiente per azioni simultanee (es. tutte le luci della stanza) e legami logici controller→device.
• Scene: snapshot di stato multi-dispositivo con comportamento coerente e certificabile nelle release recenti.
• Bridge: ruolo per esporre dispositivi Zigbee/Z-Wave/BLE Mesh come endpoint virtuali Matter.

Aggiornamenti OTA standardizzati

Lo OTA è parte integrante della specifica: un Requestor può individuare un Provider Matter, scaricare un’immagine compatibile e installarla in sicurezza. Alcuni hub possono fungere da OTA Provider all’interno della fabric. Documentazione di riferimento nelle specifiche e nei portali vendor (CSA, Silicon Labs, NXP, ecc.).

Produzione e certificazione: cosa serve davvero

• PKI di produzione: generazione dei DAC univoci, PAI/PAA del vendor (o CA accreditata) allineati alle policy CSA; pubblicazione artefatti e CRL nel DCL.
• Certification Declaration (CD): rilasciata a valle della conformità; va gestita come artefatto aggiornabile.
• Compliance & test: PICS/PIXIT, test suite CSA, prove multi-ecosistema e verifica dei profili energetici dove applicabile.

Checklist di progettazione (senza lock-in di piattaforma)

1. Device type & Data Model: definisci endpoint/cluster (obbligatori + opzionali che danno valore reale).
2. PKI: pianifica PAA/PAI/DAC, gestione chiavi (idealmente in secure element) e processi di provisioning.
3. Rete: abilita mDNS (5353/UDP), multicast IPv6 e 5540 TCP/UDP sulla LAN e sulle eventuali VLAN.
4. ICD/Power: per batteria, usa finestre di check-in, report on-change e tempi di idle lunghi.
5. OTA: integra da subito l’OTA Matter per ridurre costi di field update e support.
6. Bridge & migrazione: se hai base installata Zigbee/Z-Wave, valuta un bridge Matter per transizioni graduali.

Glossario essenziale

Fabric

Dominio di sicurezza con CA, credenziali operative (NOC) e identificatori condivisi. Un device può appartenere a più fabric.

PASE / CASE

Sessione di commissioning (passcode SPAKE2+) / sessione operativa (certificati) tra nodi Matter.

DAC / PAI / PAA

Catena di attestazione del device. I root PAA pubblici sono nel DCL; la CD attesta la conformità del prodotto.

IM (Interaction Model)

Read, Write, Invoke, Subscribe: le operazioni standard sul Data Model.

ICD

Intermittently Connected Device: dispositivi a connessione intermittente con politiche di risveglio ottimizzate.

Riferimenti e approfondimenti

• CSA – Build with Matter
• RFC 6763 – DNS-SD  |  IANA – Porta 5540
• Google – Matter Device Data Model
• Silicon Labs – Matter Fundamentals
• CSA – Distributed Compliance Ledger
• CSA – Annuncio Matter 1.4  |  CSA – Aggiornamento 1.4.2
• NXP – Energy Management in Matter 1.4

Nota: questo articolo è pensato come guida tecnica introduttiva. Per dettagli implementativi (SDK e piattaforme), rimandiamo alla documentazione dei vendor e alla specifica ufficiale Matter.

Conclusione

Matter non è “un altro protocollo radio”, ma un linguaggio applicativo comune su IP che normalizza discovery, sicurezza, modello dati e aggiornamenti. Per chi sviluppa prodotti, significa meno varianti firmware, onboarding prevedibile, integrazione multipiattaforma e una roadmap chiara su energia e scalabilità. Con le ultime release (1.4 e 1.4.2), lo standard sta maturando proprio dove serve: affidabilità, gestione di scenari complessi (scene, gruppi, energy) e semplificazione dell’onboarding.
Se vuoi, in un secondo momento possiamo trasformare questo articolo in una guida pratico-ingegneristica (con diagrammi e checklist operative per certificazione/PKI, reti, ICD e OTA) oppure in un whitepaper scaricabile con infografiche.