Nota introduttiva: quando parlo di sensore o di attuatore non mi riferisco, in realtà al VERO sensore o attuatore, ma al modulo che interfaccia un sensore da antifurto "classico" (per es. con uscita a 4 fili, per un semplice contatto aperto/chiuso) al bus di OpenAlarm e quindi alla/e centralina/e. In questo modo non abbiamo da preoccuparci della certificazione del sensore vero e proprio. In questo modo si riducono anche drasticamente i costi, dato che, almeno fino al livello 3, potrebbe esserci un solo concentratore per ogni stanza e categoria, installato come se fosse una centralina tradizionale... e potrebbe anche esserlo.

Ogni sensore deve essere dotato di "intelligenza" per poter interpretare i messaggi a lui diretti.
Salvo buone ragioni contrarie, i nodi sensori dovrebbero venire gestiti in "polling" dalla/e centralina/e o da nodi "concentratori", o comunque devono in ogni caso "dire qualcosa" ogni tot. In questo modo non serve un sistema di controllo dei "tagli". Inoltre, dato che ogni nodo deve essere stato "presentato" alla centralina e comunica con essa tramite una chiave diversa da ogni altro nodo, non si corre neanche il rischio che un attaccante possa "sostituirsi" ad un nodo per disattivarlo senza che la centralina se ne accorga.
Ogni nodo dovrebbe poter gestire almeno due chiavi diverse, così da poter comunicare con almeno due centraline in modo indipendente. Sensori particolarmente economici o per sistemi a bassa sicurezza possono anche gestire una sola chiave. Sistemi di semplice home automation possono prevedere di NON usare alcuna crittografia. In questo caso, ovviamente, il sistema non sarà minimamente adatto come antifurto, dato che basterebbe intercettare il bus per sostituirsi ad un sensore/attuatore !!!

Ogni nodo deve avere a bordo un generatore di entropia crittograficamente sicuro. Will Ware indica un sistema molto interessante.
È piuttosto robusto, economico e sicuro. Se nel pool dell'accumulatore di entropia si fanno entrare due canali (in un chip sono disponibili 6 inverter), l'accumulo è molto rapido. Purtroppo (DA VERIFICARE) probabilmente usando tutti e 6 gli inverter disponibili i bit casuali possono risultare fortemente correlati. Da valutare anche l'uso di uno o due canali A/D (di cui considerare il solo lsb.

I sensori possono essere soggetti a vari attacchi:

• Man-in-the-middle: un attaccante cerca di escludere il sensore (già installato), anche "vampirizzando" il bus;
• Setup-sniff: l'attaccante (in questo caso l'installatore) si inserisce sulla linea di programmazione del sensore (durante l'installazione);
• Firm-backdoor: il produttore dei sensori (o delle centraline) inserisce una backdoor per poterli escludere a piacere una volta installati;
• Taglio dei cavi: l'attacco classico a cui nessun antifurto deve cedere... Se i cavi vengono tagliati, l'allarme scatta;
• Active-node: l'attaccante "inietta" segnali sul bus per tentare di impedire il normale funzionamento del sistema;
• Side-channel: famiglia di attacchi che mira a determinare le chiavi usate tramite l'analisi delle temporizzazioni, dell'assorbimento e di tutti quei parametri "esterni" e normalmente ignorati
• Cattura di un sensore: un sensore viene "catturato" dall'attaccante che può così "aprirlo" anche fisicamente (p.e. rimuovendo la plastica del micro ed usando dei microprobe per leggere il chip direttamente)
• Altri attacchi: scatenate la fantasia...

Ovviamente il sistema deve essere ingegnerizzato in modo da "parare" (o rallentare il più possibile) almeno tutti questi attacchi. Come potete intuire la soluzione non è banale. In particolare sono particolarmente critiche tutte quelle situazioni in cui, per il valore degli oggetti da proteggere, non ci si possa fidare pienamente dell'installatore o del produttore. Probabilmente per queste situazioni non esistono soluzioni puramente tecniche ma solo sociali (per es. si fa installare l'impianto a due ditte diverse, o ci si programmano "in proprio" i chip -- il mio consiglio, per un impianto di livello 4, è di usare un sistema doppio, con produttori ed installatori diversi, ed almeno due differenti analisi dei rischi). Come molto spesso accade nel campo della sicurezza, il sistema finale è frutto di una serie di compromessi tra costi, sicurezza, fiducia, aspetti tecnici ed altri possibili fattori.

Usando l'autenticazione dei messaggi dai sensori si possono soddisfare quasi tutti i punti, tranne la firm-backdoor (che per essere evitata richiede ridondanza almeno doppia, usando prodotti di almeno due produttori diversi e non collegati, oppure l'utente finale deve effettuare direttamente la programmazione dopo aver analizzato per bene il codice), il side-channel-attack e la "cattura" di un sensore.

Onde evitare side-channel-attack, ogni modulo di comunicazione deve essere montato, insieme al suo generatore di numeri casuali e ad una buona sezione di filtraggio dell'alimentazione, all'interno di un involucro schermante. Così si riducono praticamente a zero le possibilità di attacchi TEMPEST e power analysis.
Inoltre la schermatura può rallentare (anche se di poco), un attacco successivo alla cattura del modulo di comunicazione.

Per eliminare la possibilità che un attaccante acquisisca informazioni utili catturando un modulo di comunicazione, le chiavi usate devono venire variate periodicamente (ma non troppo rapidamente onde evitare l'usura delle EEPROM). Dato che se un modulo viene "catturato" deve anche venire rimosso dal circuito (senza poter essere "emulato") per un tempo piuttosto lungo (minimo alcuni minuti: da una rapida valutazione informale fatta da Sergei Skorobogatov e basata sulla sua esperienza coi PIC di Microchip, servono dai 10 minuti alle 10 ore, a seconda della preparazione e dei mezzi dell'attaccante), può essere sufficiente che gli altri nodi lo escludano (segnalando l'anomalia) se non riescono a comunicare per 30 secondi o più. In seguito all'esclusione, il modulo deve essere ripresentato alla centrale. Non bisogna fidarsi troppo della "tamper resistance" dichiarata dalle case, dato che non è troppo difficile (vedi anche un altro lavoro di Sergei) aggirarla anche con strumenti non eccessivamente costosi, e quindi alla portata di molti.
Se a questo si aggiunge il fatto che l'architettura di OpenAlarm è pubblica (ricordate? niente "security by obscurity!), il lavoro di un attaccante è ulteriormente semplificato. Per ridurre gli inconvenienti dell'usura della EEPROM interna verrebbe "naturale" (almeno è la prima cosa a cui io ho pensato) usare una memoria esterna (in cui, ovviamente, la chiave "temporanea" viene criptata con una permanente nota al solo "nodo")... Peccato che questa soluzione sia attaccabile: la chiave permanente è memorizzata nella memoria interna, e quindi l'anello debole è sempre la ridotta tamper resistance! Una volta ottenuta la chiave permanente, un attaccante può sostituire agevolmente il nodo! L'unico vantaggio ottenibile è una sensibile riduzione del costo al momento del wear-out della EEPROM (è pensabile un sistema che permetta di sostituire la EEPROM esterna anche a nodo inserito).
Un altro sistema può essere il conservare la chiave solo in RAM, prevedendo una batteria (o un grosso condensatore) sul modulo, o un "carrier" su cui inserire i moduli nel tempo tra l'inizializzazione e la messa in servizio. Usando il carrier si può montare un condensatore più piccolo (e quindi economico) sul modulo, dato che poi l'alimentazione verrà fornita dalla batteria del carrier. NON bisogna però fidarsi del fatto che in assenza di alimentazione la RAM si cancella: abbassando la temperatura i dati rimangono ben leggibili anche per ORE (mitico Sergei!).

Se l'utente è disposto a non perdere di vista i moduli inizializzati fino alla loro messa in servizio, il tempo di permanenza sul carrier può essere prolungato a piacere: è infatti l'utente stesso (parte interessata al non-tampering) che vigila sul key material, impedendo che un attaccante (perfino l'installatore) possa aprire un nodo per duplicarlo. Dopotutto, perfino le certificazioni militari di sicurezza, a determinati livelli, mi risulta che prevedano delle guardie a sorvegliare sistemi che, altrimenti, sarebbero attaccabili. E nel caso dei militari, chi sorveglia spesso NON è particolarmente interessato a ciò che sta sorvegliando...

Per l'implementazione dei sensori dovrebbe essere sufficiente il PIC 16F87 (4Kword programma, 256byte EEPROM, 368byte RAM, 16 I/O, 1.84€) o il PIC 16F88 (come l'87, ma con 7 canali A/D, 1.97€) se riesco ad ottimizzare D-H per non occupare più RAM di quella disponibile (oppure a non utilizzarlo del tutto...), altrimenti bisogna passare ai PIC18F2525 (24Kword prog, 1024 byte EEPROM, 3968 byte RAM, 25 I/O con max 10 A/D, 4.63€) o PIC18F4620 (48Kword prog, 1024 byte EEPROM, 3968 byte RAM, 6.30€).
I costi sono presi da MicrochipDirect per l'acquisto di un singolo chip e servono esclusivamente come indicazione "spannometrica".
Usare i 16Fxx comporterebbe comunque l'uso di un modulo di 512bit, invece usando il 18f2525 si può utilizzare un modulo di 1024 (o più) bit, con notevole incremento della sicurezza (l'attacco potrebbe infatti essere portato offline, quindi 512 bit potrebbero essere troppo pochi per reggere alcuni anni!). Per la centralina sarà invece probabile dover ricorrere a micro più potenti, come gli ATmega di Atmel, oppure ad una memoria esterna tipo la 24LC512 (64Kx8) per conservare le chiavi di tutti i nodi (ovviamente criptate!) [non se si usa il 18F2525].

Molto interessante può essere anche l'AT90SC144144CT di AVR, ma oltre a non aver trovato informazioni riguardo il costo, dispone di due soli pin di I/O, usati per comunicare con l'esterno (nasce come controller per smart card, quindi dovrebbe essere meglio difeso da attacchi [semi]invasivi), e per l'uso in OpenAlarm richiederebbe per lo meno un I/O expander. Le caratteristiche sono comunque molto interessanti, quindi vale la pena di esaminarlo meglio, anche perché con 144K di flash lo si può programmare in C senza particolari acrobazie...

Ogni modulo dovrebbe includere un header ICD/Jtag/... per permettere la riprogrammazione "al volo" del firmware caricato nel microcontrollore e soddisfare anche i più paranoici -- eventuali prodotti di terzi dovranno includere le specifiche necessarie per realizzare un firmware alternativo, o il nodo non sarà "marchiabile" come compatibile.