it-swarm-eu.dev

Comprensione SSL 2048 bit e crittografia 256 bit

Sulla pagina di DigiCert pubblicizzano un SSL a 2048 bit con una crittografia a 256 bit: http://www.digicert.com/256-bit-ssl-certificates.htm

Qual è esattamente la differenza qui e perché vengono referenziati due bit di crittografia?

Ecco uno screenshot dell'annuncio:

Nell'annuncio Premium SSL di Geotrust, lo pubblicizzano come:

Security: domain control validation, strong 256-bit encryption, 2048-bit root

Quindi qual è la differenza tra la crittografia a 256 bit e la radice a 2048 bit?

Spero che chiarisca la domanda.

63
JohnJ

Il 2048 bit riguarda la coppia di chiavi RSA: le chiavi RSA sono oggetti matematici che includono un intero grande e una "chiave di 2048 bit" è una chiave in modo tale che il grande numero intero sia maggiore di 22047 ma inferiore a 22048.

Il 256 bit riguarda SSL. In SSL, la chiave del server viene utilizzata solo per trasmettere una chiave casuale a 256 bit ( che non ha una struttura matematica, è solo un gruppo di bit); in termini approssimativi, il client genera una chiave casuale a 256 bit, la crittografa con la chiave pubblica RSA del server (quella che si trova nel certificato del server ed è una "chiave a 2048 bit") e invia il risultato al server. Il server utilizza la sua chiave RSA privata per invertire l'operazione e quindi ottenere la chiave a 256 bit scelta dal client. Successivamente, client e server utilizzano 256 bit per eseguire simmetrici controlli di crittografia e integrità e RSA non viene più utilizzato per tale connessione.

Vedi questa risposta per alcuni dettagli. Questa configurazione è spesso chiamata "crittografia ibrida". Questo perché RSA non è appropriato per la crittografia di massa, ma la crittografia simmetrica non può svolgere l'attività pubblica/privata iniziale necessaria per iniziare le cose.

(SSL può fare lo scambio di chiavi con altri algoritmi diversi da RSA, quindi ho semplificato un po 'la descrizione nel testo sopra, ma questa è la sintesi dell'idea.)

69
Thomas Pornin

Per aggiungere un po 'più di dettaglio, la chiave RSA a 2048 bit è qualcosa che si chiama crittografia asimmetrica. Viene utilizzato per la convalida dell'identità (firma) e per garantire che solo un destinatario previsto possa accedere alle informazioni inviate (crittografia). È composto da due pezzi, una chiave pubblica e una chiave privata. Le chiavi sono in realtà correlate tra loro, ma poiché sono collegate da due numeri pseudo-primi molto grandi (primi in relazione tra loro), sono molto difficili da capire la chiave privata dal pubblico.

Detto questo, poiché l'algoritmo si basa su qualcosa che è semplicemente molto difficile da capire (ma è risolvibile), è meno sicuro di un algoritmo simmetrico basato su un segreto condiviso, che non è matematicamente risolvibile e non si basa sulla complessità di un problema di matematica per la sicurezza (ne parleremo più avanti). Questo è il motivo per cui la chiave è molto più grande della controparte simmetrica (che è solo 256 bit). Per rendere difficile la risoluzione dell'equazione è necessaria la chiave molto più grande e, inoltre, più informazioni vengono trasmesse con la chiave asimmetrica, più è probabile che venga interrotta (inoltre, la crittografia/decodifica è più intensa per il processore).

Per questo motivo, SSL utilizza RSA solo per le fasi di convalida e scambio di chiavi. Invece, una chiave simmetrica (in questo caso di 256 bit se supportata dal browser sul client) viene generata e ritrasmessa al server tramite crittografia RSA e quindi il resto dei dati viene scambiato tramite la chiave condivisa e un algoritmo simmetrico.

Ciò si verifica dal client prima che decodifica la risposta a una sfida che il server crittografa con la sua chiave privata, il client può quindi guardare la chiave pubblica del server (che è firmata da una chiave radice nota che la CA (in questo caso DigiCert ) è stato incluso con la maggior parte dei browser). Quando la risposta decodificata corrisponde alla sfida, il client sa che il server ha risposto alla richiesta (anche se potrebbe esserci un intermediario che la inoltra). Il client quindi genera la chiave simmetrica a 256 bit e la crittografa con la chiave pubblica del server e la invia al server. Poiché la chiave è crittografata con la chiave pubblica del server, solo il server (che conosce la chiave privata) può decrittografarla. Ciò significa che qualsiasi intermediario del passaggio precedente non può conoscere la nuova chiave condivisa. Il client ora può fidarsi che qualsiasi informazione inviata tramite la chiave condivisa proviene solo dal server previsto.

15
AJ Henderson

Solo per aggiungere alcuni dettagli alle risposte esistenti ...

la mia domanda è: come potrebbe sapere il client generare una chiave casuale a 256 bit? (Perché non 128?).

Ciò dipende dalla suite di crittografia negoziata. L'elenco di quelli definiti come parte di TLS 1.1 è in RFC 4346 Appendice A.5 . Per esempio TLS_RSA_WITH_AES_128_CBC_SHA utilizzerà una chiave a 128 bit, mentre TLS_DHE_RSA_WITH_AES_256_CBC_SHA utilizzerà una chiave a 256 bit.

La suite di crittografia negoziata dipenderà dalla configurazione del client e del server, non dal certificato installato sul server. Quando il client avvia la connessione con un Client Hello messaggio, invia un elenco di suite di crittografia che supporta. Il server quindi seleziona quello che vuole e lo dice nel suo Server Hello Messaggio.

Questa suite di crittografia determina quindi come queste chiavi simmetriche verranno infine condivise. Lo scopo immediato dell'handshake SSL/TLS è quello di stabilire una condivisione segreto pre-master tra il client e il server. Questo è più ampiamente indicato come scambio di chiavi (vedere RFC 4346 Appendice F.1.1) .

Questo rientra in due categorie (escluso lo scambio di chiavi anonime):

  • Scambio di chiavi RSA (ad es. TLS_RSA_WITH_AES_128_CBC_SHA): il client crittografa il segreto pre-master utilizzando la chiave pubblica del server (presente nel certificato).
  • Scambio chiave DH (E) (ad es. TLS_DHE_RSA_WITH_AES_256_CBC_SHA): ha luogo uno scambio di chiavi Diffie-Hellman. Il server firma i suoi parametri DH e il client verifica la firma sulla chiave pubblica nel certificato del server. (Avere un certificato basato su RSA non implica uno scambio di chiavi RSA.)

Alla fine dell'handshake, qualunque di questi due passaggi siano stati utilizzati, il client e il server sono in possesso di un segreto pre-master comune , da da cui derivano un master secret (vedi RFC 4346 Sezione 8.1 ).

Da quel segreto segreto , entrambe le parti possono derivare le chiavi di crittografia (e i segreti MAC), come descritto in RFC 4346 Sezione 6. .

Oltre al tipo di chiave (RSA o DSS), non esiste nulla che renda la dimensione della chiave di crittografia dipendente dal certificato. Inoltre, entrambi i tipi hanno suite di crittografia che utilizzano chiavi a 256 bit: ad esempio TLS_DHE_DSS_WITH_AES_256_CBC_SHA e TLS_DHE_RSA_WITH_AES_256_CBC_SHA. (DSS è un algoritmo di sola firma, quindi non si otterrebbe uno scambio di chiavi simile a RSA per crittografare il segreto pre-master.)

Le dimensioni della chiave nel certificato sono importanti solo per prevenire la falsificazione dello scambio di chiavi (o per poter decifrare il traffico registrato indietro): se qualcuno fosse in grado di trovare la chiave privata dalla chiave pubblica nel certificato, potrebbero agire come un MITM per impersonare il server reale o sarebbero in grado di decifrare il segreto pre-master crittografato (e quindi il traffico registrato) quando si utilizza uno scambio di chiavi RSA (le suite di crittografia DHE sono progettate con precisione per impedire l'accesso al segreto pre-master , anche se l'attaccante ottiene la chiave privata e il traffico registrato, vedere questa domanda ). Questo è il motivo per cui conta una chiave asimmetrica abbastanza grande.

Le autorità di certificazione tendono a mettere "256 bit" sui loro siti Web perché hanno un bell'aspetto dal punto di vista del marketing.

Non è sbagliato, ma può essere fuorviante per le persone che non capiscono che è importante come è configurato il tuo server e ciò che i tuoi clienti supportano.

9
Bruno