XADM: Come Secure Sockets Layer Works

Traduzione articoli Traduzione articoli
Identificativo articolo: 245152 - Visualizza i prodotti a cui si riferisce l?articolo.
Espandi tutto | Chiudi tutto

In questa pagina

Sommario

In questo articolo viene fornita una panoramica del funzionamento di SSL (Secure Sockets Layer).

Informazioni

Introduzione a crittografia a chiave

Crittografia a chiave pubblica Rivest-Rivest-Shamir-Adleman (RSA) viene ampiamente utilizzato per l'autenticazione e crittografia nel settore informatico. Netscape Ŕ concesso in licenza crittografia RSA a chiave pubblica da RSA Data Security Inc. da utilizzare nei propri prodotti, in particolare per l'autenticazione.

Crittografia a chiave pubblica Ŕ una tecnica che utilizza una coppia di chiavi asimmetriche per la crittografia e decrittografia. Ogni coppia di chiavi Ŕ costituito da una chiave pubblica e una chiave privata. La chiave pubblica Ŕ resa pubblica quando Ŕ distribuito ampiamente. La chiave privata non viene distribuita viene sempre mantenuta segreta.

I dati crittografati con la chiave pubblica possono essere decrittografati solo con la chiave privata. Al contrario, i dati crittografati con la chiave privata possono essere decrittografati solo con la chiave pubblica. Questa asimmetria Ŕ la proprietÓ che rende estremamente utile crittografia a chiave pubblica.

Utilizzo di crittografia a chiave pubblica per l'autenticazione

L'autenticazione Ŕ il processo di verifica dell'identitÓ in modo che un'entitÓ possa essere certi dell'identitÓ di un'altra entitÓ. Negli esempi che seguono, utente A e B utente utilizzare la crittografia a chiave pubblica per verificare l'identitÓ dell'utente B. La notazione seguente indica che un articolo Ŕ stato crittografato o decrittografato utilizzando la crittografia a chiave
{something}key
in cui something Ŕ una descrizione dell'elemento che Ŕ stato crittografato o decrittografato e key Ŕ la chiave utilizzata per crittografare o decrittografare l'elemento.

Nell'esempio riportato di seguito, utente A desidera autenticare l'utente b. utente B dispone di una coppia di chiavi, una pubblica e una privata. L'utente B illustra la chiave pubblica per l'utente A (questo Ŕ stato discusso nella sezione "Gestione degli fuori chiavi pubbliche" di questo articolo). L'utente A genera un messaggio casuale e lo invia utente B nel modo seguente:
A-> Brandom_message
L'utente B utilizza la chiave privata per crittografare il messaggio casuale e restituisce la versione crittografata a utente A:
B-> A {random_message}User_B's_private_key
Utente riceve questo messaggio e lo decrittografa utilizzando la chiave pubblica utente B precedentemente pubblicati. L'utente A confronta il messaggio decrittografato con il messaggio che utente precedentemente inviati utente B; se i messaggi corrispondono, l'utente sa che il messaggio successivo proviene dall'utente B, poichÚ un imposter presumibilmente potrebbe non sapere chiave privata dell'utente B, quindi sarÓ possibile crittografare correttamente il messaggio casuale da inviare per l'utente a.

Ulteriori considerazioni

Se non si conosce esattamente ci˛ che sono crittografia, non Ŕ mai consigliabile crittografare un elemento con la chiave privata e inviarlo a un altro utente. Infatti, possono essere contenuti responsabile per il valore crittografato (tenere presente che, solo Ŕ possibile eseguire la crittografia, in quanto solo Ŕ necessario che la chiave privata).

Per questo motivo, in questo esempio, invece di crittografia del messaggio originale che utente inviato, utente B crea un digest del messaggio e crittografa tale digest del messaggio. Un digest del messaggio Ŕ derivato da casuale messaggio originale e presenta le seguenti proprietÓ utile:
  • Il digest Ŕ difficile da invertire. Un utente che sta tentando di rappresentare l'utente B non pu˛ determinare il messaggio originale dal digest.
  • Un impersonator ha difficoltÓ a individuare un altro messaggio che calcola sullo stesso valore di digest.
L'utente B Ŕ protetto mediante un digest. L'utente B consente di calcolare il digest del messaggio casuale di tale utente inviati e quindi crittografa il risultato. L'utente B invia il digest crittografato all'utente a. utente A pu˛ calcola il digest stesso e l'autenticazione utente B, la decrittografia del messaggio dell'utente B e confrontare i valori.

Origine dati per l'autenticazione

La tecnica descritta nella sezione "Ulteriori considerazioni sulla" di questo articolo tratta di una firma digitale. Questa tecnica richiede che utente B firmare un messaggio che utente generato; questo Ŕ quasi pericoloso per l'utente B come la crittografia di un valore casuale che ha avuto origine con l'utente a. Di conseguenza, questo protocollo di autenticazione di esempio Ŕ necessario un passaggio pi¨ al sicuro; utente B deve derivano alcuni o tutti i dati come indicato di seguito:
A-> B B-> di hello, da cui si utente B? L'utente A, questa Ŕ l'utente B {digest[L'utente A, questa Ŕ l'utente B]} User_B's_private_key
Quando l'utente B utilizza questo protocollo, utente B sa quale messaggio inviata al utente e pertanto utente B in modo sicuro possibile firmare il messaggio. L'utente B invia in primo luogo, la versione del messaggio non crittografata "utente, questo Ŕ l'utente B," e quindi l'utente B invia la versione crittografata digested. L'utente A facilmente possibile verificare che utente B Ŕ l'utente B e utente B non Ŕ necessario firmare tutto ci˛ che non ha avuto origine con l'utente b.

Gestione fuori chiavi pubbliche

Come un utente pu˛ invece da una chiave pubblica in modo sicuro? Seguito Ŕ riportato un protocollo di autenticazione di esempio per B: utente
A-> B-> UN A-> B-> A
Hello Ciao, mi utente B, User_B's_public_key dimostrare che l'utente A, questo Ŕ
L'utente B {digest [utente, questo Ŕ utente B]} User_B's_private_key
Se questo protocollo viene utilizzato, chiunque pu˛ rappresentare l'utente b. Tutti un imposter Ŕ necessario una chiave di pubblica e privata. Un imposter pu˛ trovarsi a un utente e rappresentare l'utente B, fornendo la chiave pubblica del imposter invece di chiave pubblica dell'utente B. Quindi il imposter "dimostra" che il imposter Ŕ qualcosa di crittografia utilizzando chiave privata del imposter l'utente B, e non utente possibile stabilire che il imposter non utente b.

Per risolvere il problema, la comunitÓ standard ha inventato un oggetto denominato un certificato. Un certificato contiene le seguenti informazioni:
  • Il nome dell'autoritÓ emittente del certificato.
  • EntitÓ per cui Ŕ stata emessa il certificato, (noto anche come oggetto).
  • La chiave pubblica del soggetto.
  • Alcuni timestamp.
Il certificato firmato mediante la chiave privata dell'autoritÓ emittente del certificato. Tutti sanno che la chiave pubblica dell'autoritÓ emittente del certificato (il che significa, autoritÓ emittente del certificato anche avrÓ un certificato). I certificati sono un metodo standard per associare una chiave pubblica a un nome.

Se viene utilizzata la tecnologia di certificato, tutti gli utenti pu˛ esaminare dell'utente B certificato per verificare se il certificato Ŕ stato contraffatti. Se utente B ottiene effettivamente il certificato e utente B consente di mantenere uno stretto controllo della chiave privata, la tecnologia di certificato Ŕ protetta. Di seguito Ŕ riportato il protocollo corretto utilizzando questa tecnica:
A-> B B-> un A-> B B-> A hello ad, mi utente BUser_B's_certificate dimostrare
tale utente, questo Ŕ utente B {digest [utente, questo Ŕ utente B]} User_B's_private_key
Quando l'utente riceve primo messaggio dell'utente B, utente A pu˛ esaminare il certificato, controllare la firma (come nell'esempio precedente, utilizzando un digest e la decrittografia della chiave pubblica) e quindi selezionare l'oggetto (vale a dire il nome dell'utente B) e notare che in realtÓ Ŕ utente b. utente pu˛ quindi trust che la chiave pubblica Ŕ la chiave pubblica dell'utente B e pu˛ richiedere la prova dell'identitÓ dell'utente B.

L'utente B passa attraverso lo stesso processo, come descritto in dell'esempio precedente, progettando un digest del messaggio e quindi rispondere a utente con una versione firmata del digest. L'utente A Ŕ possibile verificare dell'utente B digest del messaggio utilizzando la chiave pubblica dal certificato e controllare il risultato.

Per creare il seguente scenario per tentare di eseguire questa operazione Ŕ possibile utilizzare una persona che desideri interferire con comunicazioni protette (in questo esempio, utente C):
A-> C C-> un A-> C C-> A hello ad, mi utente BUser_B's_certificate dimostrare
Ŕ????
Tuttavia, utente C non pu˛ soddisfare utente nel messaggio finale. Utente C non dispone di chiave privata dell'utente B, pertanto l'utente C non pu˛ creare un messaggio utente crederÓ proviene da un utente b.

Lo scambio di un segreto

Dopo l'utente Ŕ autenticato l'utente B, utente A Ŕ possibile inviare utente B, un messaggio che solo l'utente B pu˛ decodificare come indicato di seguito
A-> B {secret}User_B's_public_key
in cui l'unico modo per determinare il secret consiste decrittografando il messaggio con chiave privata dell'utente B. Lo scambio di un segreto Ŕ un altro metodo di efficace per utilizzare la crittografia a chiave pubblica. Anche se si osserva la comunicazione tra utente e l'utente B, nessuno ma l'utente B possibile determinare la le informazioni segrete.

Questa tecnica consente di rafforzare protezione Internet, utilizzando il segreto come un altro tasto, ma in questo caso Ŕ una chiave per un algoritmo di crittografia simmetrico, ad esempio DES (Data Encryption Standard), RC4 o IDEA. Utente conosce il segreto poichÚ utente che ha generato il segreto prima di inviarlo a un utente b. utente B conosce il segreto perchÚ utente B dispone della chiave privata e pu˛ decrittografare il messaggio dell'utente. PoichÚ sia utente A e B utente conosce il segreto, pu˛ avviare un algoritmo di crittografia simmetrica sia quindi inviare messaggi crittografati con l'algoritmo di crittografia simmetrica. Di seguito Ŕ un protocollo rivisto utilizza questa tecnica:
A-> B B-> un A-> B B-> un A-> B B-> A hello ad, mi utente BUser_B's_certificate
dimostrare che l'utente A, questo Ŕ utente B {digest [utente, questo Ŕ utente B]} User_B's_private_key
OK utente B di seguito Ŕ un segreto {secret} User_B's_public_key {some_message} secret_key
Il metodo utilizzato per calcolare secret_key Ŕ il protocollo viene definito, ma secret_key semplicemente pu˛ essere una copia del segreto.

Interferenza di protezione

Anche se tutte le tecniche precedente vengono utilizzate, una persona che desidera interferire con comunicazioni protette (utente C) possibile a questo scopo. Sebbene l'utente C non Ŕ in grado di individuare il segreto utente A e utente B sono stati scambiati, utente C possono interferire con la conversazione da re-arranging (o garbling) le informazioni segrete. Ad esempio se l'utente C si trova tra utente e utente B, utente C pu˛ passare la maggior parte delle invariato e viceversa informazioni ma garble determinati messaggi (questo Ŕ facile per utente C perchÚ l'utente C conosce il protocollo di tale utente e l'utente B utilizza per comunicare):
A-> C C-> B-> C, C-> UN A-> C C-> B-> C, C-> UN A-> C C-> B-> C, C-> A
Salve hello Ciao, mi utente B, User_B's_certificate Hi, mi utente B
User_B's_certificatedimostrare dimostrare che l'utente A, questa Ŕ l'utente {digest [utente A, B
Questo Ŕ utente B]} User_B's_private_key A, questo Ŕ utente B {digest [utente, questo utente
L'utente B]} User_B's_private_key ok utente B, di seguito Ŕ un segreto {secret} User_B's_public_key
OK utente B di seguito Ŕ un segreto {secret} User_B's_public_key {some_message} secret_key
Garble [{some_message} secret_key]
Utente C passa i dati senza alcuna modifica finchÚ l'utente A e B utente condividono un segreto. Quindi l'utente C garbles messaggio postale utente a. A questo punto, trust utente A utente B, in questo caso utente Ŕ in potrebbe di ritiene che il messaggio confuso e tentare di agire su esso. Nota che utente C non riconosce il segreto; procedere tutti utente C Ŕ danno i dati crittografati con la chiave segreta. A seconda del protocollo utente C non pu˛ produrre un messaggio valido, ma utente C possono ottenere fortunata e produrre un messaggio valido.

Per evitare questo tipo di danno, utente A e utente B pu˛ introdurre un codice di autenticazione del messaggio nel relativo protocollo. Un codice di autenticazione del messaggio Ŕ un componente di dati che viene calcolati utilizzando i dati un segreti e alcuni trasmessi. L'algoritmo digest descritto in precedenza include solo le proprietÓ a destra per la creazione di una funzione di codice di autenticazione messaggio che Ŕ possibile difendersi da utente C:
message_authentication_code: = digest [some_message, secret]
PerchÚ utente C non riconosce il segreto, utente C Impossibile calcolare il valore corretto per il digest. Anche se l'utente C garbles in modo casuale i messaggi, la probabilitÓ di successo Ŕ limitata se Ŕ presente una grande quantitÓ di digest dati. Utilizzando ad esempio, MD5 (un algoritmo digest crittografia buona inventato da RSA), utente A e utente B possibile inviare il messaggio a 128 bit i valori di codice di autenticazione con i messaggi. Le probabilitÓ di utente C indovinare il corretto codice di autenticazione sono di circa 1 in 18,446,744,073,709,551,616. Per tutti i motivi pratici, utente C Impossibile indovinare il codice di autenticazione corretto.

Di seguito Ŕ riportato il protocollo di esempio, modificato nuovamente per utilizzare questa tecnica:
A-> B B-> un A-> B B-> A hello ad, mi utente BUser_B's_certificate dimostrare
tale utente, questo Ŕ utente B {digest [utente, questo Ŕ utente B]} User_B's_private_key ok
Utente B, di seguito Ŕ un segreto {secret} User_B's_public_key {some_message, message_authentication_code} secret_key
Possibile tenta di utente C garble messaggi, ma i calcoli eseguiti codice di autenticazione messaggio rivelano che i messaggi non vengono forniti dall'utente b. utente o utente B pu˛ individuare il valore di codice di autenticazione messaggio non corretto e interrompere la comunicazione. Utente C non pu˛ rappresentare utente b.

ProprietÓ

Identificativo articolo: 245152 - Ultima modifica: sabato 28 ottobre 2006 - Revisione: 3.3
Le informazioni in questo articolo si applicano a:
  • Microsoft Exchange Server 4.0 Standard Edition
  • Microsoft Exchange Server 5.0 Standard Edition
  • Microsoft Exchange Server 5.5 Standard Edition
Chiavi:á
kbmt kbinfo KB245152 KbMtit
Traduzione automatica articoli
Il presente articolo Ŕ stato tradotto tramite il software di traduzione automatica di Microsoft e non da una persona. Microsoft offre sia articoli tradotti da persone fisiche sia articoli tradotti automaticamente da un software, in modo da rendere disponibili tutti gli articoli presenti nella nostra Knowledge Base nella lingua madre dell?utente. Tuttavia, un articolo tradotto in modo automatico non Ŕ sempre perfetto. Potrebbe contenere errori di sintassi, di grammatica o di utilizzo dei vocaboli, pi¨ o meno allo stesso modo di come una persona straniera potrebbe commettere degli errori parlando una lingua che non Ŕ la sua. Microsoft non Ŕ responsabile di alcuna imprecisione, errore o danno cagionato da qualsiasi traduzione non corretta dei contenuti o dell?utilizzo degli stessi fatto dai propri clienti. Microsoft, inoltre, aggiorna frequentemente il software di traduzione automatica.
Clicca qui per visualizzare la versione originale in inglese dell?articolo: 245152
LE INFORMAZIONI CONTENUTE NELLA MICROSOFT KNOWLEDGE BASE SONO FORNITE SENZA GARANZIA DI ALCUN TIPO, IMPLICITA OD ESPLICITA, COMPRESA QUELLA RIGUARDO ALLA COMMERCIALIZZAZIONE E/O COMPATIBILITA' IN IMPIEGHI PARTICOLARI. L'UTENTE SI ASSUME L'INTERA RESPONSABILITA' PER L'UTILIZZO DI QUESTE INFORMAZIONI. IN NESSUN CASO MICROSOFT CORPORATION E I SUOI FORNITORI SI RENDONO RESPONSABILI PER DANNI DIRETTI, INDIRETTI O ACCIDENTALI CHE POSSANO PROVOCARE PERDITA DI DENARO O DI DATI, ANCHE SE MICROSOFT O I SUOI FORNITORI FOSSERO STATI AVVISATI. IL DOCUMENTO PUO' ESSERE COPIATO E DISTRIBUITO ALLE SEGUENTI CONDIZIONI: 1) IL TESTO DEVE ESSERE COPIATO INTEGRALMENTE E TUTTE LE PAGINE DEVONO ESSERE INCLUSE. 2) I PROGRAMMI SE PRESENTI, DEVONO ESSERE COPIATI SENZA MODIFICHE, 3) IL DOCUMENTO DEVE ESSERE DISTRIBUITO INTERAMENTE IN OGNI SUA PARTE. 4) IL DOCUMENTO NON PUO' ESSERE DISTRIBUITO A SCOPO DI LUCRO.
Dichiarazione di non responsabilitÓ per articoli della Microsoft Knowledge Base su prodotti non pi¨ supportati
Questo articolo Ŕ stato scritto sui prodotti per cui Microsoft non offre pi¨ supporto. L?articolo, quindi, viene offerto ?cosý come Ŕ? e non verrÓ pi¨ aggiornato.

Invia suggerimenti

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com