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.