La prevención de ataques MITM en el servidor

Question

Dos clientes Alice y Bob usan un servidor para iniciar sesión e intercambiar mensajes a través del servidor. Al iniciar la sesión, ambos envían sus claves públicas a ser almacenados en el servidor. Cuando Alice quiere hablar con Bob, ella enrypts una clave simétrica con la clave pública de Bob y lo envía a Bob a través del servidor.

¿Cómo puedo estar seguro de que el servidor no tiene su propio par de claves pública y enviarlo a Alice en lugar de la clave pública de Bob. De esta manera, el servidor primero descifrar lo que Alice ha enviado y cifrar de nuevo utilizando la clave pública real de Bob.

Gracias

Answer 1

Desde que Alice y Bob no pueden confiar en el servidor, tienen que encontrar otra manera de confirmar claves de cada uno. Una posibilidad es confiar en otra parte. Si Bob confía Candice (y conoce la clave pública de Candice), que conoce a Alice, Candice puede firmar la clave pública de Alicia a continuación, enviar la versión firmada a Bob. Esto se llama red de confianza .

Answer 2

Al tener el certificado de Bob firmado por un tercero de confianza (Verisign, su corporación, una red de confianza, etc.), o haciendo que Bob envía su certificado a Alice a través de una ruta segura por separado fuera de banda (dándole un USB clave en persona, por ejemplo).

Ambos llegar al corazón de lo que se supone certificado de Bob a significar. Sólo confía en que el certificado de Bob es el certificado de Bob porque alguien de confianza lo ha certificado. Ese "alguien" puede ser él mismo o por un tercero de confianza que firma el certificado de Bob Bob. Para que sólo puede confiar en esto tanto como usted confía en el certificador.

Answer 3

En la criptografía, usted es lo que sabes. Si se quiere evitar MITM, a continuación, Alice debe tener una idea de quién es "Bob", lo que significa que Bob debe conocer algún elemento de datos que un atacante no conoce. En este caso, el atacante es el servidor, que está idealmente situado para montar un ataque.

Así que la pregunta es: ¿quién es Bob? ¿Cómo es el servidor "no-Bob"?

Por ejemplo, "Bob" se puede definir como: "Bob es un ser humano que tiene una licencia de conducir con 'Bob' escrito en él". O: "Bob es ese tipo que conocí en un bar y bebía una cerveza con"

.

El uso de la criptografía asimétrica le permite reducir el problema a una cuestión de confianza en una clave pública. Alice utilizará lo que ella cree que es la clave pública de Bob. Por lo tanto, Alice sólo necesita alguna manera de asegurarse de que la clave pública que tiene es de hecho propiedad de Bob. Posesión de una clave pública se define por el control de la clave privada correspondiente: la clave pública de Bob es la clave para el que la clave privada se encuentra bajo el control exclusivo de Bob (por ejemplo, sólo Bob sabe esa clave o la clave privada está en un token de hardware - una tarjeta inteligente -. que Bob mantiene en su cartera)

La solución básica es tener un intercambio directo de clave pública. Cuando Alice se reunió Bob en un bar, dieron unos a otros sus claves públicas. Por lo tanto, Alice puede confiar en la clave pública de Bob "por definición". Para el intercambio fácil (especialmente después de unas cervezas), Alice y Bob pueden intercambiar sólo "huellas dactilares", es decir, los valores hash calculados sobre las claves públicas. Estos valores son más cortas que las claves públicas (por ejemplo, 128 bits, en lugar de más de un millar de bits para una clave pública RSA típica) y son suficientes para verificar que unos partidos clave pública dada. En esa configuración, el servidor tiene un repositorio de claves públicas, y Alice y Bob sólo se vuelve a calcular las huellas digitales para asegurarse de que el servidor no está jugando juegos falsos.

Una solución más adelantado, lo que alivia la necesidad para el consumo directo de alcohol, es utilizar Certificados . Un certificado es una caja que contiene un Identidad (por ejemplo, un nombre, como "Bob") y una clave pública. La caja está firmada por un Autoridad de Certificación (CA): el CA afirma que la clave pública pertenece realmente a Bob, mediante la aplicación de su firma. Si Alicia conoce la clave pública CA, entonces ella puede comprobar la firma en el certificado, y luego ganar la confianza en la relación entre la clave pública y la identidad contenida en el certificado.

La certificación es la delegación de confianza. Alicia delegados su confianza a la CA; Supuestamente, el CA (vamos a llamarlo Charlie) fuimos al bar para satisfacer Bob; a través del certificado, Charlie le dice a Alicia: "sí, eso es realmente la clave de Bob, que me lo mostró después de su tercera pinta". Las cosas se vuelven un poco turbia aquí, porque la delegación de la confianza no es fácil (especialmente si Charlie está en el hábito de consumo excesivo de alcohol). La delegación puede ir más allá, cuando una CA firma un certificado para otra CA. Aquí, Charlie le dice a Alicia: "No he conocido a Bob, pero he conocido a Daphne, que pueden haber conocido a Bob y actuó como una CA". Alice, utilizando tanto el certificado expedido por Charlie a Daphne, y el certificado expedido por Daphne a Bob, puede verificar que cadena de firmas.

El punto difícil aquí es que mientras que Alice puede saber Charlie y confiar en él en su capacidad para identificar correctamente a Bob cuando se encuentre con él, incluso bajo la influencia de un galón de Guinness, Alice no sabe Daphne. En la cadena de Alice-Charlie-Daphne-Bob, Alice no sólo debe confiar en que Charlie era fiable (que no identificar Daphne correctamente), sino también de que Charlie no era ingenuo, es decir que Charlie se habría negado a firmar un certificado para Daphne Daphne si no era ella misma confianza. En situaciones prácticas, la confianza se degrada rápidamente cuando se delega.

Cuando el uso de certificados, hay principalmente dos estructuras posibles:

• CA jerárquica: hay una sola o unas pocas "CA raíz", que son conocidos por todo el mundo por la construcción. Una delegados CA tO otra CA (es decir, se firma un certificado con, en la identidad, una bandera convencional que dice: "esta clave pública puede ser de confianza con el fin de verificar las firmas en los certificados") sólo dentro de un acuerdo contractual que establece las responsabilidades legales de ambas CA con respecto a la certificación. Esto significa que la delegación se define formalmente, y se da la circunstancia de que no es fácil. Un contrato de certificación compatible con el abogado, por lo general llamado "Declaración de Política de Certificación" (CPS), es un documento largo de 200 páginas.

• Red de Confianza: todo el mundo actúa como una CA. En la ausencia de "confiabilidad formal", cada uno de los rendimientos individuales de la cadena sólo una muy pequeña cantidad de confianza. Esto está destinado a ser compensado por un gran número. Alice aceptará clave de Bob sólo si se puede verificar varios (muchos) cadenas distintas que conducen a Bob, pasando por distintos participantes. Por ejemplo, Alice requerirá la cadena de Charlie-Daphne-Bob, sino también las cadenas Elías-Fiona-Bob y Gerald-Hillary-Ivan-Bob. Están todos borrachos, pero pueden ser colectivamente fiable, en el que una falsificación Bob tendría que pagar muchas rondas con el fin de corromper a un participante de cada una de las cadenas que Alice utiliza (si Alice requiere < em> n cadenas con certificados distintos, entonces el atacante debe corrupto al menos n participantes).

Así que el negocio de la certificación es sobre todo una cuestión de procedimiento: que es una entidad de certificación, lo que es una CA verifica antes de emitir (firma) un certificado, cómo toda la cosa está parada desde un punto de vista legal, y así sucesivamente. Estos procedimientos son inherentemente complejos y deben ser compatibles con los detalles en el formato del certificado (como la bandera "esta clave pública es una clave CA"). Los dos formatos estándar principales definidos en la actualidad son X.509 y PGP . X.509 tiene mucho apoyo a la CA jerárquica, y es un desastre muy enredado de normas, formatos, prácticas y comités. PGP (estandarizado bajo el nombre de "OpenPGP") no tiene soporte real para CA jerárquica; que está destinado a ser usado con una red de confianza. OpenPGP es más simple que X.509, pero más limitada, especialmente si usted desea tener un fuerte sentido jurídico detrás de los certificados.

Para un servidor de mensajería instantánea, todo esto es probable que sea una exageración. La noción de identidad que Alice quiere realmente es, probablemente, una noción de repetición : "que Bob es el mismo que el de Bob Charlé con el ayer". Alice no sabe de antemano Bob, pero hablar con él una vez que establece su identidad con los ojos de Alice. Ella sólo quiere que no se deje engañar por otra Bob. Por eso, un proceso simple, tales como "software de Alice guarda la clave pública anunciada de cualquier nueva charla, y lo utiliza después" hará el truco. Recuerde que la cuestión clave es correcta definen lo noción de identidad que está después.

Answer 4

A menos que usted controla el servidor no se puede. A menos que, por supuesto, que ya conoce la clave pública de Bob, pero entonces .... Creo que estás en el problema de la gallina y el huevo aquí.