XADM: Como Secure Sockets Layer Works

Traduções de Artigos Traduções de Artigos
Artigo: 245152 - Ver produtos para os quais este artigo se aplica.
Expandir tudo | Reduzir tudo

Nesta página

Sumário

Este artigo fornece uma descrição geral do funcionamento (Secure Sockets Layer).

Mais Informação

Uma introdução à chave de criptografia

Criptografia de chave pública Rivest-Shamir-Adleman (RSA) é amplamente utilizada para autenticação e encriptação na indústria informática. Netscape foi licenciado RSA criptografia de chave pública pela RSA Data Security Inc. para utilizar nos respectivos produtos, especificamente para autenticação.

Encriptação de chave pública é uma técnica que utiliza um par de chaves assimétricas para encriptação e desencriptação. Cada par de chaves é constituído por uma chave pública e uma chave privada. A chave pública é efectuada público quando é distribuída bastante. A chave privada nunca é distribuída; é sempre mantida secreta.

Dados que esteja encriptados com a chave pública só podem ser desencriptados com a chave privada. Por outro lado, podem ser desencriptados dados encriptados com a chave privada apenas com a chave pública. Este assimetria é a propriedade que torna a criptografia de chave pública tão útil.

Utilizar criptografia de chave pública para autenticação

A autenticação é o processo de verificar a identidade, de modo a que uma entidade pode ter a certeza da identidade de outra entidade. Nos exemplos seguintes, o utilizador A e B do utilizador utilizam criptografia de chave pública para verificar identidade do utilizador B. A notação seguinte indica que um item foi encriptada ou desencriptada utilizando criptografia de chave
{something}key
onde é something uma descrição do item que tenha sido encriptada ou desencriptada e key é a chave utilizada para encriptar ou desencriptar esse item.

No exemplo seguinte, um utilizador pretende autenticar utilizador B. utilizador B tem um par de chaves, uma pública e privada de um. O utilizador B revela a chave pública para o utilizador A (isto é abordado na secção "Entrega sem chaves públicas" deste artigo). O utilizador A gera uma mensagem aleatória e envia-lo para o utilizador B da seguinte forma:
UM-> Brandom_message
O utilizador B utiliza a chave privada para encriptar a mensagem aleatória e devolve versão encriptada ao utilizador A:
B-> A {random_message}User_B's_private_key
O utilizador A recebe esta mensagem e desencripta utilizando a chave pública que o utilizador B publicado anteriormente. O utilizador A compara a mensagem desencriptada com a mensagem que o utilizador originalmente enviada para o utilizador B; se as mensagens correspondem A, o utilizador A sabe se a mensagem posterior provém do utilizador B, uma vez que um impostor provavelmente não saberá chave privada do utilizador B, pelo que poderia ser capaz correctamente encriptar a mensagem aleatória para enviar ao utilizador a.

Considerações adicionais

A menos que saiba exactamente o está a encriptar, nunca é uma boa ideia encriptar algo com a chave privada e, em seguida, enviá-la para outra pessoa. Isto acontece porque o pode ser mantida responsável pelo valor codificado (Lembre-se de que só é possível efectuar a encriptação porque só tem a chave privada).

Devido a isto, neste exemplo, em vez de encriptar a mensagem original esse utilizador A enviar, o utilizador B constrói um resumo de mensagens e encripta esse resumo de mensagens. Um resumo de mensagens é derivado da mensagem original aleatória e tem as seguintes propriedades útil:
  • É difícil inverter o resumo. Alguém está a tentar representar o utilizador B não consegue determinar a mensagem original o resumo.
  • Um impersonator tem dificuldade em localizar uma mensagem diferente que calcula o mesmo valor de resumo.
O utilizador B está protegido utilizando uma autenticação implícita. Utilizador B calcula o resumo da mensagem aleatório esse utilizador A enviar e, em seguida, encripta o resultado. O utilizador B envia o resumo encriptado regressar ao utilizador a. utilizador A pode calcular o mesmo resumo e autenticar o utilizador B desencriptar a mensagem do utilizador B e comparar os valores.

Dados de origem para a autenticação

A técnica descrita na secção "Considerações adicionais" deste artigo é conhecida como uma assinatura digital. Esta técnica requer que o utilizador B assinar uma mensagem desse utilizador A gerado; isto é quase como perigoso para o utilizador B como encriptar um valor aleatório que foi criada com o utilizador a. Consequentemente, este protocolo de autenticação de exemplo tem mais um passo seja segura; utilizador B tem têm na totalidade (ou) dos dados da seguinte forma:
São A-> B B-> A saudação, que o utilizador B? O utilizador A, este é o utilizador B {digest[Utilizador, este é o utilizador B]} User_B's_private_key
Quando o utilizador B utiliza este protocolo, utilizador B sabe que mensagem está a ser enviada utilizador A e, por isso, utilizador B com segurança pode assinar a mensagem. O utilizador B envia a versão da mensagem não encriptado em primeiro lugar, "utilizador A, este é o utilizador B," e, em seguida, o utilizador B envia versão digested encriptado. O utilizador A pode facilmente Verifique se utilizador B é o utilizador B e utilizador B não é necessário iniciar sessão tudo o que não provenham com o utilizador B.

Entrega sem chaves públicas

Como pode um utilizador mão sem uma chave pública de modo seguro? Segue-se um protocolo de autenticação de exemplo para B: utilizador
UM-> B B-> UM UM-> B B-> A
Olá alta, estou utilizador B User_B's_public_key provar utilizador A, este é
O utilizador B {digest [utilizador A, este é utilizador B]} User_B's_private_key
Se for utilizado este protocolo, qualquer pessoa pode representar o utilizador B. Um impostor todas as necessidades é uma chave pública e privada. Um impostor pode situar-se para o utilizador A e representar o utilizador B fornecendo a chave pública do impostor em vez de chave pública do utilizador B. Em seguida, o impostor "prova" que o impostor é utilizador B através da encriptação algo, utilizando chave privada o impostor, e utilizador A não é possível saber que o impostor não é utilizador B.

Para resolver este problema, a comunidade de padrões tem inventado objecto denominado um certificado. Um certificado contém as seguintes informações:
  • O nome do emissor do certificado.
  • A entidade para o qual o certificado está a ser emitido (também conhecido como o requerente).
  • A chave pública do requerente.
  • Algumas marcas de hora.
O certificado é assinado utilizando a chave privada do certificado de emissor. Todos saibam a chave pública do emissor de certificado (ou seja, o emissor de certificado também tem um certificado). Certificados são um método padrão para ligar uma chave pública a um nome.

Se for utilizada a tecnologia de certificado, todos os utilizadores podem examinar o utilizador B certificado para ver se o certificado tiver sido falsificado. Se mantém o utilizador B controlo apertado da chave privada e o utilizador B, na realidade, obtém o certificado, a tecnologia de certificado é segura. Segue-se o protocolo alterado utilizando esta técnica:
A-> B B-> uma A-> B B-> de hello alta, estou utilizador BUser_B's_certificate provar
Este utilizador A, este é utilizador B {digest [utilizador A, este é utilizador B]} User_B's_private_key
Quando o utilizador A recebe primeira mensagem do utilizador B, o utilizador A pode examinar o certificado, verificar a assinatura (como no exemplo anterior, utilizando um resumo e desencriptação de chave pública) e, em seguida, verificar o requerente (isto é, o nome de utilizador B) e constatará que é realmente utilizador B. utilizador A pode em seguida, a chave pública é chave pública do utilizador B de fidedignidade e pode pedir a prova da identidade do utilizador B.

O utilizador B atravessa o mesmo processo conforme descrito no exemplo anterior, conceber um resumo de mensagens e, em seguida, responder ao utilizador A uma versão assinada o resumo. O utilizador A pode verificar o utilizador B resumo de mensagens utilizando a chave pública do certificado e verificar o resultado.

Uma pessoa poderá interferir com comunicações seguras (neste exemplo, o utilizador C) pode criar um cenário seguinte para tentar fazê-lo:
A-> C C-> uma A-> C C-> de hello alta, estou utilizador BUser_B's_certificate provar
????
No entanto, o utilizador C não pode satisfazer utilizador A na mensagem final. Utilizador C não tem chave privada do utilizador B, C de utilizador não é possível construir uma mensagem que o utilizador A irá considerar provém do utilizador B.

Trocar um segredo

Depois do utilizador A tenha autenticado utilizador B, o utilizador A pode enviar utilizador B uma mensagem que só o utilizador B podem descodificar maneira
A-> B {secret}User_B's_public_key
em que a única forma para determinar o secret é desencriptando a mensagem acima com chave privada do utilizador B. Troca de uma palavra-passe é outra forma poderosa para utilizar a criptografia de chave pública. Mesmo que a comunicação entre utilizadores A e B do utilizador é respeitada, ninguém mas o utilizador B pode determinar as informações secretas.

Esta técnica reforça a segurança da Internet utilizando o segredo como outra tecla, mas neste caso é uma chave para um algoritmo criptográfico simétrica, tal como DES (Data Encryption Standard), RC4 ou IDEIA. Utilizador A conhecer a palavra-passe porque o utilizador A gerou o segredo antes de enviar para o utilizador B. utilizador B sabe a palavra-passe porque o utilizador B tem a chave privada e pode desencriptar a mensagem do utilizador do. Uma vez que o utilizador A e o utilizador B souber a palavra-passe, que podem ambos iniciam um algoritmo de encriptação simétrica e, em seguida, enviar mensagens encriptadas com o algoritmo de encriptação simétrica. Segue-se um protocolo revisto que utiliza esta técnica:
A-> B B-> uma A-> B B-> uma A-> B B-> de hello alta, estou utilizador BUser_B's_certificate
Prove-utilizador A, este é utilizador B {digest [utilizador A, este é utilizador B]} User_B's_private_key
OK utilizador B, aqui está um segredo {secret} User_B's_public_key {some_message} secret_key
O método utilizado para calcular secret_key é até ao protocolo que está a ser definido mas secret_key apenas podem ser uma cópia do segredo.

Interferência de segurança

Mesmo se todas as técnicas anteriores forem utilizadas, uma pessoa que pretende interferir com comunicações seguras (utilizador C) poderá fazê-lo. Apesar do utilizador C não consegue detectar o segredo tem trocado utilizador A e B do utilizador, utilizador C podem interferir com as respectivas conversação por re-arranging (ou garbling) as informações secretas. Por exemplo, se utilizador C é sentado entre o utilizador A e o utilizador B, C de utilizador pode passar a maioria das informações e para trás inalteradas, mas garble determinadas mensagens (isto é fácil para utilizador fazer porque o utilizador C conheça o protocolo esse utilizador A e B do utilizador estiver a utilizar para comunicar):
UM-> C C-> B B-> C C-> UM UM-> C C-> B B-> C C-> UM UM-> C C-> B B-> C C-> A
Bem-vindo "hello" Olá, estou utilizador B User_B's_certificate Hi, estou utilizador B
User_B's_certificateProve-provar A do utilizador, este é o utilizador B {digest [utilizador A
Este é utilizador B]} User_B's_private_key utilizador A, este é utilizador B {digest [utilizador A, este é
O utilizador B]} User_B's_private_key ok utilizador B, aqui está um segredo {secret} User_B's_public_key
OK utilizador B, aqui está um segredo {secret} User_B's_public_key {some_message} secret_key
Garble [{some_message} secret_key]
Utilizador C transmite dados sem modificações até que o utilizador A e o utilizador B partilham um segredo. Em seguida, o utilizador C garbles mensagem do utilizador B para o utilizador a. Neste momento, fidedignidades de utilizador A utilizador B, esse utilizador A podem considerar que a mensagem com erros e tente agi-lo. Nota que utilizador C não sabe a palavra-passe; todos os utilizadores C pode fazer é danificar os dados que são encriptados com a chave secreta. Dependendo do protocolo, C de utilizador não poderá produzir uma mensagem válida, mas poderá obter sorte e produzir uma mensagem válida C de utilizador.

Para evitar este tipo de danos, utilizador A e B do utilizador podem introduzir um código de autenticação de mensagens no respectivo protocolo. Um código de autenticação de mensagens é uma peça de dados que são calculadas através da utilização de secretas e alguns transmitidos dados. O algoritmo resumo descrito tem apenas as propriedades para a direita para criar uma função de código de autenticação de mensagem pode defesa contra C: utilizador
message_authentication_code: = digest [some_message, secret]
Porque o utilizador C não sabe a palavra-passe, utilizador C não é possível calcular o valor correcto para o resumo. Mesmo que o utilizador C aleatoriamente garbles mensagens, as hipóteses de sucesso é pequena se existir uma grande quantidade de dados de resumo. Por exemplo, utilizando o MD5 (um algoritmo de resumo criptográficos boa inventado por RSA), utilizadores A e B do utilizador podem enviar mensagem de 128 bits autenticação código valores com as suas mensagens. Odds do utilizador C adivinha o código de autenticação de mensagens correcto são aproximadamente 1 em 18,446,744,073,709,551,616. Para todos os fins práticos, o utilizador C não é possível adivinhar o código de autenticação de mensagens correcto.

Segue-se o protocolo de exemplo, revisto novamente para utilizar esta técnica:
A-> B B-> uma A-> B B-> de hello alta, estou utilizador BUser_B's_certificate provar
Este utilizador A, este é utilizador B {digest [utilizador A, este é utilizador B]} User_B's_private_key ok
Utilizador B, aqui está um segredo {secret} User_B's_public_key {some_message, message_authentication_code} secret_key
Utilizador C pode tentar garble mensagens, mas os cálculos de código de autenticação de mensagem revelar que as mensagens não ficam do utilizador B. utilizador A ou utilizador B pode descobrir o valor de código de autenticação de mensagem incorrecto e deixar de comunicação. Utilizador C já não pode representar o utilizador B.

Propriedades

Artigo: 245152 - Última revisão: 28 de outubro de 2006 - Revisão: 3.3
A informação contida neste artigo aplica-se a:
  • Microsoft Exchange Server 4.0 Standard Edition
  • Microsoft Exchange Server 5.0 Standard Edition
  • Microsoft Exchange Server 5.5 Standard Edition
Palavras-chave: 
kbmt kbinfo KB245152 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine translation ou MT), não tendo sido portanto revisto ou traduzido por humanos. A Microsoft tem artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais. O objectivo é simples: oferecer em Português a totalidade dos artigos existentes na base de dados do suporte. Sabemos no entanto que a tradução automática não é sempre perfeita. Esta pode conter erros de vocabulário, sintaxe ou gramática? erros semelhantes aos que um estrangeiro realiza ao falar em Português. A Microsoft não é responsável por incoerências, erros ou estragos realizados na sequência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza actualizações frequentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 245152
Exclusão de Responsabilidade para Conteúdo sem Suporte na KB
Este artigo foi escrito sobre produtos para os quais a Microsoft já não fornece suporte. Por conseguinte, este artigo é oferecido "tal como está" e deixará de ser actualizado.

Submeter comentários

 

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