Crittografia asimmetrica

La tua comprensione di come funziona la crittografia asimmetrica è in qualche modo imperfetta. In generale, la chiave pubblica NON è utilizzata per decodificare nulla. È usato per crittografare. La chiave privata viene utilizzata per decrittografare.

Esistono diversi meccanismi per far sì che le comunicazioni segrete inizino con una coppia di chiavi pubblica / privata in possesso del server. Per la maggior parte coinvolgono il client e il server che scambiano messaggi per stabilire una chiave simmetrica condivisa che entrambi usano per la comunicazione successiva.

Nel metodo più semplice, ma in qualche modo sfavorito, il client sceglie la chiave di sessione simmetrica, la crittografa con la chiave pubblica del server e la invia al server. Poiché la chiave di sessione è crittografata con la chiave pubblica del server, qualsiasi osservatore non sarà in grado di determinare di cosa si tratta.

I metodi più complessi per stabilire la chiave della sessione includono lo scambio di chiavi Diffie-Helman e lo scambio di chiavi Elliptic-Curve Diffie-Helman. Questi evitano l'invio di qualsiasi chiave sulla rete e preservano la segretezza in caso di una futura compromissione della chiave del server, ma comportano alcuni calcoli matematici per consentire a server e client di derivare la stessa chiave.

In nessun caso la parte privata di una coppia di chiavi pubbliche viene mai inviata tramite la rete.

Non è la chiave pubblica utilizzata per la decrittazione, è la chiave privata.

Quindi, ad esempio, Alice invia a Bob un messaggio. Ciò significa che Alice utilizza la chiave pubblica di Bob per crittografare il messaggio e Bob utilizza la sua chiave privata per decodificare il messaggio.

Fortunatamente questo è stato utile solo per la clearificazione non sono un esperto di sicurezza.

Ecco un esempio di tale processo di crittografia / decrittografia: en.wikipedia.org/wiki/RSA_ ( crittografico)

Con almeno alcuni algoritmi di crittografia asimmetrica, ad es. RSA, entrambe le chiavi possono essere utilizzate per crittografare un messaggio e l'altra chiave decrittografa il risultato.

Se tengo la mia chiave privata segreta e pubblico la mia chiave pubblica, ci sono due modi per comunicare:

Posso crittografare un messaggio con la mia chiave privata e inviarlo a te. tu può decodificarlo con la mia chiave pubblica. Chiunque intercetti il messaggio può anche decodificarlo con la mia chiave pubblica. Quindi cosa ho ottenuto? Bene, tu e tutti gli altri sapete che solo io ho la chiave privata, quindi per la decrittografia di aver funzionato, devo essere stato lo scrittore di il messaggio. Inoltre, poiché la modifica del messaggio crittografato causerebbe il fallimento della decrittografia, si sa anche che il messaggio è esattamente ciò che ho scritto.

Quindi, questo metodo fornisce l'integrità e l'autenticazione dei messaggi e costituisce la base delle firme digitali.

In alternativa, puoi criptare un messaggio con la mia chiave pubblica e inviarlo a me. Posso decodificarlo con la mia chiave privata. Nessun altro ha la chiave privata, quindi non possono decifrare il messaggio. Pertanto, questo metodo offre la segretezza, ma senza alcuna verifica su chi ha creato il messaggio e nessuna garanzia di integrità del messaggio, poiché chiunque può creare un messaggio.

Entrambi questi metodi funzionano, indipendentemente da quanto è nota la chiave pubblica, purché la chiave privata sia tenuta segreta.

Entrambi forniscono elementi costitutivi utili per algoritmi più complessi che superano altri problemi. Ad esempio, quando ricevi la mia chiave pubblica, come fai a sapere che in realtà viene da me? Non riesco a firmarlo digitalmente con la mia chiave privata, perché non ti fidi ancora della mia chiave pubblica. Un problema di pollo e uova, con soluzioni che vanno dal ritrovarsi di persona alle autorità di certificazione.

Altri algoritmi asimmetrici possono solo essere in grado di crittografare con una delle chiavi e decifrare con l'altra. per esempio. DSA supporta solo firme digitali, non segretezza.

Anche RSA non è realmente utilizzato per la segretezza dei messaggi. È troppo lento per crittografare i messaggi lunghi. Invece, viene utilizzato per negoziare una chiave simmetrica di breve durata per una crittografia più veloce. Vedi link per un'ottima risposta che spiega un po 'di più.

Un ultimo avvertimento: ci sono dei punti deboli nell'usare la stessa coppia di chiavi private e pubbliche sia per l'autenticazione che per la segretezza. Non farlo.

Offro una visione diversa che mi ha aiutato a capire le cose nel corso della giornata.

La crittografia asimmetrica funziona utilizzando come base un paio di due grandi numeri che sono calcolati in qualche modo, quindi sono correlati. Li chiamiamo chiavi o 2 parti di una chiave.

Tuttavia, la seguente proprietà contiene:

• se ne hai solo, non puoi calcolarne uno solo dall'altro
• gli algoritmi in atto ti danno il fatto che qualsiasi cosa criptata da uno di questi numeri può essere decifrata solo dall'altro numero (e nemmeno usando il primo numero, questa è una proprietà chiave).

Ora, in aggiunta, decidiamo che uno dei due è pubblico e lo distribuiremo globalmente (in certificati X.509, su server di chiavi OpenPGP pubblici, ecc.) mentre l'altro è privato e tutto dovrebbe essere reso sicuro in modo che solo l'entità (può essere un individuo, un'organizzazione, un host, un indirizzo email, ecc.) coperto da esso è l'unico a conoscere questa parte "privata".

Quindi, se immagini che tutti hanno queste 2 parti e tutte le parti pubbliche sono conosciute, fidate e sicure (vedremo che ci sono dei problemi qui) puoi prendere le seguenti cose, se prendiamo Alice e Bob:

• tutto ciò che Alice crittografa con la chiave Bob pubblica può essere decifrato solo da Bob (perché dovrebbe essere l'unico a disporre della chiave privata corrispondente)
• tutto ciò che Alice crittografa con la sua chiave privata può essere decodificato da chiunque usi la sua chiave pubblica (che è per definizione pubblica e disponibile per tutti).

Potresti trovare inutile il secondo punto. Non lo è, è la base dell'autenticazione in effetti. Perché normalmente solo Alice ha la sua chiave privata, quindi se sei in grado di decifrare qualcosa con la sua chiave pubblica, allora sai che è stata crittografata con la chiave privata Alice, quindi significa che è stata eseguita da Alice, hai dimostrato l'autenticazione.

Ora ovviamente il problema è come pubblichi tutte le chiavi pubbliche, perché chiunque può pubblicare una chiave dicendo che è per "[email protected]".

Come è risolto?

• nel mondo PKI X.509, le chiavi pubbliche non sono gestite in questo modo ma attraverso un certificato X.509 (spesso chiamato "certificato SSL" che è doppiamente sbagliato perché TLS ha sostituito SSL 20 anni fa e perché puoi fare TLS senza certificati), che è fondamentalmente una chiave pubblica più un inizio e una data di fine e una firma. Qual è la firma? Si tratta di un calcolo trasferito su tutto il contenuto del certificato (da qui la chiave pubblica) fatto dalla chiave privata legata ad un altro certificato, tipicamente una "autorità di certificazione" (normalmente esiste una catena di essi ma che non modifica l'idea generica ). E alla fine ti fidi di alcune CA, così hai la loro chiave pubblica e convalidi qualsiasi certificato che sia validamente firmato da chiavi private di queste CA.
• nella rete di fiducia di OpenPGP, infatti chiunque come una decisione locale / individuale può dire quanto si fidi di una determinata chiave; l'idea è che normalmente i due individui si incontrano nella vita reale, addirittura mostrano documenti di identità ufficiali, e solo dopo ciò si può dire "sì, la chiave X è davvero appartenente a tale individuo".

So my question is, what stops an attacker listening in from just grabbing the key which you send alongside the data? If it's not actually being sent alongside the encrypted data, then at what point does the server receive the key that it needs to decrypt?

Prendiamo un tipico handshake HTTPS che utilizza HTTP su TLS (vedi link per una spiegazione completa)

Puoi guardare questo diagramma per TLS 1.3: link ; vedrai che ogni messaggio Certificate è di fatto crittografato con chiavi derivate da scambi precedenti (i messaggi ClientHello e ServerHello che includono ciascuno un segreto casuale). Ricorda anche che se ti fidi di una determinata CA (che è la sua chiave privata) ti fidi di qualsiasi cosa firmata da essa, cioè qualsiasi certificato del client finale che abbia una firma fatta dalla sua chiave privata (che quindi chiunque potrebbe verificare usando la sua chiave pubblica). / p>

Chiunque intercetta ServerHello e rispondendo non sarà in grado di dimostrare successivamente che ha la chiave corrispondente associata al certificato inviato con il messaggio Certificate . Questo è anche il motivo per cui l'autenticazione è così importante: senza di essa puoi avere una sicurezza come nel flusso crittografato ma senza alcuna idea su chi stai parlando, che potrebbe essere un uomo nel mezzo che trasmette il traffico.

Vedere il messaggio ClientKeyExchange : " che può contenere un PreMasterSecret, chiave pubblica o nulla. (Anche in questo caso dipende dalla cifra selezionata). PreMasterSecret viene crittografato utilizzando la chiave pubblica del certificato del server. "e quindi solo il server (con la chiave privata corrispondente) sarà in grado di decrittografarlo e andare avanti. Lo stesso vale per l'altra direzione.