30 Enero 1999


Uno de los conceptos más confusos en el uso de PGP es el de validez. Constantemente los novatos preguntan asustados qué hacer tras haber recibido una clave pública inválida. ¿Significa eso que la clave no sirve? ¿Acaso ha sido falsificada por los malos? También aparece el listo que ha descubierto la forma de convertir una clave inválida en válida: firmándola. Y al hacerlo, destruye el concepto de "red de confianza" que intenta resolver el problema más grave con que el concepto de PGP se enfrenta.

Dicho problema consiste, simplemente, en saber si la clave pública que hemos recibido pertenece realmente a su supuesto remitente. Ya conocemos el problema del intermediario (man-in-the-middle). Alicia y Benito crean sus claves A y B, respectivamente. Por un procedimiento a distancia deciden enviarse mutuamente sus claves públicas. Por desgracia, Carlos entra en juego. Ha creado claves falsas tanto de Alicia (llamemos a dicha clave Af) y de Benito (Bf), y ha conseguido sustituir las claves públicas verdaderas. De ese modo, Alicia cifra un mensaje con la clave pública (falsa) de Benito, Bf. Carlos intercepta el mensaje, lo descifra con la parte privada de la clave Bf (que él tiene, puesto que él la creó), lo lee, lo cifra -o cifra un nuevo mensaje falso- con la clave (auténtica) de Benito B, y lo envía. Y el inocente de Benito descifra el mensaje con la parte privada de su clave B, creyendo que el mensaje lo escribió Alicia y que nadie lo ha podido leer por el camino. De un modo análogo, Benito cifra un mensaje, Alicia lo descifra ... y el bribón de Carlos se entera de todos los cotilleos.

Este problema se puede resolver si Alicia y Benito se ven cara a cara y se intercambian sus claves públicas en mano. Pero Internet es una red mundial, de modo que esto no será siempre factible. Para resolver dicho problema, entran los conceptos de validez y confianza. Para resumir, diremos que una clave es válida si estoy seguro de que pertenece a su dueño; una clave será de confianza si su dueño es de fiar, es decir, si es una persona responsable a la hora de firmar claves. Una firma de alguien de confianza permite establecer una "red de confianza" entre claves que han sido distribuidas por medios no directos (un servidor de claves, un archivo adjunto a un correo electrónico, etc).

Todo esto está muy bien, pero como todos sabemos no hay como un buen ejemplo. Busquemos un conjunto de personas y asignémosles unos papeles (o roles, que dicen los psicólogos) para ver cómo se teje la red de confianza [web of trust] entre ellos. Hace algún tiempo, y gracias al distorsionador temporal multiprobabilístico que me prestó mi amigo del CSIC (el mismo que fue abducido por los ribosomas, pero de eso ya hablaremos otro día), entré en contacto con un encantador grupito de personajes. Ahora, si tengo vuestra atención, compartiré con vosotros ciertos sucesos que acaecieron tiempo atrás, en un brumoso Londres de finales del siglo diecinueve ...

Así podemos ir incluyendo más personajes. Por ejemplo, el tenaz aunque algo torpe inspector Lestrade. Tras obtener las claves de los demás mediante el servidor de claves, decide establecer su nivel de confianza. No está seguro acerca de la autenticidad de la clave de Holmes; pero Holmes le dio una vez la huella [fingerprint] de su clave, que es una ristra de caracteres identificativa de cada clave. Tras comprobarla, se convence, así que firma la clave de Holmes. Y, puesto que conoce su integridad, también le otorga confianza. A continuación se ocupa de la clave del doctor Watson, pero descubre asombrado que dicha clave goza de validez. Nosotros no nos asombramos, puesto que ya sabemos que la clave de Watson está firmada por Holmes; quien confíe en éste, automáticamente dará validez a la clave de aquél.

El inspector Lestrade confía en Sebastian Moran. A fin de cuentas, es un hombre con una reputación de caballero, y el que acabara en las filas de Moriarty no es algo muy conocido. Por desgracia, el pobre inspector confunde los términos y le otorga validez a la clave de Moran firmándola, a pesar de que no sabe si esa es realmente la clave de Moran. Así, la integridad de éste queda avalada por la firma de Lestrade. Por supuesto, aceptar como válida la clave de Moran dependerá ahora de la confianza que se le otorge al inspector Lestrade.

Por ejemplo, Holmes no ha recibido la clave de Lestrade personalmente, así que no puede asignarle validez. Y ni pensar en otorgarle confianza, ya que Holmes conoce a Lestrade y, aunque fiel cumplidor de la ley, le considera demasiado atolondrado como para fiarse de él. Pero Holmes ve que la clave de Lestrade ha sido firmada por el doctor Watson. Eso no le da a dicha clave confianza, pero le da validez. Holmes confía en el buen criterio de su socio y acepta la clave.

Efectivamente, Watson ha recibido la clave de Lestrade personalmente y la ha firmado. Pero el buen doctor ha cometido un pequeño error de apreciación al decidir otorgarle a Lestrade no solamente validez, sino también confianza. De ese modo, en el archivo de claves de Watson aparecerán como válidas las claves firmadas por Lestrade, a pesar de que nosotros sabemos la poca cabeza que tiene el inspector en esos menesteres. La clave de Sebastian Moran aparece así como válida en el archivo de claves de Watson, ya que fue firmada por alguien en quien tiene confianza (Lestrade). A pesar de ello, eso no le otorga confianza a Moran. Pero, basado en la apreciación de Lestrade, Watson acepta la clave de Moran como válida.

Sin embargo, un sexto sentido indicó a Watson que quizá el inspector Lestrade no fuese tan de confianza como parece (mucho menos, por supuesto, que su admirado Holmes). Esto le lleva a otorgar a Lestrade una confianza Marginal, no completa [trusted]. El resultado es curioso: la clave de Moran aparece como de validez marginal. Es decir, Watson, se fía a medias de Lestrade, así que la firma de Moran será válida a medias. Esto aparece de manifiesto si se configura PGPkeys para que muestre el nivel de validez marginal (Edit/ Preferences/ Advanced, "Display marginal validity level"). Si no se hace así, aparecerá un círculo, cuyo color indica validez o no. En ese caso, una firma de confianza marginal implicará validez (verde) o no validez (gris), dependiendo de si hemos decidido o no tratar como válidas las claves que tienen validez marginal ("treat marginally valid keys as invalid", en Edit/ Preferences/ Advanced). Hemos de decidir si una firma de validez marginal nos vale o no. Como vemos, mostrar el nivel de validez marginal nos permite una apreciación más de "ajuste fino".

A continuación, una cuestión interesante. ¿Se pueden "sumar" los grados de validez? Es decir, ¿pueden dos, o más, firmas de personas con confianza marginal producir una clave con validez más que marginal? La respuesta es afirmativa. El doctor Watson lo comprueba tras firmar y otorgar confianza marginal a la clave del inspector Gregson. De repente, la clave de Moran aparece como de validez total. Eso se debe a que dicha clave está firmada por los dos inspectores, que para Holmes gozan de confianza marginal.

Es decir, al menos una firma de confianza total o dos de confianza marginal otorgan validez total a una clave; una firma de confianza marginal otorga validez marginal a una clave. ¿Y más de una firma de confianza total? No hay diferencia. Que el doctor Watson conceda confianza total al inspector Gregson, o que incluso firme directamente la clave de Moran, no aumenta la validez de dicha clave más allá del nivel máximo. Lástima que PGP no permita ajustar mejor la concesión de validez. Por ejemplo, a Holmes le gustaría que la validez máxima correspondiera a una clave firmada con a) una clave de confianza máxima y una de confianza marginal, o b) cuatro claves de confianza marginal. Lestrade, más convencional, podría preferir una clave de confianza máxima o tres de confianza marginal. Y así sucesivamente. Bueno, nada es perfecto.

Si has seguido hasta aquí, lector, podrás imaginarte múltiples posibilidades. Por ejemplo, ¿qué efecto tiene el que Holmes firme la clave del inspector Gregson? Para el propio Holmes, significa otorgar validez a la clave. Para Watson, ninguna, puesto que él mismo ya la había firmado. Por el contrario, para Porlock la clave de Gregson se convierte en una de validez total, ya que acaba de ser firmada por alguien en quien confía. Lo mismo le pasa a Lestrade, quien no había querido firmar personalmente la clave de Gregson (celos profesionales, imagino), pero se fía de la firma de Holmes. El propio Gregson no ve variar la validez de su propia clave (a fin de cuentas, si no te puedes fiar de tí mismo, ¿de quién podrás hacerlo?), pero ve con agrado una firma adicional que dará fe acerca de la validez de dicha clave. Y a Sebastian Moran le da igual, ya que no se molesta en actualizar su propio archivo de claves y ni siquiera sabe cuál es la clave de Gregson. Pero si lo hiciese, sabría que la nueva firma en la clave de Holmes es la del Inspector Lestrade, en lugar de conformarse con leer "Unknown signer Key ID is 0x1C97CC13"

Los esquemas confianza-validez permiten reparar golpes sufridos por la red de confianza. Uno, tan sencillo como útil, es el del cambio de nombre o dirección. Cuando Watson abandonó la calle Baker para vivir en casa propia, se vio en la obligación de cambiar de dirección de correo electrónico. De ese modo, crea un nuevo identificador de clave [Edit/Add Name] y lo establece como identificador predeterminado [Set as Primary User ID]. Supongamos que el identificador antiguo era Doctor Watson (Watson@baker.london.uk) y el nuevo es John Watson (jdwatson@md.london.uk). ¿Qué tiene que hacer Holmes para adaptarse a la nueva circunstancia?

Simplemente, importar la clave de Watson con el nuevo ID de usuario. En esta clave aparece ambos ID, el nuevo (John Watson) y el antiguo (Doctor Watson), ambos representados con el icono de un sobre. Ambos IDs han sido automáticamente firmados con la clave del propio Watson, de modo que ambos son aceptables y aceptados; cualquier clave firmada con jdwatson@london.uk es tan válida como la que esté firmada como Watson@baker.london.uk. La clave en sí no ha sido modificada esencialmente: todas sus propiedades (ID de clave, huella, algoritmo de cifrado, etc) permanecen inalteradas. La red de confianza no se altera por un cambio de nombre de clave, con tal que nos molestemos en actualizar las claves públicas de nuestro archivo periódicamente (para eso está la sincronización de claves con el servidor). Así, la pregunta de novato "he cambiado de dirección electrónica, ¿debo crear claves nuevas?" tiene una sencilla respuesta: no, simplemente cambia el ID de usuario de tu clave, y vuelve a distribuirla (enviarla a un servidor de claves bastará).

Otro caso. Watson ha decidido inhabilitar [disable] la clave del inspector Lestrade. ¿Afecta eso a la validez/confianza de dicha clave, o de otras claves firmadas por Lestrade? La respuesta es no. La opción habilitar/inhabilitar [enable/disable] sólo sirve para gestionar las claves más cómodamente. Por ejemplo, para evitar que al cifrar un mensaje de correo electrónico aparezca gran cantidad de claves que raramente se usan. Es algo así como tener una pequeña agenda con unas cuantas direcciones solamente para no tener que echar mano de la incómoda y pesada guía telefónica. Pero no interfiere en absoluto con la red de confianza. Las claves siguen teniendo validez y confianza aunque estén temporalmente inhabilitadas.

¿Qué hay de las claves revocadas? Eso es un tema distinto. Revocar una clave es un paso irreversible: indica a todos que esa clave ya no debe ser aceptada en absoluto. Eso ocurre cuando el creador de la clave ha perdido el control sobre ella (ya sea que ha perdido su clave privada o que ha olvidado su contraseña), o porque cree que ha caído en otras manos. En ese caso, publica de nuevo su clave, pero tras haberla revocado. Cualquiera que reciba dicha clave sabrá que ya no sirve para cifrar o firmar. Eso incluye las firmas. A partir de ahora, y a efectos de "red de confianza", es como si dicha clave ya no tuviese ni validez ni confianza. Aunque la firma de dicha clave en otra clave no desaparece, no tiene ningún efecto. Uno puede incluso firmar una clave revocada de otro; pero ello no da validez ni permite otorgar confianza a dicha clave bajo ninguna circunstancia.

Veamos un caso de mayor envergadura. Sherlock Holmes ha decidido pasarse a las claves Diffie-Hellman, así que crea una nueva clave. Pero entonces, ¿qué pasa con la red de confianza que ha tejido alrededor de su vieja clave RSA? ¿De qué le sirven las firmas tan cuidadosamente incluidas en la clave anterior? Si hay que volver a empezar cada vez que se cambia de clave, mal vamos. A ver quién convence al explorador Sigerson para que vuelva del Tibet. Afortunadamente, a Holmes le basta con lo siguiente: firmar su nueva clave (DH) con la antigua (RSA) y exportarla al servidor de claves. Así, cuando Watson importa la nueva clave, verá que es válida. ¿Verdad? Pues no necesariamente.

Esto es para que no pierdas el hilo: si hay una firma A en una clave B, la clave B tendrá validez si la clave A es de confianza; si la clave A tiene validez (pero no confianza), eso no significa que la clave B haya de ser válida. Recuerda, que una clave sea válida no significa que su dueño sea de fiar a la hora de firmar claves. Pero ahora hemos de tener sentido común. Si la clave Holmes-DH tiene la firma de la clave Holmes-RSA, sólo puede haber dos posibilidades: o bien Holmes ha firmado una clave que él mismo ha creado, o bien una que ha creado otra persona. Ahora bien, ni el más descuidado usuario firmaría una clave que lleva su nombre y dirección electrónica pero ha sido creada por otro; eso será aún más cierto si el firmante es una persona de confianza. Así que podemos, sin equivocarnos demasiado, suponer que la clave nueva de Holmes ha sido creada por la misma persona que creó la antigua.

Procedamos ahora a indicar cómo el receptor de la nueva clave puede ajustar las condiciones de validez y confianza para ésta, para igualarlas a las de la clave antigua; suponemos, por descontado, que la clave nueva lleva la firma de la clave antigua. CA=clave antigua; CN=clave nueva; RC: receptor de la clave

© Arturo Quirantes 2005.  Correo electrónico: aquiran arroba ugr.es

Vuelta a la sección Informes del Taller de Criptografía