Modelos de confianza

Las relaciones de confianza entre múltiples AC son necesarias para asegurar que todos los subscriptores no tengan que estar subscritos a una única AC, lo cual sería imposible de escalar, administrar y asegurar [10].

La confianza se puede establecer cuando una primera entidad puede decir que una segunda es de confianza cuando esta da por hecho que la segunda se comportará exactamente como la primera lo espera [10].

Los certificados se obtienen de diferentes AC, de acuerdo a la organización o comunidad a la que se es miembro. Típicamente varias comunidades están ligadas por su confianza a una AC. Hay dos modelos tradicionales para soportar la confianza entre varias AC: jerárquica y en red [8].

Fig. 3.2 Modelos de confianza [10].

La Fig. 3.2 a), muestra el modelo jerárquico el cual permite relaciones de confianza, donde la AC raíz es la Autoridad ancla para todas las entidades, ya que es el inicio de las relaciones de confianza de la infraestructura. Contiene AC hojas, las cuales emiten certificados a entidades finales

(usuarios, procesos, equipos o código). Cada AC puede certificar a otras AC subordinadas a ella de forma unidireccional. Esta forma de confianza es conveniente en ambientes que requieren de la emisión de una gran cantidad de certificados [10].

La Fig. 3.2 b), muestra el modelo de red, donde el establecimiento de confianza se da entre las AC, por lo que no se pueden considerar subordinadas entre sí debido a la falta de una AC raíz, entonces los usuarios se basarán en su propia AC. La validación de certificados se realizará a través de la ruta que llega hasta la AC que expide el certificado. Es común que cada AC certifique la llave pública de las demás AC, creando una confianza bidireccional [10].

Hay relaciones donde toda la confianza recae en un modelo donde solo hay una AC, la cual se encarga de realizar todas las tareas y actividades para la organización. Esta configuración es la más simple de implementar, pero si la llave pública de la AC cambia, toda la arquitectura debe ser reconfigurada. Además no es adecuada para comunidades de usuarios grandes.

Se tiene también un modelo con una AC puente, la cual establece la relación de confianza de igual a igual entre las diferentes comunidades de usuarios, actuando como un concentrador. Para implementarla se requiere de información adicional (certificación de las llaves públicas de las AC involucradas entre sí mismas) que establezca la relación de confianza entre las AC, lo que quiere decir que los certificados son más complejos y los usuarios deben estar preparados para procesar y usar esta información adicional durante la validación de los caminos de certificación. Otro inconveniente es que no han sido establecidos aún los mecanismos de distribución y obtención de información de estado de los certificados de una manera útil para los usuarios y sus aplicaciones [10].

También se tienen los modelos híbridos los cuales permiten mezclar las arquitecturas de certificación mencionadas y conectar un modelo jerárquico con uno de red.

Cuando una AC emite un certificado a otra AC se dice que es una certificación cruzada de un solo sentido, ahora bien si ambas AC se emiten certificados, la certificación cruzada es de dos sentidos. De acuerdo a la cuarta edición de X.509 la certificación cruzada es cuando un certificado se emite y el propietario es una AC diferente de quien la emite [11]. Esto se da en la combinación por la necesidad de la interacción y la confianza dada entre organizaciones. Así los usuarios de una comunidad pueden validar sus certificados con otra comunidad.

En el nivel más básico de una ruta de certificación entre la AC ancla, la cual gobierna las comunidades y el certificado objetivo, es la cadena de nombres. Ver Fig. 3.3. Esto es, la ruta comienza con el certificado auto firmado por la AC, que contiene la llave pública y termina con el certificado del usuario final, pasando por las AC intermedias.

En el modelo jerárquico, y siguiendo el estándar X.509, si una entidad envía un e-mail firmado a la entidad . Para verificar la firma digital, es necesario construir la ruta de certificación entre el y . En este caso la AC raíz es la de mayor confianza para todos los usuarios del modelo jerárquico. Básicamente desea conocer si la AC raíz ha establecido una relación de confianza con el emisor del certificado de . En otras palabras, si hay capacidad para resolver la ruta de AC-> AC1-> AC2-> A, entonces se tendría una ruta de certificación candidata que podría ser aceptada como ruta de certificación valida.

La construcción de rutas de certificación en el modelo jerárquico, es generalmente sencillo. Las rutas son típicamente construidas hacia el frente, es decir, se comienza de la AC raíz y se continúa con las AC intermedias hasta llegar a la hoja del usuario final, de acuerdo a la estructura del árbol. Una vez conocida la AC ancla para y , y con la ruta de certificación candidata (AC-> AC1-> AC2->A, de acuerdo a la Fig. 3.4), los certificados pueden ser reconocidos y válidos.

En el caso anterior, la unidireccionalidad permite representar la línea de emisión de certificados en un sentido. La bidireccionalidad, es decir, la dirección a ambos lados representa una certificación cruzada mutua, para estos casos la ruta de certificación es diferente, tomando dos dominios, uno jerárquico y otro en red se da el siguiente caso. Ver Fig. 3.5:

Una entidad recibe un e-mail firmado por . La tarea es construir la ruta de certificación entre y la AC de confianza y reconocida por . Para lo cual de forma inversa se comienza la ruta, donde fue certificado por la AC6, a esta AC4 y a la última tiene una certificación cruzada en dos direcciones con AC (C  AC6  AC4  AC). Una vez conocida la AC, no puede ser posible continuar construyendo la ruta de forma inversa, entonces ahora se construye el resto de la ruta de forma normal (ACAC1AC2A), descubriendo que el certificado de es emitido por la AC2 y el certificado de esta AC2 es emitido por la AC1 y el de la última lo emitió la AC raíz.

En algunos casos es más eficiente construir rutas de forma inversa, donde varios de ellos se resolverán con una única ruta de certificación y en otros se podrán construir varias rutas alternativas por la existencia de múltiples certificados por AC, Fig. 3.5.

Fig. 3.5 Certificación cruzada entre los modelos jerárquico y de red.