Autenticazione e protezione contro gli attacchi di riproduzione sulle istruzioni su SSL

3

ci siano due client e un server; i client hanno un ID segreto e univoco condiviso.

la loro comunicazione al server è crittografata su SSL.

il problema ora sta inviando istruzioni sicure da un client a un altro sul server utilizzando le connessioni socket e le istruzioni di instradamento al client giusto, oltre a garantire l'identità e la protezione dagli attacchi di replay di tali istruzioni da parte di aggressori.

come può essere realizzato in modo sicuro senza compromettere la privacy del cliente?

(il server non dovrebbe essere rilevante per la privacy e incapace di eseguire attacchi se compromesso)

    
posta aasgier 16.07.2015 - 01:32
fonte

1 risposta

1

Se i client comunicano con il server crittografato, e assumiamo che possiamo fidarci del server, un modo semplice per farlo sarebbe che il server trasmettesse qualche pezzo di testo in chiaro crittograficamente casuale a tutti i client (ad esempio, 2048 bit) .

I client firmano crittograficamente il testo in chiaro con i loro segreti condivisi e inviano tali firme al server, che memorizza le risposte in una tabella hash, in cui ogni risposta viene mappata anche a un elenco di client.

Quando più client danno la stessa firma, il server li informa tutti e ogni client invia un pacchetto crittografato contenente il suo ID insieme a un timestamp e un nonce, crittografati dalla chiave condivisa. Questi pacchetti vengono quindi inviati a ciascun client nell'elenco, insieme a un ID client temporaneo generato dal server.

Quando un cliente desidera comunicare con un altro client, invia l'ID temporaneo (server) del client al server. Quando due client inviano reciprocamente l'ID temporaneo al server, il server crea in modo trasparente un tunnel tra di loro. Da lì i due client possono continuare a comunicare utilizzando il loro canale condiviso, inviando un timestamp e un nonce all'interno di ogni pacchetto crittografato.

Sono sicuro che questo è sicuro dagli attacchi di replay (perché timestamp e firma di dati casuali), ma sto assumendo un algoritmo crittografico strong, un buon algoritmo di crittografia e una fonte di entropia crittografica strong sia per i client che per il server . Anche se qualcuno malintenzionato si collegasse al server durante la fase di firma originale, e fosse in qualche modo in grado di indovinare una firma funzionante (o fosse in grado di compromettere la qualità di origine entropia del server, il che creerebbe comunque ulteriori problemi, ma dal momento che noi fingendo che non sarebbero in grado di superare la fase di selezione tra pari in cui i clienti scelgono a quali altri client si desidera connettersi.

Crea un'opportunità DoS per il server, che in realtà dovrebbe essere stateless, ma le connessioni di rete OTOH creano intrinsecamente opportunità per DoS; o permetti a chiunque di connettersi via SSL, esaurisci memoria / cicli / larghezza di banda, o inizi a limitare la frequenza, ed eventualmente a escludere utenti legittimi.

EDIT: ho risposto a questa domanda come a una domanda di teoria, piuttosto che dare effettivamente un codice o un algoritmo esistente (AFAIK). Dal momento che si tratta di un problema con i giocattoli, comunque (supponendo che il server non possa essere hackerato sta andando un po 'lontano), ho pensato che sarebbe andato tutto bene. Se non era quello che cercavi, mi scuso.

    
risposta data 16.07.2015 - 02:22
fonte

Leggi altre domande sui tag