Quale autenticazione alla fine del protocollo Secure Remote Password?

"Quante di queste concatenazioni aumentano effettivamente la sicurezza?"

Per sicurezza presumo tu intenda la riservatezza di K.

K è protetto non inviandolo direttamente. Ovviamente se si invia K come testo normale su un canale non sicuro, questo verrà intercettato e qualsiasi crittografia che utilizza K sarà compromessa.

K potrebbe essere inviato crittografato, ma ciò richiederebbe un'altra chiave e non ci porterebbe da nessuna parte.

Quindi il protocollo invia una versione hash di K. Gli hash possono essere sconfitti usando la forza bruta o gli attacchi da tavolo arcobaleno. Se è stato inviato H (K), un attacco riuscito su H (K) può rivelare K all'attaccante. Poiché potrebbero esserci collisioni per un hash, un attacco riuscito su H (K) può produrre un valore diverso da K. L'aggiunta di dati di input a un hash rende più difficile attaccare con successo l'hash perché c'è un dominio di valori più ampio da tentare. Più grande è l'input per l'hash, più difficile è attaccare con successo. Quindi la risposta è che ogni concatenazione aumenta la sicurezza.

"Immagino che sarebbe altrettanto sicuro sostituire uno XOR con la concatenazione, per esempio."

Non conosco lo scopo dello XOR. Ci sono debolezze in SHA1 e sospetto che lo XOR di H (N) e H (g) abbia lo scopo di mitigare la debolezza. Penso che poiché K è un hash di una funzione di B, g, x, a, u, e N che g e N sono hash e XORed per impedire che alcuni pattern colleghino parti dei dati di input. Teoricamente vorrai inserire il maggior numero possibile di input nella funzione hash e XORing due valori riduce la dimensione dei dati di input rispetto alla concatenazione di due valori. Poiché N e g sono pubblicamente noti, XOR non sta tentando di proteggere quei valori in caso di un attacco riuscito sull'hash.

"quanta libertà devo modificare senza ridurre la sicurezza?"

Non è possibile dire intuitivamente quando una modifica all'ordine o all'operazione migliorerà o ridurrà la sicurezza. L'ipotesi di sicurezza è che qualsiasi modifica ridurrà la sicurezza. Prendi nota della frequenza degli annunci sui cambiamenti negli algoritmi che migliorano la sicurezza rispetto alla frequenza degli annunci sugli algoritmi di violazione degli attacchi. Migliorare la sicurezza dell'algoritmo è difficile. Leggi Come rompere MD5 e altre funzioni di hash , e poi trova gli errori fatti dagli autori. Le condizioni sufficienti di MD5 per MD5 non sono sufficienti è almeno un documento critico sui primi risultati dei lavori.

Alla fine di SRP, client e server sono implicitamente autenticati l'uno con l'altro. "Implicito" significa: "Non so se ho parlato con qualcuno che conosce davvero il segreto condiviso, ma so che conosce la chiave simmetrica che ho appena ricevuto dal protocollo solo se conosce il segreto condiviso". Se vuoi assicurartene, sfida il peer: usa la chiave simmetrica.

Ora non è così facile come sembra. In particolare, un aggressore potrebbe provare a far parlare una macchina a se stessa. Per garantire la sicurezza, si devono derivare diverse chiavi simmetriche da quella prodotta da SRP: una chiave per crittografare da client a server, un'altra chiave distinta da server a client. E anche un paio di chiavi per i controlli di integrità. Questo è difficile da ottenere, quindi è altamente consigliato usare un protocollo in cui tutti questi dettagli sono stati dolorosamente sintonizzati attraverso anni di attacchi e contrattacchi, ovvero TLS. Ho parlato di RFC 5054 ? TLS include i messaggi Finished che sono, fondamentalmente, le sfide di cui sto parlando. Quando una macchina ha ricevuto un messaggio Finished dal peer, e potrebbe essere elaborato (MAC corretto, valore corretto quando decrittografato), quindi il peer è debitamente, esplicitamente autenticato.

Come ha osservato Thomas Pornin, dovresti preferire la RFC (specifica dell'ingegnere) sulla carta (specifica della crittografia). Se RFC5054 non funziona per te, usa 2945.

Dal poco che so di protocolli crittografici, i valori A, B, M sono fondamentali per impedire all'avversario di modificare l'ordine dei messaggi e la loro riproduzione nelle stesse connessioni o in parallelo con lo stesso host o altri host.

I valori H (N) e H (g) non sono usati nella carta originale perché penso che siano parametri comuni lì, mentre in pratica questi parametri di gruppo sono selezionati da una negoziazione iniziale del protocollo. Quindi, gli attacchi possono essere possibili se il parametro cambia improvvisamente. Un server reale può anche avere più valori di verificatore SRP per ciascun utente per ciascuno dei valori supportati (g, N), o anche più verificatori per ciascuno con differenti sali 's'. Suppongo che Tom Wu li abbia integrati nell'hash per assicurare che la sicurezza del protocollo sia indipendente da tali strane impostazioni, che è come dovrebbero essere progettati tali protocolli. Forse non ha nemmeno identificato un attacco specifico ma lo ha fatto solo per "buona forma".

Forse, si spera, hai solo dimenticato di correggere la tua spiegazione di U, ma:

Tu scrivi che U è "privato" nel tuo caso ma che hash salato e sale sono pubblici. L'ultimo bit, che il valore del verificatore è pubblico, è molto strano e non è inteso in SRP. I valori del verificatore pubblico si verificano solo dopo la compromissione del server. In questo caso, SRP è sicuro come uno scambio di risposte-risposta standard basato su hash: il valore del verificatore è vulnerabile a bruteforce offline.

Se la password (P?) è molto strong, questo non è un problema, altrimenti è un grosso problema. In entrambi i casi, non sei migliore rispetto alla risposta standard alla sfida.

U non può essere "privato", viene trasferito in chiaro nel primo passaggio.