Oggigiorno la comunicazione e l'elaborazione dei dati sono difficilmente concepibili senza considerare gli aspetti della sicurezza. Infatti, i sistemi di comunicazione insicuri stanno rapidamente diventando inaccettabili. La strada è già stata indicata da Internet, con il ben noto protocollo 'http' del 1991 che è stato ampiamente sostituito dalla variante criptata 'https'. Guarda caso, un anno prima dell'http, nel 1990, fu lanciato il sistema KNX con il nome di EIB.
Anche negli edifici, la necessità di una comunicazione sicura non può più essere trascurata. Al momento, nonostante i rapporti sulla manomissione, ci possono essere poche prove concrete di danni reali da parte degli hacker, ma i loro sforzi sono destinati ad aumentare, quindi è necessario contrastare i potenziali pericoli per le infrastrutture tecniche.
Rendere sicuro KNX
In quanto associazione di costruttori, KNX Association si è avvicinata al tema della sicurezza con il concetto ‘KNX Secure'. La specificazione e l'implementazione hanno richiesto diversi anni; una delle ragioni principali è la complessità del protocollo KNX, per il quale l'indirizzamento di gruppo, essenziale per l'intero sistema KNX, è una vera sfida per la crittografia sicura.
All'inizio del 2019, sia il sistema che le specifiche dei test sono stati considerati stabili e sono stati approvati dal Technical Board di KNX Association. Inoltre, KNX Association ha investito molto nell'implementazione della sicurezza in ETS - il software di installazione centrale per KNX. Anche gli strumenti di test per lo sviluppo di dispositivi KNX Secure sono stati estesi di conseguenza, e sono ora disponibili prodotti certificati KNX Secure.
Quindi, ora che KNX Secure è una realtà, vediamo più in dettaglio le sue due varianti, cioè KNX Data Secure e KNX IP Secure.
KNX Data Secure
KNX Data Secure mira a rendere sicura la comunicazione a livello di telegramma. Può essere usato indipendentemente dalla rete KNX sia per la messa in servizio che per la comunicazione runtime.
KNX Association si è posta l'obiettivo della ‘sicurezza fin dall'inizio'. Questo significa che anche il primo download sui dispositivi da parte dell'ETS è criptato fin dall'inizio. A questo scopo, ogni dispositivo viene fornito con un FDSK (Factory Default Setup Key) individuale per il firmware, che l'ETS deve conoscere prima della programmazione. L'informazione della chiave è mappata insieme al numero di serie del dispositivo in un codice QR e stampata sul dispositivo. Il codice può essere scansionato e valutato dall'ETS utilizzando una fotocamera del PC o del portatile o tramite un'applicazione mobile. È possibile anche l'inserimento tramite una tastiera.
Poiché la chiave del dispositivo può essere conosciuta da altri, l'ETS la sostituisce con la 'tool key', cioè una chiave di programmazione. Anche questa chiave viene generata individualmente per ogni dispositivo.
Altre chiavi sono necessarie per i telegrammi di gruppo. Per la massima sicurezza, viene usata una chiave separata per ogni indirizzo di gruppo. La crittografia impedisce il controllo dei dati. Allo stesso tempo, un codice di autorizzazione nel telegramma assicura che solo gli apparecchi autorizzati possano partecipare alla comunicazione.
Un noto attacco ai sistemi è il cosiddetto ‘attacco replay'. L'attaccante utilizza telegrammi che ascolta e rinvia senza essere in grado di interpretarli da solo. Per prevenire questo scenario, ogni telegramma contiene un numero di telegramma che il rispettivo mittente assegna consecutivamente. Il ricevitore può accettare solo telegrammi che hanno un numero più alto dell'ultimo telegramma che ha ricevuto da questa stazione. A causa della lunghezza di 6 byte di questo numero, un overflow è praticamente impossibile e viene interpretato come un errore.
Installazioni di sicurezza miste
Poiché non ci si aspetta che tutti i dispositivi richiesti siano disponibili in breve tempo come variante sicura, è importante che la comunicazione sicura e insicura possano essere mescolate in un'installazione. La proprietà sicura è definita a livello di gruppo. Se due oggetti di gruppo che supportano entrambi la sicurezza sono collegati, l'ETS propone un collegamento sicuro. Tuttavia, se un solo oggetto è in un gruppo senza sicurezza, l'intero gruppo deve comunicare in modo insicuro.
Diversi oggetti di comunicazione in un dispositivo possono avere diverse proprietà di sicurezza. Così è possibile, per esempio, che i telegrammi di commutazione per un attuatore di commutazione siano criptati, ma i messaggi di feedback siano inviati in chiaro per poter essere visualizzati. La sicurezza potrebbe anche essere utilizzata caso per caso per un attuatore per tapparelle. Ciò significa che le tapparelle possono essere controllate senza protezione, mentre gli aprifinestra accettano solo telegrammi criptati.
Un altro scenario è la crittografia solo in segmenti parziali dell'impianto, come un segmento KNX RF, per il quale la crittografia è un requisito importante. Allo stesso tempo, i telegrammi devono poter essere inviati anche ai tradizionali dispositivi KNX Twisted Pair (TP). La soluzione per questo requisito in KNX è il 'Secure Proxy'. Si tratta di un modulo software implementato in un accoppiatore. Nell'esempio precedente, è implementato nell'accoppiatore KNX RF/TP. Il Secure Proxy traduce la comunicazione sicura dal lato radio in telegrammi non sicuri su KNX TP e viceversa. Tuttavia, il Secure Proxy può anche essere implementato negli accoppiatori di linea (TP/TP), per esempio per collegare linee esterne protette a una rete KNX interna non protetta.
KNX IP Secure
KNX IP Secure segue un approccio alternativo, ma si basa sugli stessi metodi di crittografia di KNX Data Secure. KNX IP Secure sfrutta un approccio pragmatico basato sul presupposto che esiste un punto di attacco a livello IP. Mentre si presume che KNX Twisted Pair sia relativamente sicuro in quanto mezzo puramente locale situato nel muro, la comunicazione IP è spesso collegata a Internet e può quindi essere attaccata a distanza.
KNX IP Secure protegge la comunicazione KNX IP mentre la comunicazione su KNX TP rimane non criptata. Il vantaggio principale di questo approccio è che i dispositivi e le installazioni KNX TP esistenti possono continuare ad essere utilizzati senza modifiche. Solo i dispositivi KNX IP, ovvero le interfacce KNX IP e i router KNX IP, devono essere sostituiti.
KNX IP include il protocollo di routing, che è usato per le dorsali IP, ma rappresenta anche la rete KNX IP. D'altra parte, il protocollo di tunnelling è usato per permettere ad un client (ad es. ETS) di accedere ad una linea TP via IP. Mentre i router KNX IP solitamente implementano entrambi i protocolli, le interfacce KNX IP supportano solo la funzione di tunnelling.
Tanto diverse sono le due applicazioni di KNX IP, quanto diverse sono le rispettive estensioni per la sicurezza. Con il protocollo Secure Routing, che è basato su UDP Multicast, viene usata una chiave comune per criptare tutte le comunicazioni di routing KNX IP. Una caratteristica speciale è il contatore di telegrammi durante il routing. Essendo basato sul tempo rappresenta una marca temporale che permette di individuare i telegrammi obsoleti. Il tempo di sistema comune è continuamente sincronizzato tra i dispositivi.
Con il protocollo di tunnelling, il client e il dispositivo KNX IP (server KNXnet/IP) stabiliscono prima un canale sicuro utilizzando il cosiddetto metodo Diffie-Hellmann. Solo allora vengono trasferiti l'ID utente e la password. Una nuova caratteristica di KNX Secure Tunnelling è la possibilità di stabilire la connessione con TCP. Oltre alla possibilità di accedere a una linea bus, il tunnelling permette anche di programmare molto velocemente i dispositivi KNX IP.
KNX Secure dal punto di vista del costruttore
KNX Secure è certamente una sfida per i costruttori. L'espansione dei dispositivi KNX esistenti con KNX Secure non sarà possibile, nella maggior parte dei casi, senza cambiare l'hardware, poiché i requisiti di memoria e potenza di calcolo disponibili aumentano. Anche l'assegnazione e la stampa delle chiavi devono essere implementate come codice QR nella produzione.
Nuovi requisiti sorgono anche per i produttori di software per KNX, per esempio le visualizzazioni. Non è più sufficiente importare o inserire gli indirizzi di gruppo del progetto. Anche la conoscenza delle chiavi utilizzate non è sufficiente per inviare telegrammi di gruppo criptati. Piuttosto, ogni partecipante deve essere reso noto a tutti i dispositivi che deve raggiungere. Attualmente ciò è possibile solo attraverso l'ETS e probabilmente continuerà ad esserlo. Per la maggior parte dei dispositivi sul mercato che non possono essere messi in funzione utilizzando l'ETS, oggi la strada verso un sistema di comunicazione sicuro KNX sarà probabilmente una sfida, anche se gestibile.
L'Ing. Thomas Weinzierl è il CEO di Weinzierl Engineering GmbH, produttore di prodotti KNX e fornitore di una gamma completa di servizi di sviluppo e collaudo di hardware e software.