É este cenário é seguro?

Question

Eu estou usando RSA para comunicação cifram entre um servidor e um cliente. Vamos dizer que temos 2 chaves assimétricas, chave 1 e Key2.

O servidor tem key1 (Private) desde o início e o cliente tem a key1 (público)

Então aqui é o cenário:

1. o cliente gera key2
2. Ligações cliente para o servidor
3. envio key2 (público) criptografados com key1 (público)
4. a partir de agora o servidor irá enviar todos os dados criptografados com a key2 (público)
5. o cliente envia alguns dados aleatórios para o servidor
6. o servidor envia de volta os mesmos dados hash
7. as verifica cliente que os dados são direito

Tanto quanto eu posso ver isso deve impedir que um ataque man-in-the-middle, ou estou faltando alguma coisa? No ponto 7, o cliente deve saber se alguém está tentando dar ao servidor a chave errada para criptografar com, como ninguém, mas o servidor pode descriptografar key2 (público).

Se houver qualquer coisa que pode ser feito para melhorar a segurança por favor me diga.

Answer 1

A melhor coisa que você pode fazer para melhorar a segurança é usar um projeto existente e não tentar reinventar a roda. Eu não estou dizendo que o que você fez é necessariamente errado, mas só que muitas pessoas muito mais inteligente do que você e eu passei muito tempo pensando sobre esse problema. Use TLS vez.

Answer 2

Enquanto key1 (privado) não foi interceptado alguma forma por um terceiro, a sua aparência cenário seguro.

Eu acho que vi isso em algum lugar em um papel realmente. Nele, Alice deu Bob uma caixa desbloqueado (número 1 público), então Bob colocar um monte de suas próprias caixas (número 2 pública) na mesma, bloqueia-o e envia de volta para Alice. Alice, em seguida, abre a caixa (número 1 privada), e agora ela pode seguramente selar as caixas que Bob apenas deu-la.

Apesar da analogia caixa, que é essencialmente o que você está fazendo, então eu diria que o seu seguro.

Answer 3

Eu concordo, é só usar TLS.

Além disso, o valor de fazer os passos 5 a 7 fornecem? A MITM querendo fazer um ataque que iria trabalhar após as etapas 1-4 (por exemplo DoS de algum tipo, passando n transações através de e, em seguida, parar, forçando uma repetição desde o início) poderia fazê-lo tão bem depois de 5-7. O que eles acrescentar?

- MarkusQ

Answer 4

Não, este protocolo não é seguro.

A man-in-the-middle pode interceptar os dados enviados pelo cliente e enviar o que quiser para o servidor, desde que você não tenha especificado nenhum mecanismo para o servidor para autenticar o cliente ou verificar a integridade das mensagens que recebe.

Claro, você pode medicar o seu protocolo para corrigir esses problemas evidentes, mas haveria outros. Se você nunca corrigi-los todos, você teria algo que mapeia para TLS ou SSH, então por que não começar por aí?

---

@ Petoj-o problema que eu estava focando foi a do servidor confiar nas mensagens que recebe; sua proposta não fornece nenhuma segurança lá. No entanto, se você está preocupado com a confidencialidade, você ainda tem um problema, porque o MITM poderia passar mensagens e para trás inalterado até que ele vê o que quer encontrar, porque você não tem qualquer privacidade nas mensagens do cliente.

A sua proposta parece estar destinada a garantir a integridade das mensagens do cliente. Você desenvolveu o protocolo para o ponto onde o cliente não pode distinguir entre um ataque e uma falha de rede. Ao invés de tentar ajudar o cliente a determinar se o servidor agiu em uma mensagem adulterados, permitir que o servidor para verificar a integridade da mensagem antes de agir sobre ele.

Answer 5

Eu concordo com Greg que você está reinventando a roda . O que você está, essencialmente, descrevendo alguma forma básica de chave troca. Aliás, a fim de garantir que é seguro contra man-in-the-middle você também deve ter certeza da identidade do servidor, ou seja, garantir que o cliente pode saber com certeza que o que ela acredita ser público (key1) realmente é do servidor e não os de man-in-the-middle (por exemplo, usando uma CA ou ter público do servidor (key1) em armazenamento seguro no lado do cliente.)

Além disso, há considerações adicionais você deve estar ciente do ponto de vista de sistemas, tais como:

• criptografia de chave assimétrica é mais lento de criptografia de chave simétrica, que é uma das razões por que as soluções existentes, como TLS vai utilizar a criptografia de chave assimétrica apenas para negociar uma chave simétrica temporária, a qual é então utilizada para a encriptação canal.
• Se a análise de tráfego por um terceiro consegue rachar uma chave simétrica temporária, você não comprometido você par de chaves assimétricas. Você está incentivados a re-negociar a chave temporária com relativa frequência por este motivo. Indiscutivelmente, gerando uma nova key2 em seu cenário iria atenuar este aspecto.