Gunnar Wolf

El establecimiento de cualquier forma de comunicación apoyada por la criptografía de llave pública entre dos entidades determinadas presupone para cualquiera de ellas confianza en la identidad de su contraparte. Esto es, si Alice desea enviar un mensaje a Bob, sea cifrándolo para asegurar la confidencialidad, firmándolo para asegurar integridad y no repudio, o cualquier otra operación/propiedad, el primer paso para Alice debe ser verificar que la llave para la cual esté cifrando pertenezca a Bob y no a un impostor, al igual que Bob debe asegurarse de que la llave firmante sea efectivamente la de Alice, y de nadie más que ella.

En un entorno donde son posibles las verificaciones fuera de banda (donde Alice y Bob se conocen y pueden emplear canales para intercambiar sus llaves sin que haya margen de duda, como podría ser un encuentro en un café) este problema queda resuelto. Sin embargo, la realidad de Internet plantea una situación claramente distinta. En una transacción en línea típica, Alice y Bob no se conocen, y ni siquiera verse en persona les aseguraría que dicha persona es el destinatario de la comunicación y no Eve, Mallory u otro de los personajes del catálogo criptográfico. La respuesta que se ha encontrado ante este planteamiento es el uso de certificados y el depósito de confianza en terceras entidades, los certificadores, lo que se conoce como infraestructura de llave pública (PKI por sus siglas en inglés).

Hay dos modelos principales para hacer esto:

Modelo jerárquico

Se designa a uno o un grupo de participantes de la red como certificadores raíces de confianza. Todos los usuarios confiarán en los certificados emitidos por éstos, o por aquellos certificadores delegados por ellos. Los certificados quedan entonces dispuestos siguiendo la estructura de una serie de árboles, con nodos raíz bien conocidos.

Modelo entre pares

Se establece que todo usuario de la red es un certificador, y se instituye la costumbre de firmar mutuamente los certificados de todas aquellas entidades en cuya identidad se tenga plena confianza. Al hacer pública la lista de certificados, todo usuario podrá trazar rutas de confianza siguiendo a los certificados que unan al Alice con el supuesto Bob. Si se puede establecer dicha ruta, y es suficientemente robusta (pueden emplearse diversas métricas para establecerlo), la identidad de Bob se toma por buena.

El primer modelo es el empleado por los navegadores Web, en el que un grupo de decenas de autoridades certificadoras definidas por los desarrolladores del navegador o del sistema operativo obtienen confianza plena. El segundo modelo impera cuando las relaciones son más bien horizontales (no de cliente-servidor, sino persona a persona), y han logrado fuerza particularmente en las comunidades de desarrollo de software libre, necesariamente al situarse éstas sobre una amplia distribución geográfica. Ambos modelos tienen sus fortalezas y debilidades.

Esta exposición abunda sobre un estudio de caso realizado en una comunidad comparativamente grande (el proyecto Debian, con cerca de 1,000 desarrolladores miembro, y con más de 20 años de existencia) relativo a la dificultad y resultados obtenidos de la adopción de políticas encaminadas a asegurar que todas las llaves reconocidas por el proyecto sean de suficiente fuerza criptográfica para asegurar la inviolabilidad de las características de seguridad que el proyecto requiere. El autor es mantenedor del llavero de confianza de Debian, y participó en la planeación, diseño e implementación del proceso que esta presentación describirá, enfrentándose a factores tanto técnicos como sociales para su consecución.