Invio di chiavi di crittografia / decrittografia su HTTPS

0

Sono un principiante del mondo crittografico, quindi abbi pazienza con me.

Pensare a una strategia (per proteggere i dati P2P) in cui il server sta generando una chiave che dovrebbe essere utilizzata per la crittografia AES tra i client e l'invio a più client (Android, iOS, Web). Mi chiedevo se dovessi usare la crittografia nell'invio di questa chiave tramite la rete https ai client o che https si occupasse di questo? Capisco che lo scambio di chiavi di Diffie Hellman sia fatto per lo stesso motivo, ma è eccessivo?

    
posta amitchhajer 04.05.2018 - 06:52
fonte

3 risposte

1

HTTPS (o TLS in generale) può essere usato per inviare il segreto ai client in modo sicuro, cioè protetto contro lo sniffing e la modifica. Ma ha bisogno di avere una qualche forma di autenticazione per proteggere contro gli attacchi degli uomini nel mezzo (che potrebbero annusare o modificare il segreto). L'autenticazione viene solitamente effettuata con un certificato che il cliente deve conoscere in anticipo o in cui il cliente può ottenere il trust in quanto è stato firmato da un emittente di fiducia.

Diffie-Hellman da solo non è sufficiente per scambiare la chiave poiché manca la parte di autenticazione. In effetti, TLS utilizza comunemente Diffie-Hellman (ma non sempre) come scambio di chiavi, ma esegue anche l'autenticazione del server.

    
risposta data 04.05.2018 - 10:21
fonte
0

Lo scambio iniziale di chiavi pubbliche è su un canale non sicuro. Una volta che entrambe le parti hanno la chiave pubblica dell'altra parte, possono quindi utilizzare la crittografia asimmetrica per concordare una chiave simmetrica. Dopodiché, tutte le comunicazioni sono simmetricamente criptate. Ma si noti che ciò dipende dallo scambio iniziale di chiavi pubbliche su una connessione non sicura. Come fai a sapere se una terza parte non ha intercettato la chiave pubblica di una delle parti, ha sostituito la propria e ha successivamente inoltrato i messaggi avanti e indietro tra le due parti?

Una delle soluzioni è che le due parti legittime conoscano le rispettive chiavi pubbliche (o l'hash delle rispettive chiavi pubbliche) in anticipo. Questo è più sicuro, ma insolito nel 2018.

Un'altra soluzione è che entrambe le parti si fidino di un'entità di terze parti, come un'autorità di certificazione. I browser e i sistemi operativi vengono preconfezionati con una notevole quantità di autorità di certificazione attendibili. Una quantità molto consistente. E quelle autorità di certificazione sono di solito imprese - imprese commerciali con una presenza fisica e uffici e conti bancari - che operano sotto le grazie dei governi che hanno giurisdizione pertinente su di loro. Se un governo del genere costringesse un'autorità di certificazione radice a emettere un certificato intermedio fasullo per il governo, tale certificato sarebbe quindi considerato attendibile da qualsiasi browser Web che già si fidava dell'autorità di certificazione radice. E come ho sottolineato, ci sono un sacco di autorità di certificazione radice affidabili nel tuo browser e / o nel tuo sistema operativo. Ognuno di loro è vulnerabile alla coercizione imposta dal governo (o potenzialmente persino al crimine organizzato, a seconda della relativa impunità relativa in quel paese). Un compromesso come questo è effettivamente accaduto, in particolare nel 2011, a un'autorità di certificazione denominata DigiNotar. Ciò ha comportato massicce violazioni della sicurezza a livello nazionale.

Infine, vi è una soluzione di avere una versione più piccola del sistema di autorità di certificazione composto da circoli di fiducia, entità che sono comunemente riconosciute dalle parti comunicanti come affidabili ma deliberatamente selezionate in anticipo e non installate nel browser per impostazione predefinita. Le chiavi pubbliche potrebbero quindi essere firmate da un'entità reciprocamente attendibile prima di essere scambiate tramite lo scambio Diffie Hellman.

La sfida consiste nello scambiare tali chiavi pubbliche in modo affidabile prima che avvenga una comunicazione crittografata successiva. Diffie Hellman NON è una panacea.

    
risposta data 04.05.2018 - 16:33
fonte
-1

Suppongo che sia necessario utilizzare qualsiasi algoritmo di scambio di chiavi per effettuare lo scambio di chiavi, indipendentemente dall'overkill (tutti i principali algoritmi crittografici hanno una complessità temporale elevata). HTTPS non può aiutarti in questo contesto, poiché HTTPS verificherà solo l'origine della chiave (il tuo server). Non garantirà che la chiave non sia stata copiata o rubata da nessuno.

Il Diffie-Hellman utilizzato in HTTPS per lo scambio di chiavi, viene utilizzato per scambiare le chiavi inviate dall'autorità di certificazione al client, che decrittografa il carico utile ricevuto dal server e quindi lo autentica.

Leggi questo per ulteriori dettagli.

    
risposta data 04.05.2018 - 08:17
fonte

Leggi altre domande sui tag