Sicurezza delle comunicazioni di sistema integrate

6

Mi sto preparando ad avviare la distribuzione di una rete di sensori incorporati che è collegata a Internet (tramite la rete cellulare) e riporta dati privati su base regolare a un server centrale. Sfortunatamente, il dispositivo non ha né la connettività (latenze elevate) né la potenza di elaborazione per utilizzare SSL, quindi penso di essere lasciato a inventare qualcosa da solo, in violazione della regola n. 1 della crittografia.

Quello che mi è venuto in mente:

Abbiamo essenzialmente tre canali (comandi fuori banda, richieste http su Internet, risposte http), quindi memorizzeremo tre chiavi indipendenti (generate casualmente durante l'assemblaggio) su base per dispositivo.

I dati HTTP sono crittografati come E (iv, chiave, carico utile || H (chiave, payload)) dove E è AES 128 in modalità CBC e H è un HMAC SHA256. Sul lato incorporato iv viene generato come H (ora corrente) e trasmesso in chiaro, insieme all'ID univoco del dispositivo per la selezione della chiave corretta. Non c'è RNG sul microcontrollore, quindi sto facendo il meglio che posso per la flebo. È abbastanza buono?

Poiché i comandi non sono privati ma devono essere autenticati, vengono trasmessi come payload || H (chiave, payload) utilizzando una chiave diversa da richieste o risposte HTTP.

So che ottenere questo diritto è davvero difficile, mi manca qualcosa di ovvio o ho dei dettagli sbagliati?

    
posta John Laxson 28.08.2011 - 19:11
fonte

3 risposte

4

Per vedere cosa hanno fatto gli altri in questo spazio, puoi guardare i seguenti sistemi:

Ecco alcuni punti deboli che ho individuato nel tuo schema (questa è solo una risposta "ho qualche dettaglio sbagliato?", non "cosa dovrei fare?".):

  • Stai utilizzando la stessa chiave per la crittografia e l'autenticazione. Non è una buona idea.

  • Stai usando authenticate-then-encrypt. Ha delle debolezze di sicurezza. Se questi sono un problema nella pratica dipenderà dalle specifiche del tuo formato di pacchetto. Comunque, almeno in alcune plausibili istanze del tuo schema, ci saranno degli attacchi a testo cifrato scelti. Ad esempio, con alcuni schemi di padding sarai vulnerabile agli attacchi oracle di riempimento.

  • Non hai alcuna protezione contro la riproduzione.

Cosa dovresti fare:

  • Utilizza SSL.

  • Oppure, se non puoi usare SSL: segui i consigli di Thomas Pornin o segui le orme di uno dei sistemi che ho citato sopra - e in entrambi i casi assumi un crittografo come consulente per assicurarti di avere giusto.

risposta data 01.09.2012 - 22:09
fonte
5

Vorrei riesaminare il punto di non avere la connettività per usare SSL; Non so con quale frequenza vengono stabilite le connessioni, ma qualsiasi moderno stack SSL che supporti i curriculum imporrebbe solo un paio di pacchetti aggiuntivi di overhead dopo l'iniziale handshake. Per non avere la potenza necessaria per eseguire la crittografia, di nuovo, dovresti seriamente ricontrollare questa ipotesi. Non ho cercato di analizzare il tuo progetto, dal momento che mi attengo alla crittografia basata su standard a tutti i costi, ma dovresti fare una strong argomentazione sul fatto che non hai alcuna necessità fondamentale per le cose che SSL sta facendo. Se non usi SSL, dovrai fare qualcosa per autenticare il tuo peer, e una chiave pre-condivisa statica, se questa è la tua risposta, è una supplica per i guai. Come aggiornerai la chiave se è compromessa?

Usa SSL.

    
risposta data 28.08.2011 - 19:34
fonte
5

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.

    
risposta data 30.09.2011 - 23:13
fonte

Leggi altre domande sui tag