En criptografía, eres lo que sabes. Si desea evitar MITM, entonces Alice debe tener una idea de quién es "Bob", lo que significa que Bob debe conocer algún elemento de datos que el atacante no conozca. Aquí, su atacante es el servidor, que está idealmente ubicado para montar un ataque.
Entonces 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 ella". O bien: "Bob es el tipo que conocí en un bar y bebió una cerveza".
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 usará lo que ella cree que es la clave pública de Bob. Por lo tanto, Alice solo necesita alguna forma de asegurarse de que la clave pública que posee sea propiedad de Bob. La propiedad de una clave pública se define mediante el control de la clave privada correspondiente: la clave pública de Bob es la clave para la cual la clave privada está bajo el control exclusivo de Bob (por ejemplo, solo Bob conoce esa clave, o la clave privada está en una ficha de hardware - una tarjeta inteligente - que Bob guarda en su billetera).
La solución básica es tener un intercambio directo de clave pública. Cuando Alice se encontró con Bob en un bar, se dieron sus llaves públicas. Por lo tanto, Alice puede confiar en la clave pública de Bob "por definición". Para facilitar el intercambio (especialmente después de algunas cervezas), Alice y Bob solo pueden intercambiar "huellas dactilares", es decir, valores hash calculados sobre las claves públicas. Estos valores son más cortos que las claves públicas (por ejemplo, 128 bits, en lugar de más de mil bits para una clave pública RSA típica) y son suficientes para verificar que una clave pública determinada coincide. En esa configuración, el servidor tiene un repositorio de claves públicas, y Alice y Bob solo vuelven a calcular las huellas dactilares para asegurarse de que el servidor no esté reproduciendo juegos falsos.
Una solución más avanzada, que alivia la necesidad de consumo directo de alcohol, es utilizar certificados. Un certificado es un cuadro que contiene una identidad (por ejemplo, un nombre, como "Bob") y una clave pública. La caja está firmada por una autoridad de certificación (CA): la CA afirma que la clave pública realmente le pertenece a Bob, mediante la aplicación de su firma. Si Alice conoce la clave pública de CA, puede verificar la firma en el certificado y luego confiar en el vínculo entre la clave pública y la identidad contenida en el certificado.
La certificación es una delegación de confianza. Alice delega su confianza a la CA; supuestamente, el CA (llamémoslo Charlie) fue al bar para encontrarse con Bob; a través del certificado, Charlie le dice a Alice: "Sí, esa es realmente la llave de Bob, me la mostró después de su tercera pinta". Las cosas se vuelven un poco turbias aquí, porque delegar confianza no es fácil (especialmente si Charlie tiene el hábito de beber en exceso). La delegación puede ir más allá cuando una CA firma un certificado para otra CA. Aquí, Charlie le dice a Alice: "No conocí a Bob, pero conocí a Daphne, que tal vez conoció a Bob y actuó como CA". Alice, utilizando tanto el certificado emitido por Charlie a Daphne, como el certificado emitido por Daphne a Bob, puede verificar que cadena de firmas.
El punto delicado aquí es que, aunque Alice puede conocer a Charlie y confiar en él en su capacidad para identificar correctamente a Bob cuando lo encuentra, incluso bajo la influencia de un galón de Guinness, Alice no conoce a Daphne. En la cadena Alice-Charlie-Daphne-Bob, Alice no solo debe confiar en que Charlie era confiable (identificó a Daphne correctamente) sino también que Charlie no era crédulo, es decir, que Charlie se habría negado a firmar un certificado para Daphne si Daphne no era ella misma confiable. En situaciones prácticas, la confianza se degrada rápidamente cuando se delega.
Cuando se utilizan certificados, hay sobre todo 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 CA delega a otra CA (es decir, firma un certificado con, en la identidad, una bandera convencional que dice: "esta clave pública puede ser confiable con el fin de verificar firmas en certificados") solo dentro de un acuerdo contractual que establece la legal responsabilidades de ambas CA con respecto a la certificación. Esto significa que la delegación está formalmente definida, y sucede que no es fácil. Un contrato de certificación compatible con el abogado, generalmente llamado "Declaración de Política de Certificación" (CPS), es un documento de 200 páginas de largo.
Web of Trust: todo el mundo actúa como CA. En ausencia de "confiabilidad formal", cada cadena individual produce solo una cantidad muy pequeña de confianza. Esto está destinado a ser compensado por grandes números. Alice aceptará la clave de Bob solo si puede verificar varias (muchas) cadenas distintas que conducen a Bob, pasando por distintos participantes. Por ejemplo, Alice requerirá la cadena Charlie-Daphne-Bob, pero también las cadenas Elijah-Fiona-Bob y Gerald-Hillary-Ivan-Bob. Todos son borrachos, pero pueden ser colectivamente confiables, ya que un falso Bob tendría que pagar muchas rondas para corromper a un participante de cada una de las cadenas que usa Alice (si Alice requiere n cadenas con distinto certificados, entonces el atacante debe corromper 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, etc. . Estos procedimientos son intrínsecamente complejos y deben ser respaldados por detalles en el formato del certificado (como el indicador "esta clave pública es una clave CA"). Los dos formatos estándar principales actualmente definidos son X.509 y PGP. X.509 tiene mucho soporte para la CA jerárquica, y es un lío muy complicado de estándares, formatos, prácticas y comités. PGP (estandarizado bajo el nombre "OpenPGP") no tiene soporte real para CA jerárquica; está destinado a ser utilizado con una Web of Trust. OpenPGP es más simple que X.509 pero más limitado, especialmente si desea tener un fuerte significado legal detrás de los certificados.
Para un servidor de MI, todo esto es probable que sea excesivo. La noción de identidad que Alice realmente quiere es probablemente una noción de repetición: "que Bob es el mismo Bob que el que chateé ayer". Alice no conoce a Bob de antemano, pero hablar con él una vez establece su identidad en el ojo de Alice. Ella solo quiere no ser engañada por otro Bob. Para eso, un proceso simple como "el software de Alice guarda la clave pública anunciada de cualquier nueva conversación y la usa después" hará el truco. Recuerde que la cuestión clave es definir correctamente qué concepto de identidad está buscando.
Candice? ¿Estaba Trent enfermo hoy? – caf
Ah, y Candice no necesita enviar la versión firmada a Bob, ella puede simplemente dársela a Alice, quien puede pasarla a Bob a través del servidor que no es de confianza. Bob aún puede verificar la firma de Candice. – caf