Perché un attacco man-in-the-middle non può accadere con RSA?

Questo è il problema della distribuzione delle chiavi, ed è difficile. In generale, Alice deve già sapere che la chiave appartiene a Bob, o che qualcuno di cui si fida affermi che appartiene a lui.

Per HTTPS ciò è ottenuto da una Public Key Infrastructure (PKI), dove Certificate autorità (CA) attestano che una chiave appartiene a un determinato dominio o insieme di domini. Questo schema si sgretola rapidamente se una CA ampiamente affidabile si dimostra indegna della fiducia riposta in essa, e sfortunatamente questo è accaduto più volte in passato ( WoSign , Symantec ).

SSH lo attenua memorizzando la chiave host per ogni server che ti connetti, quindi ti avvisa se la chiave host cambia per le connessioni future (questo è chiamato trust al primo utilizzo ). Inoltre ti avvisa e ti permette di verificare l'impronta digitale della chiave quando ti colleghi per la prima volta, ma ciò richiede l'ottenimento dell'impronta digitale attraverso altri mezzi, in modo che non risolva il problema fino a quando non lo trasmette all'utente.

Non hai torto, in senso stretto. Le garanzie di riservatezza e autenticità offerte dalla crittografia asimmetrica presuppongono che tutte le parti dispongano di copie autentiche delle chiavi pubbliche delle controparti. Se un avversario impersona la tua controparte e ti inganna ad accettare la propria chiave non autentica come vero affare, tutto va a pezzi.

Il vantaggio della crittografia asimmetrica è che questa autenticazione può avvenire su un canale visibile a tutto il pubblico. Pensala in questo modo: tutta la crittografia richiede che i partecipanti usino una sorta di canale sicuro intermittente a un certo punto per configurare la crittografia per dopo. La pura crittografia simmetrica richiede un canale riservato e autentico per consentire ai partecipanti di stabilire le chiavi segrete condivise. La crittografia asimmetrica migliora su questo perché richiede solo un canale autentico : puoi autenticare le chiavi pubbliche delle controparti in piena vista degli intercettatori.

Il problema che hai descritto può effettivamente accadere - nulla in RSA (o qualsiasi altro schema di crittografia) lo impedisce. Questo è chiamato ad es. "problema di distribuzione delle chiavi".

Sì, scambiare la chiave su un canale sicuro , invece che su uno del messaggio non sicuro, è un modo per risolverlo. A seconda del caso d'uso potrebbero esserci altri modi utili (o meno).

In TLS, questo è impedito dall'avere già qualcosa sull'altro lato: i verifi- canti pubblici di varie CA, preinstallati con il sistema operativo o il browser. Può essere usato per controllare la firma della chiave pubblica trasmessa, che è stata effettuata da una CA.

(Non molto rilevante per questa domanda, ma nessuno crittografa i messaggi direttamente con RSA, ad esempio perché è lento. Crittografare i messaggi con AES e solo la chiave AES con RSA è molto più comune, ma questo non cambia il problema qui).

Perché affermi che non può accadere con RSA? Certo che può.

Nel caso in cui la chiave pubblica sia un falso. Supponiamo che A richieda la chiave pubblica di B. A si riferisce all'host di destinazione per nome. Se il DNS di A viene compromesso dall'attaccante, A può ottenere l'IP dell'host compromesso, che fornisce un certificato falso. L'intera catena di certificati può essere compromessa. A ottiene una chiave pubblica e crede che questa sia una chiave di B, mentre in realtà è una chiave di C. Poi succede quello che hai descritto. C è nel mezzo e legge tutto il traffico.

Leggi informazioni su Public Key Pinning. È una delle possibili misure contro l'uomo nel mezzo degli attacchi in PKI, non limitato a RSA.

Now, when A sends an encrypted message using what he thinks is B's public key (but is actually C's), C will intercept this message, decrypt it, then encrypt it again using B's actual public key.

Would this work? If not, why not? Is it just a matter of using a secure network to send the public key?

Sì, questo "funzionerebbe" in un certo senso. Questo è un noto attacco del MITM sulla crittografia a chiave asimmetrica. Questa tecnica non è solo usata da "cattivi". Ad esempio, questo è esattamente ciò che fanno le appliance di sicurezza di rete di alcuni fornitori per "ispezionare" il traffico di rete crittografato e bloccare il traffico "cattivo".

Quindi, perché ho messo "avrebbe funzionato" tra virgolette? Ad esempio, se un malintenzionato MITM sostitutivo sostituisce il proprio certificato per un certificato del sito Web HTTPS noto, molto probabilmente questo certificato non sarà stato firmato da una CA attendibile (a meno che il MITM non abbia in qualche modo ingannato la CA attendibile a firmare un certificato che ha dichiarato che era il sito web conosciuto). In questo caso, un browser Web che visita il sito Web HTTPS che riceve il certificato MITM invierà un allarme e comunicherà all'utente di non procedere perché il nome del dominio non corrisponde o corrisponde ma il certificato non è stato firmato da una CA attendibile.

I certificati di CA attendibili sono incorporati nel sistema operativo al momento dell'acquisto. Questi sono ragazzi come Verisign, ecc. È possibile visualizzare i certificati CA affidabili utilizzando le utilità del sistema operativo. Potresti rimuoverli se vuoi, ma poi tutti i siti web che visiti verranno visualizzati senza un bel simbolo di blocco verde.

Penso che ti sia mancato il ruolo dell'Autorità di certificazione (CA) nella creazione / distribuzione di certificati.

Il concetto di infrastruttura a chiave pubblica si è evoluto per aiutare a risolvere questi problemi e altri. Un'infrastruttura a chiave pubblica (PKI) consiste di elementi software e hardware che una terza parte affidabile può utilizzare per stabilire l'integrità e la proprietà di una chiave pubblica.

La parte fidata, denominata autorità di certificazione (CA), in genere esegue tale operazione emettendo certificati binari firmati (crittografati) che affermano l'identità dell'oggetto del certificato e associano tale identità alla chiave pubblica contenuta nel certificato. La CA firma il certificato utilizzando la sua chiave privata. Emette la chiave pubblica corrispondente a tutte le parti interessate in un certificato CA autofirmato. Quando viene utilizzata una CA, l'esempio precedente può essere modificato nel modo seguente:

1. Supponiamo che la CA abbia emesso un certificato digitale firmato contiene la sua chiave pubblica. La CA firma automaticamente questo certificato utilizzando la chiave privata che corrisponde alla chiave pubblica nel certificato.
2. Alice e Roberto accettano di utilizzare la CA per verificare le loro identità.
3. Alice richiede un certificato di chiave pubblica dalla CA.
4. La CA verifica la sua identità, calcola un hash del contenuto che comporrà il suo certificato, firma l'hash usando il privato chiave che corrisponde alla chiave pubblica nella CA pubblicata certificato, crea un nuovo certificato concatenando il file contenuto del certificato e hash firmato, e rende il nuovo certificato pubblicamente disponibile.
5. Bob recupera il certificato, decodifica l'hash firmato utilizzando il comando chiave pubblica della CA, calcola un nuovo hash del certificato contenuto e confronta i due hash. Se gli hash corrispondono, i la firma è verificata e Bob può assumere che la chiave pubblica in il certificato appartiene effettivamente ad Alice.
6. Bob utilizza la chiave pubblica verificata di Alice per crittografare un messaggio a lei.
7. Alice usa la sua chiave privata per decrittografare il messaggio di Bob.

In sintesi, il processo di firma del certificato consente a Bob di verificare che la chiave pubblica non sia stata alterata o corrotta durante il transito. Prima di emettere un certificato, la CA esegue il hashing del contenuto, firma (crittografa) l'hash utilizzando la propria chiave privata e include l'hash crittografato nel certificato emesso. Bob verifica i contenuti del certificato decodificando l'hash con la chiave pubblica CA, eseguendo un hash separato del contenuto del certificato e confrontando i due hash. Se corrispondono, Bob può essere ragionevolmente certo che il certificato e la chiave pubblica in esso contenuta non siano stati alterati.

Fonte: link