Come si chiama questo schema e come dovrebbe funzionare esattamente?

Question

Come si chiama questo schema e come dovrebbe funzionare esattamente?

#1 da (1 voti)

1

Quindi pensavo alla comunicazione client-server e a come mantenerlo privato, specialmente da attacchi man-in-the-middle. Ho trovato uno schema che sono sicuro che esiste già, ma non sono riuscito a trovare risultati di ricerca sufficientemente concreti per saperne di più.

È iniziato pensando che quando un client si connette al server, vorrebbe stabilire un canale di comunicazione sicuro, in modo che il client possa generare una coppia di chiavi privata / pubblica e inviare la chiave pubblica al server. Il problema è ottenere la chiave pubblica sul server in modo sicuro (altrimenti un uomo nel mezzo potrebbe decrittografare tutti i messaggi usando la chiave pubblica che ha afferrato dal primo messaggio, allegare la propria chiave pubblica al messaggio, usare la chiave privata corrispondente per decodificare la risposta e, dopo averla memorizzata, re-cifrare con l'effettiva chiave pubblica del cliente).

Quindi ho pensato ad una possibile soluzione: il client prima riceve una chiave pubblica dal server, che userà per crittografare la propria chiave pubblica. Il MitM può intercettare tutti i messaggi, ma non sarà in grado di decodificare nessuno di essi - solo il server effettivo può decrittografare la richiesta del client e la risposta può essere decifrata dal solo client effettivo. Una volta che il server conosce la chiave pubblica del client, lo memorizza in modo sicuro e lo utilizza per crittografare qualsiasi ulteriore comunicazione.

Ho alcune domande correlate.

Che cos'è questo tipo di sicurezza / handshaking chiamato?
Ho sentito la parola nonce ma ho ragione che si tratta di impedire attacchi di riproduzione e non il problema MitM che sto cercando di risolvere?
La chiave iniziale che il server invia al client dovrebbe essere fissa e possibilmente pubblicata da qualche parte, in modo che i clienti possano saltare il passaggio "Dammi il tuo passaggio chiave pubblico" nelle sessioni successive? O dovrebbe essere una chiave appena generata per ogni cliente ad ogni nuova richiesta di sessione?
Al contrario, se la chiave pubblica del client cambia con ogni sessione o il client può riutilizzare la stessa chiave una volta che è stata comunicata in sicurezza al server?
Quali sono i rischi a questo, a parte l'ovvio fallimento da parte di una delle parti coinvolte di mantenere private le chiavi private?

Sono sicuro che questo è abbastanza comune e probabilmente già come funzionano molti schemi di autenticazione, quindi piuttosto che rispondere a tutte queste domande separatamente, sarei felice se qualcuno potesse fornirmi la terminologia corretta (ho provato alcune combinazioni di parole chiave come "client / server", "crittografia asimmetrica", "stabilire una sessione", ma sono troppo generiche per trovare qualcosa di utile). E anche se questo è un SE teorico, immagino che come con tutta la buona sicurezza non si debba implementare la propria implementazione, quindi qualsiasi codice di esempio di una corretta applicazione client / server (ad es. In PHP) usando librerie ben consolidate sarebbe il benvenuto.

key-exchange session-management

posta CompuChip 12.05.2018 - 01:07

fonte

1 risposta

Leggi altre domande sui tag key-exchange session-management

Alternative disponibili per lo scambio di chiavi pubbliche per l'invio di e-mail Identificazione del tipo di attacco del sito Web (Meuhy.php)

score 1 · Accepted Answer

La frase specifica che stai cercando è "scambio di chiavi". link

Ci sono alcuni schemi (molti deprecati) per realizzare questo in modo sicuro, ma se stai scrivendo il tuo programma (e quindi non sei preoccupato per "chi è questa persona in realtà", e solo per scambiare in modo sicuro le chiavi ), Diffie-Helman è un buon punto di partenza. link

Diffie-Helman è specificamente progettato per rendere sicuro lo scambio di chiavi anche se osservato . Se si desidera rendere sicuro lo scambio di chiavi contro gli attacchi MitM, è qui che entra in possesso di certificati firmati da una CA attendibile. Una CA attendibile non (o non suppone ) firmerà la stessa identità per più parti, quindi un utente malintenzionato nel mezzo che intercetta la chiave pubblica legittima prima che venga consegnato al conversatore previsto non sarà in grado di inserire la propria chiave pubblica, poiché non sarà firmato in modo corretto.

Gli spunti sono effettivamente lì per assicurarti che ogni messaggio venga risposto una sola volta e di solito entro un tempo prestabilito. Non impediscono a un utente malintenzionato di intercettarli, inoltrarli, intercettare la risposta, inoltrarla, ecc.
Il segreto in avanti è considerato la migliore pratica ora. link Con i sistemi che implementano la segretezza anticipata, vengono generate nuove chiavi ogni sessione, in modo che le informazioni sulla sessione precedente non possano essere compromesse utilizzando un'intercettazione di mitm delle nuove chiavi. Nota: non stai generando nuove chiavi private a lungo termine per ogni sessione, stai generando nuove "chiavi segrete" casuali (cioè la chiave utilizzata solo durante quella sessione per crittografare il traffico).
Vengono mantenute le chiavi private specifiche dell'utente utilizzate per generare le chiavi di sicurezza per sessione, ma quelle chiavi non sono le chiavi utilizzate per crittografare e decrittografare il traffico direttamente.
Oltre al compromesso della chiave privata, nulla può impedire a un mitm di manomettere il traffico che possono toccare. Le firme CA corrette possono impedire che la catena di certificati sia valida se fanno manomettere qualcosa, ma che in realtà non proteggerà i dati; solo la sua affidabilità.