Mentre lo leggevo, la tua domanda si riduce a: è sicuro usare la stessa chiave sia per la crittografia simmetrica di alcuni dati, sia per un MAC su altri dati?
È possibile costruire un esempio (un po 'forzato) in cui tale uso non è sicuro. Ad esempio, la crittografia simmetrica potrebbe essere una cifratura di flusso personalizzata in cui il flusso consiste in valori HMAC calcolati su un valore successivo di un contatore; in tal caso, il MAC che utilizza la stessa chiave potrebbe interagire con la crittografia e le informazioni sulle perdite. Tuttavia, con algoritmi di crittografia "normali" e HMAC, i rischi sono bassi. Lo stesso non si può dire se il MAC fosse CBC-MAC : utilizzando la stessa chiave per la crittografia in modalità CBC, e per CBC-MAC, è un peccato mortale.
In generale , è preferibile che ogni singola chiave abbia uno scopo univoco. Il metodo generico, qui, è di avere una "chiave master" K e derivare da quella chiave, utilizzando un Key Derivation Function , una chiave per la crittografia e un'altra chiave per il MAC. In pratica, questo può essere semplice come hashing K con SHA-256 e dividere l'uscita a 256-bit in due metà a 128-bit; la prima metà deve essere utilizzata per la crittografia, la seconda metà per il MAC. Questo è sicuro sulla base di alcune assunzioni di one-wayness parziali su SHA-256, ipotesi abbastanza ragionevoli.
Lo stesso SSL usa il proprio KDF, che viene chiamato, nella specifica SSL, il "PRF" .
Se la chiave segreta è un po 'debole, cioè è derivata da una password , gli hacker che osservano lo scambio possono usare ciò che vedono per eseguire un attacco di dizionario offline, cioè provare potenziali password; questo è "offline" nel senso che gli aggressori lo fanno sulle loro macchine e non devono parlare con il server onesto per ogni tentativo. Gli attacchi del dizionario offline sono un problema. L'esecuzione del protocollo all'interno di SSL è un buon modo per contrastare tali intercettazioni.
Se non c'è SSL, gli stessi aggressori potrebbero attivarsi e modificare i dati crittografati restituiti dal server. Pertanto, il sistema di crittografia dovrebbe includere anche il proprio MAC. La combinazione di MAC e crittografia è nota per essere complicata, quindi le modalità che svolgono correttamente il lavoro (come GCM ) sono altamente raccomandabili .
Più aggressivamente, gli attaccanti potrebbero anche commettere errori falsi. Se invii il tuo GET su un semplice HTTP, un utente malintenzionato attivo potrebbe intercettarlo e restituire una risposta 404 falsa: poiché non vi sono dati crittografati in un 404 (in effetti, il punto del 404 è dichiarare che non ci sono dati) , il client non ha nulla da verificare e non può rifiutare il messaggio 404 come falso. A seconda di cosa usi il tuo protocollo, questo potrebbe causare problemi di sicurezza. Per proteggersi dagli aggressori attivi, tutte le risposte dal server devono essere autenticate, comprese risposte negative (404). Ma, a quel punto, sei sul punto di reinventare SSL ...
Allo stesso modo, un utente malintenzionato attivo può restituire una vecchia risposta dal server. Supponiamo che a un certo momento il blocco dati D 1 sia stato memorizzato sul server e possa essere ottenuto con un GET. Successivamente, il blocco dati viene aggiornato con D 2 . Tuttavia, la chiave non è cambiata e la richiesta GET dal client è sempre la stessa. Un attaccante attivo può sostituire D 2 dal server con una copia di D 1 , come precedentemente intercettato.
Questo può essere evitato usando un nonce - un client nonce, inviato dal client; il server quindi deve calcolare dinamicamente un MAC su ciò che restituisce e l'input MAC deve includere il nonce del client. A quel punto:
- il protocollo non è più leggero come si poteva sperare;
- questo sembra davvero un SSL fatto in casa.
Riepilogo: non è facile sovraperformare SSL. SSL è relativamente complesso, ma quella complessità è (soprattutto) intrinseca alla durezza del problema in questione. Un protocollo di comunicazione che resiste a imitazioni, alterazioni e attacchi di replay, dovrà includere un numero di elementi crittografici finemente sintonizzati e non sarà sostanzialmente più semplice o economico da gestire di SSL.
Se puoi concordare che il tuo client e server condividano una chiave segreta ad alta entropia comune, quindi suite di crittografia TLS PSK ti darà buone prestazioni e la minore complessità possibile (nessun certificato, nessuna crittografia asimmetrica).