it-swarm-eu.dev

Come funzionano i processi per certificati digitali, firme e SSL?

Ho cercato di capire come funziona ssl. Invece di Alice e Bob, consideriamo la comunicazione client e server. Il server ha un certificato digitale acquisito da una CA. Ha anche chiavi pubbliche e private. Il server desidera inviare un messaggio al client. La chiave pubblica del server è già disponibile per il client.

Supponendo che la stretta di mano ssl sia completata.

Server to Client:

  • Il server allega la sua chiave pubblica al messaggio.
  • Esegue la funzione hash su (messaggio + chiave pubblica). I risultati sono noti come HMAC.
  • Crittografa HMAC usando la sua chiave privata. Il risultato si chiama firma digitale.
  • Invialo al cliente insieme al certificato digitale.
  • Il client controlla il certificato e rileva che proviene dal server previsto.
  • Decodifica HMAC utilizzando la chiave pubblica del server.
  • Esegue la funzione hash su (messaggio + chiave pubblica) per ottenere il messaggio originale.

da client a server

  • Il client esegue la funzione hash su (messaggio + chiave pubblica) e quindi esegue la crittografia utilizzando la stessa chiave pubblica.
  • Il server decodifica utilizzando la chiave privata, esegue la funzione hash sui dati risultanti per ottenere il messaggio.

Per favore fatemi sapere se la mia comprensione è corretta.

27
John

Ci sono alcune confusioni nel tuo post. Prima di tutto, HMAC non è un funzione hash . Maggiori informazioni su HMAC in seguito.

Funzioni hash

A hash function è un algoritmo completamente pubblico (nessuna chiave in questo) che combina bit in un modo che è davvero impossibile districare: chiunque può eseguire la funzione hash su qualsiasi dato, ma trovando il i dati provenienti dall'output di hash sembrano essere molto al di là del nostro spirito. L'output hash ha una dimensione fissa, in genere 256 bit (con SHA-256) o 512 bit (con SHA-512). La funzione SHA- * che emette 160 bit si chiama SHA-1, non SHA-160, perché i crittografi lasciati ai propri dispositivi possono rimanere ragionevoli solo per così tanto tempo, e certamente non oltre la quinta pinta.

Algoritmi di firma

Un algoritmo A firma usa una coppia di chiavi, che sono matematicamente collegate tra loro, la chiave privata e la chiave pubblica ( ricalcolare la chiave privata dalla chiave pubblica è teoricamente fattibile ma troppo difficile da fare in pratica, anche con Really Big Computers, motivo per cui la chiave pubblica ed essere resa pubblica mentre la chiave privata rimane privata). Utilizzando la struttura matematica delle chiavi, l'algoritmo della firma consente di:

  • a generate una firma su alcuni dati di input, usando la chiave privata (la firma è un oggetto matematico che è ragionevolmente compatto, ad esempio alcune centinaia di byte per una tipica firma RSA);
  • a verifica una firma su alcuni dati di input, usando la chiave pubblica. La verifica accetta come parametri la firma, i dati di input e la chiave pubblica e restituisce "perfetto, amico!" o "amico, questi non corrispondono".

Per un algoritmo di firma sicura, è presumibilmente impossibile produrre un valore di firma e inserire dati in modo tale che l'algoritmo di verifica con una determinata chiave pubblica dica "buono", salvo conosci la chiave privata corrispondente, nel qual caso è facile ed efficiente. Nota la stampa fine: senza la chiave privata, non puoi evocare alcuni dati e un valore di firma che funziona con la chiave pubblica, anche se puoi scegliere i dati e la firma come desideri.

"Presumibilmente irrealizzabile" significa che tutti i crittografi intelligenti del mondo ci hanno lavorato per diversi anni e tuttavia non hanno trovato il modo di farlo, anche dopo la quinta pinta.

La maggior parte (in realtà, tutti) gli algoritmi di firma iniziano elaborando i dati di input con una funzione hash, quindi funzionano solo sul valore hash. Questo perché l'algoritmo di firma ha bisogno di oggetti matematici in alcuni insiemi di dimensioni limitate, quindi devono lavorare su valori "non troppo grandi", come l'output di una funzione hash. A causa della natura della funzione hash, le cose funzionano bene (firmare l'output hash è buono come firmare l'input hash).

Scambio di chiavi e crittografia asimmetrica

A key exchange protocol è un protocollo in cui entrambe le parti si lanciano oggetti matematici l'uno contro l'altro, ogni oggetto potrebbe essere collegato con alcuni valori segreti che mantengono per loro, in un modo molto simile al pubblico/coppie di chiavi private. Alla fine dello scambio di chiavi, entrambe le parti possono calcolare un "valore" comune (l'ennesimo oggetto matematico) che sfugge totalmente alla presa di chiunque abbia osservato i bit scambiati sul filo. Un tipo comune di algoritmo di scambio chiavi è crittografia asimmetrica. La crittografia asimmetrica utilizza una coppia di chiavi pubblica/privata (non necessariamente dello stesso tipo di un algoritmo di firma):

  • Con la chiave pubblica puoi crittografare un dato. Tali dati hanno generalmente dimensioni limitate (ad es. Non più di 117 byte per RSA con una chiave pubblica a 1024 bit). Il risultato della crittografia è, indovina, un oggetto matematico che può essere codificato in una sequenza di byte.
  • Con la chiave privata, è possibile decrittografare, ovvero eseguire l'operazione inversa e recuperare i dati di input iniziali. Si presume che senza la chiave privata, buona fortuna.

Quindi il protocollo di scambio di chiavi funziona così: una parte sceglie un valore casuale (una sequenza di byte casuali), lo crittografa con la chiave pubblica del peer e glielo invia. Il peer usa la sua chiave privata per decrittografare e recupera il valore casuale, che è il segreto condiviso.

Una spiegazione storica delle firme è: "crittografia con la chiave privata, decodifica con la chiave pubblica". Dimentica questa spiegazione. È sbagliato. Può essere vero solo per un algoritmo specifico (RSA) e, di nuovo, solo per una versione bastardata di RSA che in realtà non riesce a garantire una sicurezza decente. Quindi no , le firme digitali non sono la crittografia asimmetrica "al contrario".

Crittografia simmetrica

Una volta che due parti hanno un valore segreto condiviso, possono utilizzare crittografia simmetrica per scambiare ulteriori dati in modo confidenziale. Si chiama simmetrico perché entrambe le parti hanno la stessa chiave, cioè la stessa conoscenza, cioè la stessa potenza. Niente più dicotomia privata/pubblica. Vengono utilizzati due primitivi:

  • Crittografia simmetrica : come manipolare i dati e districarli in seguito.
  • Codici di autenticazione dei messaggi : un "checksum con chiave": solo le persone che conoscono la chiave segreta possono calcolare il MAC su alcuni dati (è come un algoritmo di firma in cui la chiave privata e pubblica sono identiche, quindi la chiave "pubblica" è meglio che non sia pubblica!).

HMAC è un tipo di MAC che si basa su funzioni hash in modo intelligente, perché ci sono molti modi non intelligenti per farlo, e che falliscono a causa di dettagli sottili su ciò che fornisce una funzione hash e NON fornisce.

Certificati

A certificate è un contenitore per una chiave pubblica. Con gli strumenti spiegati sopra, si può iniziare a immaginare che il server disporrà di una chiave pubblica, che il client utilizzerà per effettuare uno scambio di chiavi con il server. Ma come fa il client a assicurarsi che stia usando la chiave pubblica del server giusto e non quella di un subdolo aggressore, un malvagio che impersona astutamente il server? È qui che entrano in gioco i certificati. Un certificato è firmato da qualcuno specializzato nella verifica delle identità fisiche; si chiama a Autorità di certificazione. La CA incontra il server "nella vita reale" (ad es. In una barra), verifica l'identità del server, ottiene la chiave pubblica del server dal server stesso e firma l'intero lotto (identità del server e chiave pubblica). Ciò si traduce in un bundle elegante che si chiama un certificato. Il certificato rappresenta la garanzia da parte della CA che il nome e la chiave pubblica coincidono (si spera che la CA non sia troppo credulona, ​​quindi la garanzia è affidabile - preferibilmente, la CA fa not firma i certificati dopo la sua quinta pinta).

Il client, dopo aver visto il certificato, può verificare la firma sul certificato relativamente alla chiave pubblica della CA e quindi acquisire la sicurezza che la chiave pubblica del server appartiene realmente al server previsto.

Ma, mi diresti, cosa abbiamo guadagnato? Dobbiamo ancora conoscere una chiave pubblica, ovvero la chiave pubblica della CA. Come possiamo verificarlo? Bene, possiamo usare un altro CA. Questo sposta semplicemente il problema, ma può finire con il problema di conoscere a priori un unico o una manciata di chiavi pubbliche di über-CA che non sono firmate da nessun altro. Tuttavia, Microsoft ha incorporato circa un centinaio di tali "chiavi pubbliche di root" (chiamate anche "ancoraggi di fiducia") all'interno di Internet Explorer stesso. È qui che nasce la fiducia (precisamente, hai rinunciato alla base della tua fiducia alla ditta Redmond - ora capisci come Bill Gates è diventato il ragazzo più ricco del mondo?).

[~ ~ #] ssl [~ ~ #]

Ora mettiamo tutto insieme, nel protocollo SSL, che ora è noto come TLS ("SSL" era il nome del protocollo quando era una proprietà di Netscape Società).

Il client desidera parlare con il server. Invia un messaggio ("ClientHello") che contiene un mucchio di dati amministrativi, come l'elenco di algoritmi di crittografia supportati dal client.

Il server risponde ("ServerHello") indicando quali algoritmi verranno utilizzati; quindi il server invia il proprio certificato ("Certificato"), possibilmente con alcuni certificati CA nel caso in cui il client possa averne bisogno (non certificati root, ma certificati intermedi, under-CA).

Il client verifica il certificato del server ed estrae la chiave pubblica del server da esso. Il client genera un valore casuale ("segreto pre-master"), lo crittografa con la chiave pubblica del server e invia quello al server ("ClientKeyExchange").

Il server decodifica il messaggio, ottiene il pre-master e ne ricava chiavi segrete per crittografia simmetrica e MAC. Il client esegue lo stesso calcolo.

Il client invia un messaggio di verifica ("Finished") che è crittografato e MACed con le chiavi derivate. Il server verifica che il messaggio Finished sia corretto e invia il proprio messaggio "Finished" in risposta. A quel punto, sia il client che il server dispongono di tutte le chiavi simmetriche di cui hanno bisogno e sanno che la "stretta di mano" è riuscita. I dati dell'applicazione (ad es. Una richiesta HTTP) vengono quindi scambiati, utilizzando la crittografia simmetrica e MAC.

Non vi è alcuna chiave pubblica o certificato coinvolto nel processo oltre la stretta di mano. Solo crittografia simmetrica (ad esempio 3DES, AES o RC4) e MAC (normalmente HMAC con SHA-1 o SHA-256).

38
Tom Leek

Dopo molta lotta. Di seguito ho compreso le differenze tra SSL, crittografia a chiave asimmetrica, certificato digitale (DC) e firma digitale (DS).

Che cos'è il certificato digitale, noto anche come certificato a chiave pubblica?

DC è un documento elettronico che utilizza una firma digitale per associare una chiave pubblica con informazioni di identità come nome, indirizzo, ecc

Contenuto del certificato: Certificato a chiave pubblica

L'essere più importante è l'algoritmo della firma, l'emittente e la chiave pubblica.

Che cos'è una crittografia a chiave asimmetrica e una firma digitale?

Spiegato per mezzo di un esempio.

Entrambe le macchine hanno una coppia di chiavi crittografiche: una chiave di crittografia pubblica e una chiave di decrittografia privata.

Machine-A ha accesso alla chiave pubblica e al certificato di Machine-B.
Machine-B ha accesso alla chiave pubblica e al certificato di Machine-A.

Dalla macchina A alla macchina B

Alla macchina A:

  • Hash_function (Data) = Hash
  • Crittografa (hash) usando la chiave privata di Machine-A = DS
  • Allega dati a DS e DC = Data + DS + DC
  • Crittografa (Dati + DS + DC) usando la chiave pubblica di Machine-B.
  • Invia a Machine-B.

Alla macchina B:

  • Decifrare (Dati + DS + DC) usando la chiave privata di Machine-B.
  • Verifica DC per autenticare la macchina-A.
  • Decifrare (DS) usando la chiave pubblica di Machine-A = Hash # 1
  • Hash_function (Data) = Hash # 2
  • if (Hash # 1 == Hash # 2) I dati e la firma sono validi.

Dalla macchina B alla macchina A

Il processo ora è esattamente il contrario di quanto sopra.

Che cos'è SSL/TLS?

Il protocollo TLS consente alle applicazioni client/server di comunicare attraverso una rete in un modo progettato per prevenire intercettazioni e manomissioni. Nella maggior parte delle comunicazioni client-server, solo il server deve essere autenticato. TLS semplifica la crittografia della chiave asimmetrica per sfruttare efficacemente questo fenomeno. Secure Sockets Layer

Esempio di client e server.

Il server ha un certificato digitale acquisito da una CA. Ha anche chiavi pubbliche e private.

L'utente fa clic su un URL che inizia con

https: //

Per questa sessione è necessaria una connessione sicura. Il browser stabilisce una TCP connessione su HTTPS TCP porta 443.

  1. Client> Server: SYN
  2. Client <Server: SYN + ACK
  3. Client> Server: ACK

    Handshake SSL su new TCP:

  4. Client> Server: CLIENT_HELLO

    Il client invia un comando CLIENT_HELLO al server, che include:

    • La versione SSL e TLS più alta supportata dal client.
    • Cifre supportate dal client. Le cifre sono elencate in ordine di preferenza.
    • Metodi di compressione dei dati supportati dal client.
    • L'ID sessione. Se il client sta avviando una nuova sessione SSL, l'ID sessione è 0.
    • Dati casuali generati dal client per l'utilizzo nel processo di generazione delle chiavi.
  5. Client <Server: SERVER_HELLO

    Il server invia un comando SERVER_HELLO al client, che include:

    • La versione SSL o TLS che verrà utilizzata per la sessione SSL.
    • Il codice che verrà utilizzato per la sessione SSL.
    • Metodo di compressione dei dati che verrà utilizzato per la sessione SSL.
    • L'ID sessione per la sessione SSL.
    • Dati casuali generati dal server per l'utilizzo nel processo di generazione delle chiavi.
  6. Client <Server: CERTIFICATO (TASTO PUBBLICO)

    Il server invia il comando CERTIFICATE. Include il certificato del server.

  7. Client <Server: SERVER_DONE

    Il server invia il comando SERVER_DONE. Questo comando indica che il server ha completato questa fase dell'handshake SSL.

  8. Client> Server: CERTIFICATE_VERIFY

    Il client informa il server che ha verificato il certificato del server

  9. Client> Server:

    Utilizzando tutti i dati generati finora nell'handshake, il client (con la collaborazione del server, a seconda del codice utilizzato) crea il segreto pre-master per la sessione, lo crittografa con la chiave pubblica del server (ottenuta dal certificato del server ), quindi invia al server il segreto pre-master crittografato.

    Il server utilizza la sua chiave privata per decrittografare il segreto pre-master, quindi esegue una serie di passaggi per generare il segreto master.

    Il client esegue anche la stessa serie di passaggi sul segreto pre-master per generare lo stesso segreto master.

    Nota: nelle situazioni in cui il client deve essere autenticato, il client firma anche un'altra porzione di dati unica per questa stretta di mano e conosciuta sia dal client che dal server. In questo caso, il client invia al server sia i dati firmati sia il proprio certificato insieme al segreto pre-master crittografato.

  10. Client <> Server:

    Sia il client che il server utilizzano il segreto master per generare le chiavi di sessione, che sono chiavi simmetriche utilizzate per crittografare e decrittografare le informazioni scambiate durante la sessione SSL e per verificarne l'integrità.

    Nota: d'ora in poi è la crittografia della chiave simmetrica.

  11. Client> Server:

    Il client invia un messaggio al server informandolo che i messaggi futuri dal client verranno crittografati con la chiave di sessione.

  12. Client> Server: FINITO

    Il client invia quindi un messaggio separato (crittografato) che indica che la parte dell'handshake è terminata.

  13. Client <Server:

    Il server invia un messaggio al client informandolo che i messaggi futuri dal server verranno crittografati con la chiave di sessione.

  14. Client <Server: FINITO

    Il server invia un messaggio separato (crittografato) che indica che la parte dell'handshake è terminata.

    L'handshake SSL è ora completo e inizia la sessione. Il client e il server utilizzano le chiavi di sessione per crittografare e decrittografare i dati che si scambiano e per convalidarne l'integrità.

4
John

Per una spiegazione più dettagliata "sotto il cofano", posso anche suggerire il seguente articolo: I primi pochi millisecondi di una connessione HTTPS di Jeff Moser. L'articolo utilizza acquisizioni di pacchetti di una sessione di comunicazione HTTPS per illustrare come funziona il protocollo. È interessante vedere le cose di cui stiamo parlando in azione e cancella molti punti "oscuri".

2
George

Non proprio; i certificati entrano in gioco solo durante l'handshake SSL iniziale o durante una rinegoziazione SSL. Successivamente, verrà utilizzato un codice simmetrico come AES, (3) DES o RC4. La crittografia a chiave pubblica è generalmente più costosa della crittografia simmetrica, quindi viene generalmente utilizzata per concordare una chiave simmetrica all'inizio.

1
Steve Dispensa