RSA o ECDHE per certificati x.509: cosa fanno ciascuno?

2

Sono relativamente nuovo ai certificati x.509, ma recentemente ho guardato il lucchetto di connessione https nella parte superiore dello schermo. Su alcuni siti Web, facendo clic sul pad mi informa che il sito è collegato in modo sicuro tramite uno scambio di chiavi, ECDHE, e queste chiavi sono firmate con RSA. Ma quando apro il certificato completo per il sito, la chiave pubblica è RSA 2048 bit. Questo mi ha confuso, poiché pensavo che la chiave pubblica dovesse essere di 256 bit ECC e non una chiave RSA, poiché lo scambio di chiavi è ECC e non RSA.

Probabilmente mi manca qualcosa di ovvio, ma qualsiasi aiuto sarebbe apprezzato.

    
posta Sam Gregg 01.02.2017 - 21:41
fonte

3 risposte

2

Le chiavi pubbliche / private sono (abbastanza) statiche e sono normalmente 2048 bit o anche 4096 bit - vengono utilizzate all'inizio della negoziazione TLS, per verificare l'identità del sito (e del client, nel caso di un certificato client) e negoziare usando la crittografia asimmetrica una nuova chiave che sarà a) condivisa tra il client e il server, b) unica per questa connessione ec) simmetrica. Questa è la chiave che viene effettivamente scambiata ed è più breve e ciò che viene utilizzato per il trasporto effettivo.

La crittografia asimmetrica è (relativamente) lenta - ecco perché la sessione è effettivamente crittografata con la crittografia simmetrica.

    
risposta data 01.02.2017 - 21:47
fonte
2

Uno schema di scambio di chiavi è costituito da due algoritmi:

  • Un algoritmo di generazione di chiavi, che seleziona casualmente una coppia di chiavi;
  • Un algoritmo di scambio di chiavi, che prende come input la tua chiave privata e la chiave pubblica del partecipante remoto e genera un segreto condiviso.

Uno schema di firma è una tripla di algoritmi:

  • Un algoritmo di generazione della chiave, che seleziona casualmente una coppia di chiavi.
  • Un algoritmo di firma, che accetta un messaggio e una chiave privata e emette una firma.
  • Un algoritmo di verifica, che accetta un messaggio, una firma e una chiave pubblica, e restituisce un valore booleano che indica se la combinazione è valida.

Per eseguire uno scambio di chiavi effimero autenticato, le parti devono concordare uno schema di scambio di chiavi e uno schema di firma e devono avere la propria chiave pubblica autenticata. Poi:

  1. Entrambe le parti generano la propria coppia di chiavi di scambio temporaneo;
  2. Entrambe le parti firmano la loro chiave pubblica di scambio di chiavi effimere;
  3. Entrambe le parti inviano la loro chiave pubblica di scambio delle chiavi effimere all'altra, insieme alla firma di quella chiave;
  4. Entrambe le parti controllano la firma sulla chiave pubblica di scambio temporaneo dell'altro e interrompono se non è valida;
  5. Entrambe le parti utilizzano ora la loro chiave privata di scambio di chiavi effimere e la chiave pubblica di scambio temporanea dell'altro per calcolare il segreto condiviso.

Questo può essere fatto anche facendo in modo che solo una delle parti firmi la chiave pubblica di scambio delle chiavi effimere. Ecco come facciamo normalmente HTTPS, per esempio. L'altra parte quindi non ottiene alcuna garanzia che l'altro sia quello che dichiara di essere.

Puoi scegliere qualsiasi combinazione di algoritmi firma e Diffie-Hellman per questo. Non importa se lo schema della firma è RSA e lo schema di scambio delle chiavi è ECDH. In tal caso, il passo 1 utilizza l'algoritmo di generazione della chiave ECDH per generare una coppia di chiavi ECDHE, quindi il passo 2 utilizza l'algoritmo di firma RSA per firmare la chiave pubblica ECDHE. L'algoritmo della firma non si preoccupa del fatto che il messaggio che sta firmando sia una chiave pubblica ECDHE: sono solo i dati che una parte deve firmare e poi l'altra da verificare.

Un'altra cosa da notare è che il titolo della tua domanda rivela che sei confuso da qualcosa:

RSA or ECDHE for x.509 certificates-what does each do?

ECDHE non è coinvolto nel certificato. Il certificato contiene una chiave di firma pubblica , i metadati che descrivono il suo proprietario e le firme per aiutare il destinatario a verificare che i metadati siano accurati. L'algoritmo di firma più utilizzato nei certificati è RSA. ECDSA è un'altra alternativa. ECDH non è rilevante, perché non è un algoritmo di firma.

Con i certificati, l'algoritmo dello schizzo sopra sarebbe modificato aggiungendo due passaggi all'inizio:

  1. Entrambe le parti inviano il loro certificato a vicenda.
  2. Entrambe le parti utilizzano il proprio PKI per verificare il certificato dell'altro e interrompono se non è valido.

Quindi la procedura continua utilizzando le chiavi in dotazione del certificato per firmare e verificare lo scambio di chiavi.

    
risposta data 02.02.2017 - 02:43
fonte
1

Domande correlate:

Risposta breve: una sessione TLS ha i seguenti quattro passaggi principali: (in qualche modo semplificata)

  1. Client e server sono d'accordo su una suite di crittografia, il mio browser e security.stackexchange.com sono d'accordo su TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) , quindi usiamolo come esempio.
  2. Il client impone al server di dimostrare chi è facendo una firma di chiave pubblica dei dati forniti dal client. Nel nostro esempio, userebbe RSA .
  3. Client e server eseguono uno scambio di chiavi per stabilire una chiave di sessione. Nel nostro esempio, useranno ECDHE con la curva secp256r1 . Il server firmerà i messaggi ECDHE con la sua chiave RSA solo per prevenire un attacco man-in-the-middle.
  4. Una volta che una chiave di sessione è stata stabilita e entrambi i lati (e nessun altro) ne ha una copia, useranno questa chiave di sessione con un codice simmetrico per il resto della sessione - nel nostro esempio AES-128-GCM .
risposta data 02.02.2017 - 00:04
fonte

Leggi altre domande sui tag