In primo luogo, dovresti definire con precisione quale tipo di attacco cerchi di difendere:
- Hai paura degli aggressori che spiano i messaggi scambiati tra il sensore e il server e apprendi il contenuto dei messaggi?
- Hai paura degli aggressori che impersonano il server e parlano al sensore come se fossero il server?
- Hai paura degli aggressori che impersonano il sensore e invii richieste false al server?
- Hai paura degli aggressori che rilasciano, duplicano, rieseguono e riordinano i messaggi tra client e server?
Un protocollo leggero solo simmetrico che copre tutto quanto sopra - in una certa misura - assomiglia a questo:
- Per ogni canale di comunicazione tra il sensore e il server, ci sono due tasti simmetrici che conoscono sia il server che il sensore, uno per i dati inviati dal server al sensore e uno per i dati inviati dal sensore al server .
- Ogni messaggio inviato dal server o dal sensore è crittografato con AES in modalità EAX .
- La modalità EAX richiede un IV non ripetuto; il sensore e il server useranno i contatori .
- Ogni messaggio contiene l'IV (valore contatore) per quel messaggio, seguito dalla crittografia AES-EAX del messaggio.
- Per ogni canale di comunicazione, il sensore memorizza il valore corrente del contatore per il messaggio che invia e il IV dell'ultimo messaggio ricevuto dal server su quel canale.
- Quando invia un nuovo messaggio, il sensore incrementa il suo contatore (per quel canale), memorizza il nuovo valore, e allora (solo allora) usa il nuovo valore come IV per AES-EAX.
- Quando riceve un messaggio dal server, il sensore controlla che il nuovo messaggio usi un IV che è strettamente maggiore dell'ultimo ricevuto dal server; il sensore memorizza quel nuovo IV e poi (solo allora) decrittografa ed elabora il messaggio dal server.
- Il server utilizza le stesse tecniche del sensore (contatore per i messaggi inviati, IV salvato dall'ultimo messaggio dal sensore e così via).
Supponendo che i contatori inizino a 0, ciò significa che il primo messaggio che il sensore invierà userà 1 come IV; il secondo messaggio utilizzerà 2 e così via. Allo stesso modo per i messaggi inviati dal server. Ciò consente al server e al sensore di rilevare messaggi riprodotti, messaggi fuori servizio e messaggi mancanti; quello che dovrebbero fare in questo caso dipende da te decidere.
Su EAX: la combinazione di crittografia e MAC insieme a una determinata chiave non è completamente semplice. Il riutilizzo della stessa chiave per la crittografia e il MAC è, teoricamente, rischioso. Una modalità di crittografia autenticata come EAX si prende cura dei minimi dettagli. Come bonus, l'EAX non ha bisogno di IV uniformemente casuale e imprevedibile, come fa CBC; richiede solo che i valori IV non vengano mai ripetuti (per una data chiave), quindi un contatore va bene - purché sia possibile memorizzare il valore IV corrente in modo resiliente, e farlo al momento giusto. Fai attenzione a un attaccante che spegne il sensore per forzare un ripristino IV!
Sui tasti: ho parlato qui dei canali bidirezionali. Hai bisogno di una chiave per direzione del canale. Ciò significa due chiavi per la cosa HTTP (una per le richieste, una per le risposte) e una chiave per il canale di comando, assumendo che sia unidirezionale (comandi dal server al sensore, nessuna risposta dal sensore). Se la memorizzazione di tre chiavi a 128 bit è problematica, è possibile memorizzare una chiave singola a 128 bit (una "chiave master") e ricostruire dinamicamente le tre chiavi da quella, con un funzione di derivazione della chiave . Dato che ci si trova in un ambiente vincolato e EAX utilizza solo AES, suggerisco di utilizzare AES anche per questo: utilizzando la chiave master come chiave, criptare tre valori costanti fissi (ad es. "0", "1" e "2") con un invocazione AES singola grezza per ciascuna; questo produrrà tre blocchi a 128 bit che andranno bene come le tue chiavi di canale.
In caso di resistenza alla manomissione: suppongo che i sensori saranno distribuiti "sul campo", quindi un utente malintenzionato può riuscire a catturare un sensore, aprirlo e quindi cercare di recuperare il suo contenuto logico. A meno che il sensore non sia appositamente indurito contro la manomissione (come sarebbe una smartcard), ciò significa che l'attaccante sarà in grado di apprendere i tasti del sensore e, da quel momento, "emulerà" il sensore come visto dal server. Come minimo, ogni sensore implementato dovrebbe avere le proprie chiavi e il server dovrà conoscere le chiavi di tutti i sensori implementati.