Prevenção de ataques MITM no servidor

Question

Dois clientes Alice e Bob usar um servidor de início de sessão e trocar mensagens através do servidor.Sobre o login, eles enviam suas chaves públicas a serem armazenados no servidor.Quando Alice quer falar para Bob, ela enrypts uma chave simétrica com a chave pública de Bob e a envia para Bob através do servidor.

Como posso certificar-se de que o servidor não fazer o seu próprio par de chaves pública e enviá-lo para Alice, em vez de Bob chave pública.Desta forma, o servidor irá primeira descriptografar o que Alice tem enviado e criptografá-lo novamente usando o Bob real de chave pública.

Obrigado

Answer 1

Como Alice e Bob não podem confiar no servidor, eles devem encontrar outra maneira de confirmar as chaves um do outro. Uma possibilidade é confiar em outra parte. Se Bob confia em Candice (e conhece a chave pública de Candice), que conhece Alice, Candice pode assinar a chave pública de Alice, enviar a versão assinada para Bob. Isso é chamado Web of Trust.

Answer 2

Por ter Bob certificado assinado por uma terceira parte confiável (Verisign, a sua empresa, um site de confiança, etc.), ou por ter Bob envia seu certificado para Alice através de um seguro separado caminho fora de banda (a entregar-lhe uma chave USB na pessoa, por exemplo).

Ambos esses chegar ao coração do que Bob certificado é suposto dizer.Você apenas confiar em que Bob certificado de Bob certificado porque alguém em quem você confia tenha certificado.Que "alguém" pode ser Bob si ou para um terceiro confiável que sinais de Bob certificado.Você só pode confiar isso tanto quanto você a confiança o certificador.

Answer 3

Na criptografia, você é o que você sabe. Se você deseja evitar o MITM, Alice deve ter uma noção de quem é "Bob", o que significa que Bob deve conhecer algum elemento de dados que um invasor não conhece. Aqui, seu atacante é o servidor, idealmente localizado para montar um ataque.

Então, a pergunta é: quem é Bob? Como está o servidor "não-bob"?

Por exemplo, "Bob" pode ser definido como: "Bob é um ser humano que tem uma carteira de motorista com 'Bob' escrito". Ou: "Bob é aquele cara que eu conheci em um bar e bebi uma cerveja".

O uso de criptografia assimétrica permite reduzir o problema a uma questão de confiança em uma chave pública. Alice usará o que ela acredita ser a chave pública de Bob. Portanto, Alice só precisa de alguma maneira de garantir que a chave pública que ela possui é realmente de propriedade de Bob. A propriedade de uma chave pública é definida pelo controle da chave privada correspondente: a chave pública de Bob é a chave para a qual a chave privada está sob controle exclusivo de Bob (por exemplo, Bob sabe que a chave ou a chave privada está em um token de hardware - Um Smartcard- que Bob mantém em sua carteira).

A solução básica é ter uma troca direta de chave pública. Quando Alice conheceu Bob em um bar, eles deram suas chaves públicas. Assim, Alice pode confiar na chave pública de Bob "por definição". Para trocas mais fáceis (especialmente depois de algumas cervejas), Alice e Bob podem trocar apenas "impressões digitais", ou seja, valores de hash calculados sobre as chaves públicas. Esses valores são mais curtos que as chaves públicas (por exemplo, 128 bits, em vez de mais de mil bits para uma chave pública típica da RSA) e são suficientes para verificar que uma determinada chave pública corresponde. Nessa configuração, o servidor possui um repositório para chaves públicas, e Alice e Bob apenas recompram as impressões digitais para garantir que o servidor não esteja jogando jogos falsos.

Uma solução mais avançada, que alivia a necessidade de consumo direto de álcool, é usar certificados. Um certificado é uma caixa que contém um identidade (por exemplo, um nome, como "Bob") e uma chave pública. A caixa é assinada por um Autoridade de Certificação (CA): A CA afirma que a chave pública realmente pertence a Bob, aplicando sua assinatura. Se Alice conhece a chave pública da CA, ela poderá verificar a assinatura no certificado e, em seguida, ganhar confiança no link entre a chave pública e a identidade contida no certificado.

A certificação é delegação de confiança. Alice delegados sua confiança na CA; Supostamente, a CA (vamos chamá -lo de Charlie) foi ao bar para conhecer Bob; Através do certificado, Charlie diz a Alice: "Sim, isso é realmente a chave de Bob, ele me mostrou depois de sua terceira cerveja". As coisas se tornam um pouco sombrias aqui, porque a delegação de confiança não é fácil (especialmente se Charlie tem o hábito de beber compulsivamente). A delegação pode ir além, quando uma CA assina um certificado para outra ca. Aqui, Charlie diz a Alice: "Eu não conheci Bob, mas conheci Daphne, que pode ter conhecido Bob e atuado como uma CA". Alice, usando o certificado emitido por Charlie para Daphne, e o certificado emitido por Daphne para Bob, pode verificar que corrente de assinaturas.

O ponto complicado aqui é que, embora Alice possa conhecer Charlie e confiar nele em sua capacidade de identificar adequadamente Bob quando ele o conhece, mesmo sob a influência de um galão de Guinness, Alice não conhece Daphne. Na cadeia Alice-Charlie-Daphne-Bob, Alice deve não apenas confiar que Charlie era confiável (ele fez Identifique Daphne corretamente), mas também que Charlie não era ingênuo, ou seja, que Charlie teria se recusado a assinar um certificado para Daphne se Daphne não fosse confiável. Em situações práticas, a confiança se degrada rapidamente quando é delegada.

Ao usar certificados, existem principalmente duas estruturas possíveis:

• CA hierárquico: Há um único ou alguns "raiz ca" que são conhecidos por todos por construção. A CA delega para outra CA (ou seja, assina um certificado com, na identidade, uma bandeira convencional que diz: "Essa chave pública pode ser confiável com o objetivo de verificar as assinaturas nos certificados") apenas dentro de um contrato contratual que estabelece o legal Responsabilidades de ambas as CA em relação à certificação. Isso significa que a delegação é formalmente definida, e acontece que não é fácil. Um contrato de certificação compatível com advogado, geralmente chamado de "Declaração de Política de Certificação" (CPS), tem um documento de 200 páginas.

• Web of Trust: Todo mundo age como ca. Na ausência de "confiabilidade formal", cada cadeia individual produz apenas uma quantidade muito pequena de confiança. Isso deve ser compensado por grandes números. Alice aceitará a chave de Bob apenas se ela puder verificar de várias (muitas) cadeias distintas que levam a Bob, passando por participantes distintos. Por exemplo, Alice exigirá a cadeia Charlie-Daphne-Bob, mas também as cadeias Elijah-Fiona-Bob e Gerald-Hillary-Ivan-Bob. Eles estão todos bêbados, mas podem ser coletivamente confiável, pois um bob falso teria que pagar muitas rodadas para corromper um participante de cada uma das correntes que Alice usa (se Alice exigir n correntes com certificados distintos, então o invasor deve corromper pelo menos n participantes).

Portanto, o negócio de certificação é principalmente uma questão de procedimento: quem é uma CA, o que a CA verifica antes de emitir (assinar) um certificado, como a coisa toda é de um ponto de vista legal e assim por diante. Esses procedimentos são inerentemente complexos e devem ser suportados por detalhes no formato do certificado (como o sinalizador "essa chave pública é uma chave CA"). Os dois principais formatos padrão atualmente definidos são X.509 e Pgp. O X.509 tem muito apoio à CA hierárquica e é uma bagunça muito emaranhada de padrões, formatos, práticas e comitês. O PGP (padronizado sob o nome "OpenPGP") não possui suporte real para a CA hierárquica; Deve ser usado com uma rede de confiança. O OpenPGP é mais simples que X.509, mas mais limitado, especialmente se você deseja ter um forte significado legal por trás dos certificados.

Para um servidor de IM, tudo isso provavelmente será um exagero. A noção de identidade que Alice realmente deseja é provavelmente uma noção de repetição: "Que Bob é o mesmo Bob do que o que conversei ontem". Alice não conhece Bob de antemão, mas conversar com ele uma vez estabelece sua identidade nos olhos de Alice. Ela só quer não ser enganada por outro bob. Para isso, um processo simples, como "o software de Alice, salva a chave pública anunciada de qualquer nova conversa e o usar posteriormente" fará o truque. Lembre -se de que a questão principal é adequadamente definir Que noção de identidade você procura.

Answer 4

A menos que você controla o servidor, você não pode. A menos, é claro, você já conhece a chave pública de Bob, mas então ... acho que você está no problema de frango e ovo aqui.