coppie di chiavi utente e problemi man-in-the-middle

1

Sto cercando di capire come scambiare le chiavi dell'utente con un server.

Forse durante la registrazione un applet JS genera una coppia di chiavi per l'utente. Queste chiavi sarebbero utilizzate per firmare richieste successive dall'utente al server, quindi il server ha bisogno di una copia della chiave pubblica dell'utente da associare all'account dell'utente.

Ma l'invio della chiave pubblica al server è soggetto agli attacchi del MITM - se un cattivo intenzionato sufficientemente motivato voleva mettersi nel mezzo, catturare la chiave pubblica sul suo cammino verso il server e sostituirla con una chiave per la quale controlla la chiave segreta.

Parte della soluzione sembra essere l'invio della chiave pubblica da parte dell'agente solo tramite un canale crittografato, ad esempio TLS. Ma sembra che con le applicazioni basate su browser, l'onere sia ancora molto all'utente di essere sia istruito e sveglio abbastanza da rendersi conto quando la loro sessione non è con il server giusto a cui dovrebbe essere connesso. In particolare, il nostro cattivo motivato potrebbe creare qualcosa che sembra autentico e credibile, ad esempio

httpS://certificate_server_acme.com

di cui avrebbe il controllo. Il nostro utente potrebbe non rendersi conto che DOVREBBE collegarsi solo a, ad esempio, httpS://certificates.acme.com

Sospetto che si tratti solo di "certificati autofirmati". Le password non risolvono il problema. La verifica della chiave di un utente tramite un messaggio di posta elettronica non è fattibile a meno che gli utenti non possano confrontare e verificare una chiave e il nostro malintenzionato motivato non possa manomettere i messaggi di posta elettronica sulla strada per l'utente.

O c'è qualcosa, forse una funzionalità di OpenID, che può essere utilizzata?

    
posta Johan 20.03.2015 - 13:01
fonte

1 risposta

2

Esiste già un'infrastruttura per gestire la fiducia e si chiama "Public Key Infrastructure". Questa è la base di tutti i protocolli SSL / TLS utilizzati su Internet e siti Web.

L'idea principale è quella di designare una Terza parte fidata (TTP) che sia riconosciuta da tutte le parti coinvolte. Questi TTP emettono la loro chiave pubblica e vengono spediti di default in tutti i principali browser (dobbiamo supporre che non vi sia alcuna manomissione prima di questo punto, o che tutto non funzioni). Una volta che hai quella chiave pubblica di cui ti fidi, nessun server può chiedere al TTP (che è chiamato Autorità di certificazione) di consegnargli un certificato. Il certificato include una chiave pubblica e l'identità del richiedente certificato e dell'emittente del certificato. Quando la CA ha verificato l'identità del richiedente, il certificato è firmato dalla chiave privata della CA.

Chiunque riceve questo certificato firmato può verificare la firma della CA. Se è ok, si deduce che il certificato (quindi la chiave pubblica) appartiene all'entità menzionata nel certificato. Puoi quindi utilizzarlo per crittografare il messaggio a questa persona senza timore che venga intercettato da qualcun altro.

Se qualcuno su cui effettuare un attacco MitM sul sistema dovrebbe:

  • ottenere un certificato contraffatto per un nome di dominio che non possiede
  • portare la vittima ad accettare un nuovo certificato CA / falsificato su cui ha il controllo (e quindi generare un certificato forgiato)
  • interrompe la chiave pubblica (molto improbabile)

Altrimenti, la firma del certificato non verrebbe verificata e pertanto l'autenticità della chiave pubblica non verrebbe dimostrata.

    
risposta data 20.03.2015 - 13:39
fonte

Leggi altre domande sui tag