È insicuro chiedere l'attuale nonce dal server?

2

Sto sviluppando un'applicazione incorporata che fornisce informazioni tramite HTTP al mio server web. Queste consegne sono protette da un hash

H(secret : data : nonce)

dove il segreto è condiviso tra le due entità e i dati sono i dati che vengono consegnati. Il nonce serve per proteggere dagli attacchi di replay.

Il mio problema è che il dispositivo incorporato non ha idea dell'ora corrente e non posso memorizzare alcun dato su di esso. Quindi ad ogni riavvio del dispositivo il nonce parte da 1, il che non è molto buono.

Sto pensando di usare un contatore come nonce e poi chiedere al server web su ogni avvio quale fosse l'ultimo nonce usato e usarlo come punto di partenza. Nella mia testa questo sembra sicuro poiché il nonce non è un segreto, cioè non ha senso non dirlo al mondo. Ma ci sono delle implicazioni sulla sicurezza che ho trascurato?

    
posta m__ 09.09.2013 - 21:59
fonte

1 risposta

4

Prima di tutto. Il tuo "hash" è in realtà un MAC , e uno scarso uno perché non riesce a garantire la sicurezza con le solite funzioni di hash (SHA-1, SHA-256 ...). Cerca l' attacco di estensione della lunghezza per i dettagli. In sostanza, se si desidera un MAC, utilizzare un MAC appropriato, ad es. HMAC . Ogni chiamata HMAC richiede una coppia di invocazioni della funzione hash sottostante, una delle quali è in input breve, quindi dovrebbe essere accettabile per il tuo dispositivo.

Supponendo un MAC corretto, devi considerare a cosa serve il nonce. Il nonce protegge dagli attacchi di replay solo finchè:

  • Il server controlla che il valore nonce sia quello che si aspetta (in modo equivalente, il server ricalcola il MAC utilizzando il suo valore nonce noto e il MAC corrisponderà solo se quel nonce è lo stesso di quello utilizzato nel dispositivo) .
  • I valori nonce sono non prevedibili .

Le dinamiche normali sono le seguenti:

  • Il client si connette al server con qualche tipo di connessione.
  • Il server restituisce un valore nonce appena generato.
  • Il client calcola il MAC e restituisce i dati e il valore MAC associato al server.
  • Server controlla il valore MAC.

Nel contesto HTTP, ciò significa un paio di richieste. Nominalmente, le richieste HTTP sono indipendenti l'una dall'altra, e quindi possono capitare di apparire sulla stessa connessione (con "keep-alive"), o usare connessioni distinte; sul lato server, se viene utilizzato il bilanciamento del carico, le richieste possono andare a front-end distinti. Questo potrebbe rendere le cose più difficili per te. Il punto critico è che il server deve accettare un determinato valore nonce solo una volta . Se è stata ricevuta una risposta, usando un valore MAC calcolato con un nonce specifico, allora il nonce è "bruciato" e NON DEVE essere accettato di nuovo.

Ora per la non prevedibilità: supponiamo che il valore nonce sia, ad esempio, un contatore mantenuto sul server (utilizzando l'ora corrente sarebbe equivalente). Ad un certo punto, il valore del contatore è C , quindi l'attaccante può prevedere che qualche tempo dopo sarà C + 100 (o C + 100000 o qualsiasi altra cosa). Tale utente malintenzionato potrebbe intercettare una connessione tra il dispositivo e il server e inviare il valore nonce C + 100 al dispositivo. Il dispositivo, che ritiene di parlare con il server originale, invierà un pacchetto di dati contenente un valore MAC corretto per nonce C + 100 . L'attaccante registra le risposte. In un secondo momento, quando il contatore del server raggiunge C + 100 , l'utente malintenzionato si maschera come dispositivo e invia la risposta registrata.

Pertanto, un nonce prevedibile consente all'autore dell'attacco di raccogliere un pacchetto di dati (valido) dal dispositivo e inviarlo al server nel momento che preferisce. L'utente malintenzionato non sarà in grado di creare un pacchetto di dati puramente sintetico, ma potrà decidere quando il pacchetto raggiungerà il server. A seconda del contesto esatto, questo può o non può essere un problema; è più sicuro, tuttavia, impedire che tali eventi si verifichino del tutto.

Questo riassume quanto segue:

  • Non è un problema far sapere alle persone quali valori nonce si usano.
  • MA ogni nonce deve essere usato una sola volta. Se due client si connettono simultaneamente, ognuno ottiene il proprio nonce.
  • È molto meglio che i nonces non sono prevedibili. Genera un nonce come una sequenza di almeno 16 byte con un PRNG crittograficamente protetto .
  • Se il tuo dispositivo ha abbastanza succo per questo, potresti voler passare a SSL (ad esempio HTTPS). All'interno del tunnel SSL, il dispositivo può semplicemente utilizzare Autenticazione di base , cioè mostrare il "segreto" così com'è, poiché il tunnel è crittografato e correttamente eseguito, SSL garantisce che il dispositivo sia convinto a parlare con il server giusto.

SSL è più pesante (non proprio per la CPU, più per la larghezza di banda e la latenza della rete: un handshake SSL è di due round-trip, e poi uno in più per la richiesta stessa) ma è abbastanza grande per convincere le persone sulla sicurezza. L'uso di SSL ti consente di risparmiare un sacco di sforzi quando si tratta di dimostrare ad alcuni revisori che hai fatto le cose correttamente. Inoltre, ti dà riservatezza, che potrebbe essere una buona cosa nel tuo caso.

    
risposta data 09.09.2013 - 22:21
fonte

Leggi altre domande sui tag