Fortalecimiento del llavero de confianza en un proyecto geográficamente distribuido

Submitted by gwolf on Thu, 11/19/2015 - 11:34
TitleFortalecimiento del llavero de confianza en un proyecto geográficamente distribuido
Publication TypeReport
Year of Publication2015
AuthorsWolf G
Refereed DesignationNon-Refereed
Prepared forIII Congreso de Seguridad de la Información ESIMECU-IPN; Congreso de Seguridad en Cómputo UNAM
CityMéxico DF, México
KeywordsDebian, identidad, Seguridad
Abstract

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.

AttachmentSize
Poster presentado en el III Congreso de Seguridad de la Información (ESIMECU-IPN, oct 2015)8.77 MB
Presentación empleada para el Congreso de Seguridad en Cómputo 2015 de DGTIC/UNAM2.99 MB

Post new comment

The content of this field is kept private and will not be shown publicly. If you have a Gravatar account associated with the e-mail address you provide, it will be used to display your avatar.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <br> <b> <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <blockquote> <img> <h1> <h2> <h3> <tt> <pre> <strike> <table> <tr> <th> <td>
  • Lines and paragraphs break automatically.
  • Use <bib>citekey</bib> or [bib]citekey[/bib] to insert automatically numbered references.
  • Use [fn]...[/fn] (or <fn>...</fn>) to insert automatically numbered footnotes.
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>. The supported tag styles are: <foo>, [foo].

More information about formatting options

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
Keep in mind that all comments will also have to be administrator-moderated. Don't waste your time writing a spam that no one will read.
u
a
5
z
4
y
Enter the code without spaces and pay attention to upper/lower case.