Criptografia de chave pública

Question

É assim que entendo como funciona a chave pública ... Digamos que você esteja em um site e acesse o cartão de crédito da página. Você então criptografa o pacote com a chave pública desse site e o envia para eles. O site então decodifica o pacote usando a chave privada correspondente. Então essa parte eu entendi.

Agora, que tal quando estou acessando uma página autenticada? Digamos que eu esteja acessando a minha conta bancária. Como o site criptografa o pacote que é destinado a mim? Como faço para abri-lo e como sei que alguém ao longo do caminho não o leu.

    

Answer 1

Essa é uma grande questão =) A seguir, uma visão geral de alto nível do HTTPS; grite se algo não estiver claro e preencherei mais detalhes.

Quando você usa uma conexão HTTPS, a criptografia de chave pública é usada apenas durante a inicialização da sessão. Parte dessa inicialização é a troca segura de uma chave privada compartilhada que é usada para criptografia simétrica. A razão para isso é que a criptografia assimétrica (chave pública) é significativamente mais lenta que a criptografia de chave simétrica, devido à matemática envolvida.

handshake SSL

Em um nível muito alto, o protocolo é algo assim:

1. O cliente envia a mensagem inicial "HELLO", que contém a versão ssl que gostaria de usar, uma sequência pseudo-aleatória de bits (vamos chamá-la B1) e uma lista das várias cifras que ela suporta.

2. O servidor responde com sua própria mensagem "HELLO", outra string pseudo-aleatória de bits (vamos chamá-lo de B2), a cifra que ele selecionou (normalmente a cifra mais strong da lista que o cliente enviou que o server supports), e seu certificado que contém sua chave pública (vamos chamar isso de k ).

3. O cliente então usa o certificado para autenticar o servidor (veja abaixo) e cria um "segredo pré-mestre" - outra sequência de bits pseduo-aleatórios que chamaremos de S.

4. Se o cliente estiver satisfeito com os resultados da autenticação do servidor, ele criptografa o segredo pré-mestre S com a chave pública do servidor k e o envia para o servidor (o próprio S é criptografado, mas a conexão ainda não é).

5. Neste ponto, o servidor e o cliente compartilham três sequências de bits - B1, B2 e S. B1 e B2 foram enviados na forma clara - S foi criptografado e, portanto, supondo que a chave privada do servidor seja realmente privada , é conhecido apenas pelo cliente e servidor.

6. O cliente e o servidor usam essas sequências de três bits para construir a chave de sessão - uma string conhecida apenas por eles e que pode ser usada como uma chave na criptografia simétrica selecionada anteriormente.

7. Cliente e servidor trocam mensagens que indicam que estão mudando de protocolo e todas as mensagens subseqüentes são criptografadas (simetricamente, com a chave computada acima).

Autenticação do servidor

Quando o cliente recebe a mensagem HELLO do servidor, ele precisa ter certeza de que está falando com o servidor que acha que está. O certificado e a chave do servidor são usados para estabelecer essa confiança.

Todo certificado digital é um terceiro afirmando que "essa entidade contém a chave privada que corresponde a essa chave pública, que está incorporada neste certificado". Organizações como a Verisign farão essa afirmação - por um preço. A razão pela qual as pessoas pagam à Verisign e a outras por certificados é que a Verisign se deu ao trabalho de inserir seus certificados intermediários na maioria dos navegadores comuns.

Assim, quando o cliente receber o servidor HELLO, ele executará as seguintes verificações:

• A data de hoje está dentro do período de validade do certificado?
• O nome da entidade do certificado corresponde ao do servidor ao qual estou tentando me conectar?
• O nome do emissor no certificado corresponde a alguma das CAs cujas chaves públicas eu conheço?
  • Em caso afirmativo, a chave pública que tenho para esta CA validar este certificado?

Se todas as verificações passarem, o cliente assume que pode acreditar que o servidor é quem estava esperando. Em seguida, ele tira a chave pública (ainda k ) do certificado e a usa para transmitir com segurança S para o servidor. Neste ponto, a idéia é que você tenha a afirmação de algum terceiro (Verisign) de que a chave pública pertence ao servidor; então, somente o servidor poderá descriptografar o resultado de E (S, k ) e, portanto, somente o servidor poderá produzir a chave correspondente que você usará para a cifra simétrica.

Após o handshake, sua confiança de que os pacotes não podem ser lidos por terceiros deve ser igual à sua confiança no algoritmo simétrico que está sendo usado.

(Há outras reviravoltas interessantes - por exemplo, o uso de três sequências de caracteres para evitar ataques de repetição. Se apenas S foi usado, um invasor pode gravar toda a sessão e reproduzi-la como quiser - por exemplo, repetindo uma transferência de dinheiro Ao fazer com que o cliente e o servidor gerem strings pseduo-random adicionais, você reduz bastante a probabilidade de dois handshakes SSL independentes produzirem o mesmo S.)

    

Answer 2

É mais simples que isso, na verdade.

As chaves públicas são públicas. Qualquer um pode vê-los, qualquer um pode usá-los ... Mas eles são apenas um caminho. Algo criptografado com sua chave pública só pode ser criptografado com sua chave privada.

Assim, no seu exemplo, o que acontece é que você envia pacotes para o banco que são criptografados com a chave pública que pertence ao banco, e o banco envia de volta pacotes que são criptografados com a sua chave pública. Só você pode ler o que o banco lhe envia e apenas o banco pode ler o que você envia ao banco. Mesmo que você a criptografe usando sua chave pública, não será possível lê-la. Você pode apenas ler os pacotes se tiver a chave privada correspondente.

Assumindo que as chaves privadas são de fato privadas, ninguém pode ler seus pacotes sem quebrar a chave privada.

Agora, a advertência é o ataque "Man in the Middle". É nesse ponto que um proxy ou um site de retransmissão se instala entre você e a pessoa com quem você pensa que está falando e o induz a aceitar sua chave pública em vez da chave do site que você acha que está visitando. Então, você envia pacotes para eles, criptografados com sua chave pública, que eles lêem, reencriptam usando a chave pública deles e encaminham para o site, que envia os pacotes que eles lêem e depois enviam para você.

    

Answer 3

Sua pergunta é um pouco genérica. O que exatamente você está procurando?

• implementações de protocolo (como eu abro um pacote criptografado)
• detalhes matemáticos (como o site criptografa o pacote destinado a mim)
• problemas de segurança (o ataque 'homem no meio')

Você leu a seção relacionada wikipedia ?

    

Answer 4

Em ambos os casos, você usa a chave pública do site (site de compras ou banco) para negociar uma chave de criptografia para a sessão atual. Essa chave de criptografia é usada para criptografar toda a comunicação depois disso. Não é uma chave assimétrica (não é um par de chaves privadas de chave pública), é uma chave secreta "regular" que é compartilhada entre o seu navegador e o site (e será destruída quando você fechar a janela). / p>

O motivo para usar a criptografia de chave pública apenas para transmitir a chave secreta é que é muito mais rápido fazer a criptografia simétrica. Também é igualmente seguro. E, como você apontou, apenas um lado precisa ter uma chave pública.

Na verdade, a única razão pela qual o site precisa ter uma chave pública, é para que você possa ter certeza com quem está falando. Impede ataques man-in-the-middle. Para os fins de manter a conexão segura de bisbilhoteiros, isso não é estritamente necessário. Na verdade, muitos sites usam chaves públicas que são autoassinadas (em vez de certificadas por uma autoridade de registro) para SSL. Nesse caso, você não pode realmente ter certeza de que a outra parte realmente é quem eles dizem ser, mas você pode ter certeza de que nenhum terceiro pode ouvir.

    

Answer 5

Existem dois tipos de cifras sendo usadas aqui. Há o tipo de chave pública (assimétrica) e o tipo mais comum de chave compartilhada (simétrica). As cifras simétricas são muito mais eficientes, pois não há muitas maneiras de configurar uma cifra de chave pública.

Portanto, você usa a chave pública para fazer contato. Seu navegador pode criptografar uma chave compartilhada com a chave pública do site, e apenas esse site pode receber a chave compartilhada. Então seu navegador e o site se comunicam com uma cifra padrão. A chave é normalmente descartada no final da sessão. Portanto, desde que tudo corra bem, sua comunicação é segura.

Há também a questão de saber com quem você está falando. Para isso, o site tem um certificado, que é uma atestado de uma autoridade de certificação com o qual você está falando para quem solicitou o certificado. As autoridades de certificação são carregadas no seu navegador quando você as obtém e qualquer certificado assinado por um deles será aceito pelo seu navegador. Algumas autoridades oferecem certificados com preços mais altos que aparecerão em seu navegador como verdes e que foram verificados com mais cuidado pela autoridade de certificação em questão.

Não estou dizendo que essa é a melhor maneira de fazer isso. Por exemplo, eu gostaria de ver um aviso quando você recebe um certificado diferente para o mesmo site, um aviso que é freqüentemente usado em outros aplicativos de criptografia de chave pública. Não creio que o aviso do Firefox para um certificado auto-assinado seja apropriado (o que indica um site que usava criptografia de chave pública sem comprar um certificado), pois faz com que esses sites pareçam menos confiáveis do que uma conexão não criptografada.

(Eu não estou indo para os detalhes técnicos aqui, mas é uma aplicação razoavelmente direta de cifras de chave pública e hashes criptográficos. Um hash é um método de reduzir um arquivo ou algo para um identificador de lengh fixo, então dois É improvável que os arquivos tenham o mesmo valor. Um hash criptográfico é aquele em que é realmente difícil criar dois arquivos com o mesmo valor de hash.)

    

Answer 6

Resposta simples: exatamente da mesma maneira.

Suponha que A possa enviar dados com segurança para B, mas B só pode enviar dados de forma insegura para A. Tudo que você precisa fazer é ter uma chave aleatória e enviá-la com segurança para B. Agora B pode criptografar dados com essa chave aleatória , envie para A e é seguro.

Portanto, se você tiver um link bidirecional seguro apenas em uma direção, é trivial torná-lo seguro em ambas as direções.

    

Answer 7

Você sabe quem é o banco porque seu navegador reconhece o certificado como válido. Mas como o banco sabe que é você? A resposta é que não, pelo menos não do SSL. Seu navegador FAZ uma chave privada POR SESSÃO. Essa chave privada não significa nada para o banco, porque você ainda pode ser alguém. No entanto, essa chave privada faz fornecer uma conexão segura. Como você confia no site do banco, efetua login usando a conexão segura e, nesse momento, sabe que é você e que a sessão é segura para dados sobre você.

O banco criptografa os dados do seu navegador usando a chave pública que o navegador forneceu quando a sessão foi iniciada, e você criptografa o material para o banco usando a chave pública. O processo é o mesmo em ambas as direções, essencialmente, uma vez que você estabeleça identidade.