INSTITUTO POLITÉCNICO NACIONAL
ESCUELA SUPERIOR DE INGENIERÍA MECÁNICA Y ELÉCTRICA
SECCIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN
ANALISIS Y DISEÑO DE UNA AUTORIDAD CERTIFICADORA
Trabajo que para obtener el grado de
Especialidad en Seguridad Informática y
Tecnologías de la Información que
P R E S E N T A
Adrián de la Torre Guzmán
Directores de Tesina:
M. EN C. MARÍA AURORA MOLINA VILCHIS M. EN C. GINA GALLEGOS GARCÍA
AGRADECIMIENTOS
A DIOS.
Por permitirme avanzar en mi
carrera profesional.
A MI MADRE.
Quien me dio vida y ha estado a
mi lado y me ha apoyado en todas
las circunstancias buenas y malas
de mi vida.
A MIS HERMANOS.
Quienes me han apoyado
constantemente.
A MI INSTITUCIÓN.
Que me permitió seguir
estudiando y desarrollar este
trabajo.
A MI ASESORA AURORA.
Maestra de gran conocimiento y
profesionalismo, por guiarme y
conducirme a la culminación de
INDICE GENERAL
ACTA DE REVISION ii
CARTA DE CESION DE DERECHOS iii
AGRADECIMIENTOS iv
INDICE GENERAL v
INDICE DE TABLAS vii
INDICE DE FIGURAS viii
RESUMEN x
ABSTRACT xi
JUSTIFICACIÓN xii
HIPÓTESIS xiii
OBJETIVO xiv
INTRODUCCIÓN xv
CAPÍTULO I. INTRODUCCIÓN A LA AUTORIDAD DE CERTIFICACIÓN.
1.1. Conceptos generales 1
1.2. Características 2
1.3. Aplicaciones que la requieren 3
1.4. Funciones básicas de la AC 4
1.5. Restricciones y limitaciones 5
CAPÍTULO II. FUNDAMENTOS TEÓRICOS DE LAS AUTORIDADES DE CERTIFICACIÓN (AC).
2.1. Conceptos básicos de la seguridad criptográfica 9
2.2. Criptosistema 10
2.2.1. Criptosistema simétrico 12
2.2.2. criptosistema asimétrico 15
2.2.3. Comparación de ambos sistemas de cifrado 17
2.3. Funciones hash 18
2.4. Firma Digital 19
2.5. Terceras entidades de confianza (TTP –Trusted Third Path) 21
2.5.1. Tipos (personas o entidades) 22
2.5.2. AC públicas 23
2.5.3. AC privadas 24
2.6. Certificados digitales 24
2.6.1. Lista de certificados revocados 27
2.6.2. Verificación de certificados 29
2.6.3. Directorios de certificados 30
CAPÍTULO III. ANÁLISIS DE LA ARQUITECTURA.
3.1. Componentes básicos 31
3.1.1. Generación de certificados 31
3.1.2. Revocación de certificados 32
3.1.3. Lista de certificados revocados 33
3.1.4. Renovación de certificados 33
3.1.5. Administración 34
3.1.6. Repositorio de certificados y CRL 36
3.2. Modelos de confianza 38
3.3. Establecimiento de las identidades 43
3.4. Servicios 44
3.5. Certificados 45
3.5.2. Solicitud 46
3.5.3. Modelos para la administración 47
3.5.4. Validación 48
CAPÍTULO IV. DISEÑO DE COMPONENTES DE LA AC
4.1. Requisitos 49
4.2. Políticas y criterios para la emisión de certificados 50
4.3. Metodología 55
4.3.1. Diagramas de caso de uso 56
4.3.2. Diagrama de actividades. 57
4.3.3. Diagrama de secuencia. 59
4.4. Casos de uso 61
4.5. Diagramas de actividades 68
4.6. Diagramas de secuencia 75
4.7. Diagrama de objetos 82
CONSLUSIONES Y RECOMENDACIONES 83
GLOSARIO DE ACRONIMOS 85
REFERENCIAS 87
INDICE DE TABLAS Y FIGURAS
Tabla 1.1 Comparativa de software AC. 17 Tabla 2.1 Comparativa entre criptosistemas 17
Figura 2.1 Criptosistema. 11
Figura 2.5 Proceso de firma digital. 20 Figura 2.6 Certificado Digital de Internet Explorer 26 Figura 2.7 Certificado revocado de Internet Explorer 29 Figura 3.1 Información DIT. 37 Figura 3.2 Modelos de confianza. 38 Figura 3.3 Cadena de nombres. 40 Figura 3.4 Construcción de ruta en modelo jerárquico. 41 Figura 3.5 Certificación cruzada entre los modelos jerárquico y de red. 43 Figura 3.6 Cadena de identificador de llave. 44 Figura 4.1 Simbología de diagrama de casos de uso. 57 Figura 4.2 Simbología de diagrama de actividades. 59 Figura 4.3 Ejemplo diagrama de secuencia. 60
Figura 4.4 Diagrama de casos de uso de una AC. 61
Figura 4.5 Diagrama de actividades generar certificado. 68
Figura 4.6 Diagrama de actividades de renovación de certificados. 69
Figura 4.7 Diagrama de actividades de revocación de certificados. 70
Figura 4.8 Diagrama de actividades de auditoría. 71
Figura 4.9 Diagrama de actividades de generación de CRL. 72
Figura 4.10 Diagrama de actividades de respaldos de base de datos y registros de auditoría.
73
Figura 4.11 Diagrama de actividades de administración de AC. 74
Figura 4.12 Diagrama de secuencia generación de certificados. 75
Figura 4.13 Diagrama de secuencia renovación de certificados. 76
Figura 4.14 Diagrama de secuencia revocación de certificados. 77
Figura 4.16 Diagrama de secuencia generación de CRL. 79
Figura 4.17 Diagrama de secuencia de respaldos de base de datos y registros de auditoría.
80
Figura 4.18 Diagrama de secuencia de administración de AC. 81
RESUMEN
ABSTRACT
JUSTIFICACIÓN
HIPÓTESIS
OBJETIVO
INTRODUCCIÓN
La información es poder, y quien la posea tiene control y dominio sobre aquellos que no la tienen, por ello es tan importante adquirirla, almacenarla y transmitirla, manteniendo su autenticidad, integridad y confidencialidad. Es por ello que se debe conocer y estar seguros del origen e integridad de esa información. Uno de los mecanismos de autenticidad de mayor impacto por su fortaleza, es el empleo de certificados digitales, elementos empleados para autenticar llaves de las entidades dentro de una comunicación y transmisión de la información, estos certificados adquieren su grado de confiabilidad debido a su emisor, la AC.
Este trabajo presenta el análisis y diseño de las funciones, procedimientos y componentes de una AC para la emisión, revocación y renovación de certificados digitales, para lo cual en el capítulo 1 se da una introducción a la Autoridad de Certificación proporcionando información del concepto general, características y funciones básicas.
El capítulo 2 presenta los fundamentos teóricos en los que se ampara el presente trabajo, refiriéndose a los conceptos básicos de la seguridad criptografica como la criptografía de llave pública y criptografía de llave secreta, entre otros fundamentos.
El capítulo 3 presenta el análisis de la arquitectura de una Autoridad Certificadora, describiendo sus componentes, modelos de confianza, establecimiento de identidades, servicios y certificados.
El capítulo 4 presenta el diseño que se realizó a partir del análisis del capítulo anterior, empleando para ello el lenguaje de modelado unificado.
CAPÍTULO I
INTRODUCCIÓN A LA AUTORIDAD
1.1. Conceptos generales
Toda comunicación entre dos o más entidades debe ser identificada y
autenticada por seguridad, y más aún en la transmisión de información digital
sensible como las llaves públicas, a través de una red pública, también es
importante que la información recibida no sea denegada por su creador, una
forma de lograr esta tarea es mediante el empleo de certificados digitales, los
cuales son emitidos, revocados y publicados por una tercera entidad de
confianza llamada AC.
Una Autoridad Certificadora “AC”, es similar a una notaría, ya que la AC
verifica y confirma la relación de una llave pública con su propietario. Después
certifica la llave pública, por medio de un certificado digital.
Un certificado digital, permite validar la identidad del otro extremo de
una comunicación ya sea una persona, un dispositivo o un proceso. El
certificado de la llave pública es una estructura de datos protegida por la firma
digital de la AC que lo emite, la cual sirve para validar y afirmar que los datos
en él, no han sufrido alteraciones.
La lista de certificados revocados (Certificate Revocation List – CRL),
es un mecanismo útil para revisar el estado actual del certificado, consta de un
conjunto de certificados que ya no son de confiar, por lo que pasan a una lista
Tanto los certificados de llave pública como la CRL, deben estar
disponibles para todo usuario que requiera conocer el estado del certificado,
un mecanismo para obtener el estado, es el protocolo en línea del estado del
certificado (On line Status Certificate Protocol – OSCP), de manera que
estando en línea se puede obtener el estado del certificado.
Entre los elementos más importantes del certificado son la versión, la
firma, el emisor y fecha de validación.
1.2. Características
Las características principales con las que una AC debe contar son en
primer lugar el nivel de confianza de aceptación por parte de sus usuarios,
esta confianza puede ser de facto o de jure. Como ejemplo se puede
mencionar a Verisign, quien ha emitido certificados con una gran historia y
vanguardia siendo una AC de facto. Cuando en un grupo organizacional se
impone a una entidad como AC por norma entonces se dice que es una AC de
jure.
Además la AC debe ser disponible, es decir debe contar con una alta
capacidad de respuesta, ya que el estado del certificado para algunas
transacciones se requiere del estado en un momento específico, por ejemplo
en una transacción de dinero entre bancos, para lo cual se emplean
certificados como mecanismo de autenticación y de firma. En ningún
momento la AC debe dejar de funcionar, es decir, debe trabajar de forma
constante en todo momento.
Otra característica es que debe ser escalable para que permita agregar
aceptar el cambio de versiones de forma transparente.
La seguridad es otra característica, a fin de que la información que
maneje, no pueda sufrir alteraciones parciales o totales. Tampoco debe ser
susceptible a ataques a fin de evitar la denegación del servicio.
Frecuentemente debe ser amigable, es decir, debe contar con un
sistema de administración con interfaces de fácil interacción con el sistema,
para que cualquier usuario con los privilegios correspondientes y
conocimientos mínimos, pueda interactuar con las pantallas de manejo de la
AC.
1.3. Aplicaciones que la requieren
Toda organización requiere del intercambio seguro de información, ya
sea entre sus áreas de trabajo o con agentes externos a la misma, esto se
logra mediante el uso de servicios de seguridad de la información como son:
autenticación, confidencialidad, integridad y no repudio. El uso de certificados
digitales, permiten el empleo de mecanismos para cumplir algunos de estos
servicios, como lo es el protocolo de socket seguro (Secure Socket Layer –
SSL), el cual provee servicios de autenticación, confidencialidad, mediante la
autenticación de llaves intercambiadas para generar el canal seguro, este es
un protocolo muy utilizado en comunicaciones, comercio electrónico e
interacciones de forma segura en sitios Web, intranet y extranet.
También los servicios públicos en la Internet para ser considerados
seguros requieren de certificados digitales. Todo explorador web a través de
un proceso de autenticación solicita el certificado digital del servidor para
verificar la identidad del servicio y su contenido y así avise al usuario si es o
tienda virtual puede estar seguro de su interacción con la tienda.
Otro uso de certificados digitales es en las comunicaciones entre
equipos (routers, PC) empleando para tal efecto redes privadas virtuales
(Virtual Private Network - VPN), las cuales en la fase de autenticación
requieren certificados digitales de ambas partes de la comunicación para
establecer un canal seguro.
1.4. Funciones básicas de la AC
Como tercera entidad de confianza, se espera que la AC para mantener
su estado de confianza realice las siguientes funciones:
La función primordial de la AC es generar certificados digitales que
garanticen la relación intrínseca entre llave pública, su llave privada
correspondiente y al dueño del certificado, así mismo la renovación y
revocación del certificado.
Otra función primordial es la generación de su par de llaves (pública y
privada) de la AC, así como mantener de forma segura sus llaves secretas,
las cuales se usan para certificar las llaves externas a la AC.
La renovación de certificados digitales es una actividad que se realiza cuando un certificado ha caducado, es decir, su periodo de validez ha
fenecido, por lo cual se requiere de la generación de un certificado con una
llave pública nueva y con un nuevo periodo de validez.
La revocación de certificados se realiza cuando:
2. Perdida u olvido de la contraseña para el empleo de la llave privada.
3. El certificado ha caducado.
4. A solicitud de la entidad propietaria.
También debe garantizar la auditoría de eventos y acciones en el sistema
de forma segura, con el fin de estar en condiciones de comprobar o
verificar cualquier uso inapropiado del sistema así como de las fallas que
ocurran.
La AC para la generación de certificados debe realizar funciones de
registro y validación de usuarios bajo las políticas de certificación1 y
asegurar que la persona es quien dice y es dueña de la llave privada
correspondiente a la llave pública por certificar.
1.5. Restricciones y limitaciones
Debido a la importancia que una AC adquiere por la cantidad, utilidad e
importancia de los certificados digitales que administra, es indispensable que
cuente con la mayor cantidad de medidas de seguridad posible, de esta forma
sea instalada en un área perfectamente acondicionada y con medidas de
seguridad físicas como el control de acceso, sistema contra incendios, aire
acondicionado; así como la seguridad de la red y las comunicaciones para
evitar cualquier tipo de robo de certificados, suplantación de servicios de la AC
entre otros, y estar en condiciones de tener un servicio con alta disponibilidad.
Por la alta cantidad de certificados que administra, genera, renueva,
revoca y valida certificados, así como la generación de llaves, la AC requiere
de un hardware con alta capacidad de procesamiento, memoria y
almacenamiento de tal forma que los servicios que ofrece sean
proporcionados de forma expedita.
Otra limitación es que para un buen empleo e implementación, es
necesario contar con personal especializado en seguridad conocimiento
profundo de las funciones y procesos de la AC.
Siendo de importancia cada uno de los certificados y de su necesidad
en la organización, es conveniente contar con un conjunto de políticas y
procedimientos que auxilien en la recuperación de desastres, esto para tener
un sistema redundante del servicio y si por algún motivo como un desastre
natural o humano (terremoto, incendio, inundación, fallo de energía eléctrica,
etc.) el servicio mantenga su estado de disponibilidad sin pérdida de
certificado alguno.
1.6. Estado actual de desarrollo
Hoy en día existen muchas aplicaciones que implementan este servicio
de certificación para compañías o empresas. Estas aplicaciones son
desarrolladas en diferentes lenguajes y paradigmas de programación, siendo
de código abierto o no. Lo cierto es que ninguna de ellas explica o da a
conocer el análisis de los componentes y sus interacciones entre los procesos
que desarrollan, tampoco se conoce el diseño de la aplicación en sí.
Como ejemplo de las diferentes aplicaciones se tiene Key One CA, la
cual ofrece toda la gama de componentes necesarios para el empleo de la AC,
así mismo ofrece una instalación fácil, para plataforma Windows, sin embargo
Otra aplicación que requiere de una inversión económica es Pretty
Good Privicyo también conocida como PGP.
Entre las aplicaciones gratuitas se tienen GPG la cual es muy parecida
a PGP solo que no se cuenta con una administración del sistema visual, todos
los comandos o instrucciones que se realicen sobre el software son en línea
de comandos. Otra aplicación parecida a PGP es OPENSSL, estas
aplicaciones pueden trabajar en sistemas operativos Linux.
Otra aplicación gratuita y muy completa es EJBCA, desarrollada en
java, es una aplicación web que incluye todos los componentes de una AC, la
cual hace uso de JBOSS y puede interactuar con gestores de bases de datos
como MySQL, Postgres, Oracle, DB2, entre otros, sin embargo se requiere de
un conocimiento exacto de las funciones de la AC para su mejor empleo.
Tabla 1.1 Comparativa de software AC.
Software S. O. Hardware Amigabilidad Costos
Key one CA Windows,
Solaris
Intel,
Sparc
Se desconoce la
interacción del sistema
Licencia de uso,
licencia de DB.
PGP Windows,
Unix,
MacOS
Intel Requiere conocimiento
avanzados para
operarlo, con pantallas
sencillas.
Licencia de uso.
GPG Windows, Unix, MacOS, BSD. Intel, Sparc, amd64
Requiere conocimientos
avanzados, opera con
línea de comandos
Licencia GNU.
OpenSSL BSD,
Linux
Intel. Requiere conocimientos
avanzados, opera con
línea de comandos
CAPÍTULO II
FUNDAMENTOS TEÓRICOS DE
LAS AUTORIDADES DE
2.1. Conceptos básicos de la seguridad criptográfica
La información es un activo2 de gran importancia y es esencial para la organización y su entorno, por consecuencia necesita ser protegida de forma adecuada. Hoy en día existe una diversidad de formas de almacenamiento como memorias USB, discos duros externos, discos compactos, etc., también esta información es transmitida por medios inseguros como las redes públicas (Internet), donde la información está expuesta a ser intervenida, monitoreada o robada por entidades no autorizadas, lo cual amenaza con causar daños a la organización [1].
Para mantener la seguridad de la información se cuenta con la Criptología, esta es una ciencia que abarca el estudio de la Criptografía y el Criptoanálisis, y algunos autores también incluyen la Esteganografía [2].
Cuando se habla de la Criptografía, se refiere a la seguridad de la información mediante el empleo de las Matemáticas. La primordialidad de la criptografía es en primer lugar mantener la información accesible únicamente al personal autorizado quedando excluida toda persona que no debe saber de los datos, a esto se le llama confidencialidad; también debe mantener los datos íntegros, es decir garantizar que los datos no sufran ningún tipo de sustitución, inserción o eliminación de forma parcial o total; así mismo hay que identificar a las partes que están involucradas en una comunicación y
2
validarlas entre sí, dando pie a tener, tanto el origen de los datos como su contenido, identificados por cada parte, a esto se le conoce como autenticación; y por último, más no por ello menos importante el no repudio, es decir prevenir que una entidad niegue sus compromisos o acciones, un procedimiento para evitarlo es emplear una tercera parte de confianza que ayude actuando como juez y parte para resolver cualquier problema de denegación de acciones o compromisos [2],[3].
2.2. Criptosistema
El comunicar, transmitir o compartir información ha sido una de las necesidades básicas de los seres humanos. Para realizar esta comunicación es necesario que existan al menos dos entidades (personas, instituciones, empresas, o procesos), un canal de comunicación (la atmósfera, líneas telefónicas, entre otros) y un estándar para la comprensión de la información (alfabeto), estableciendo si la información se transmite de forma inteligible “mensaje en claro o texto en claro”, o ininteligible, a lo que se le llama “mensaje cifrado, texto cifrado o criptograma”.
Fig. 2.1 Criptosistema. a) cifrado, b) descifrado
Nomenclatura empleada en Fig. 2.1. Transformación matemática,
en algunos casos la función de cifrar y descifrar es la misma.
Espacio de la llave.
Espacio de texto en claro. Espacio de texto cifrado.
2.2.1.
Criptosistema simétrico [image:28.612.192.485.245.492.2]En este sistema se emplean las ideas de la criptografía clásica (transposición y sustitución). Se le conoce así por el uso de una misma llave, llamada llave secreta para dar pie al texto cifrado y al texto en claro en un criptosistema para cifrar y descifrar mensajes [4].
Fig. 2.2. Criptosistema de llave secreta. a) cifrado, b) descifrado.
La Fig.2.2 (a), muestra el proceso de cifrado simétrico, es decir, al mensaje en claro se le aplica una transformación mediante la función de cifrar que está comprendida por un algoritmo matemático que hace uso de una llave secreta , dando por resultado el
mensaje cifrado , de la siguiente manera
La Fig. 2.2 (b), muestra el proceso de descifrado simétrico, es decir, al mensaje cifrado se le aplica una transformación mediante la función de descifrar que está comprendida por un algoritmo matemático que hace uso de una llave secreta , dando por resultado el mensaje en claro , de la siguiente manera .
Nomenclatura empleada en Fig. 2.2. Espacio de la llave
Llave secreta
Espacio de texto en claro. Espacio de texto cifrado.
Función de cifrar. (1)
Función de descifrar. (2)
Como ya se mencionó, la criptografía de llave simétrica emplea la misma llave para obtener tanto el texto cifrado como el texto en claro, esto origina la necesidad del intercambio de la llave secreta entre las entidades emisora y receptora. Es decir, si el mensaje cifrado es enviado de una entidad “ ”, a una entidad “ ” que se encuentra geográficamente a varios kilómetros, es importante que la entidad “ ” tenga la llave con la que se originó el texto cifrado, de otra forma no podrá obtener el texto en claro; existe la posibilidad que durante el intercambio de llave, ésta sea interceptada.
El o los poseedores de la llave secreta deberán mantener la llave lo más segura posible y así evitar que personas no autorizadas conozcan su información.
El número de llaves para el intercambio de mensajes va de la mano con el número de entidades involucradas es decir, para dos entidades se requiere una llave, para tres entidades tres, para cuatro entidades seis, lo cual nos lleva a deducir la siguiente ecuación para
entidades:
(3)
Lo cual origina un caos en la administración de llaves, no se diga la seguridad en el intercambio de las mismas.
Fig. 2.3 Administración de llaves.
Los algoritmos más conocidos para este sistema de cifrado son DES, 3DES, AES, TwoFish y RC4. Siendo la distribución de llaves un problema y la parte débil de la criptografía de llave secreta, ya que durante la transmisión de la llave pude ser perdida o robada, provocando que el criptosistema pierda su seguridad [4].
0 200 400 600 800
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39
N ú m e ro d e l la v e s
2.2.2. Criptosistema asimétrico
En 1976 Diffie y Helmman desarrollaron un algoritmo de llave pública “DH”, el cual se basa en funciones matemáticas en lugar de operaciones simples (permutación o sustitución como en el cifrado de llave secreta) sobre bits. Permite el uso de un par de llaves diferentes, una para cifrar llamada “llave pública” y otra para descifrar conocida como “llave privada”, si se tiene la llave pública, es computacionalmente inviable conocer la llave privada correspondiente y de forma inversa cumple la misma propiedad [3],[5].
Para establecer el intercambio de mensajes cifrados, sólo es necesaria una copia de las llaves públicas de los destinatarios, así que para entidades que deseen comunicarse entre sí, solo se requieren pares de llaves.
Nomenclatura empleada en figura 2.4 Llave privada
Llave pública
Espacio de texto cifrado.
Espacio de texto en claro. Par de llave pública y privada de A
Función de cifrar (4)
Función de descifrar (5)
Transformación de cifrado. Transformación de
descifrado
En la figura 2.4 se puede observar como dos entidades y intercambian un mensaje cifrado empleando la criptografía de llave pública, donde la entidad envía su llave pública a para que esta pueda cifrar mensajes y hacerlos llegar de manera segura a la entidad y así solo esta pueda obtener el mensaje en claro.
De esta manera las funciones de cifrado y descifrado para criptografía de llave pública, quedan determinadas en las ecuaciones (4) y (5) respectivamente.
2.2.3. Comparación de ambos sistemas de cifrado
Como se puede observar cada sistema simétrico o asimétrico tiene sus propias ventajas y desventajas, ver tabla 2.1.
Tabla 2.1. Comparativa entre criptosistemas.
CRIPTOGRAFÍA SIMÉTRICA CRIPTOGRAFÍA ASIMÉTRICA Misma llave k para cifrar y descifrar Dos llaves: una para cifrar y otra para
descifrar
Longitud de llave de 64 hasta 256 bits. Longitud de llave de 160, 512, 1024 y 2048.
Generación de llaves moderadamente complicado
Generación de llaves muy complicado, por el manejo de números primos.
Problema de distribución de llaves Sufraga el problema de la distribución de llaves.
Administración de llaves complejo de acuerdo a (3)
La administración de llaves es más sencilla ya que para entidades se requiere de par de llaves .
Procesamiento más rápido, ya que sus operaciones son a nivel bit y byte.
Requiere de mayor uso de CPU por las operaciones matemáticas empleadas. La seguridad recae en mantener en
secreto la llave.
La seguridad está en la dificultad de resolver el problema matemático.
2.3. Funciones hash
Un algoritmo usado en la seguridad es el llamado funcione Hash “ ”, su finalidad es la de obtener una “huella”, esto a partir de un conjunto de bits de longitud variable como entrada, lo que da pie a un mensaje de longitud fija representativa del mensaje de entrada, llamado hash, resultado de hash o valor hash, a esta función hash se le conoce como MDC (MDC – Modification Detection Code). Esta función permite verificar si el mensaje de entrada ha sufrido alguna alteración de agregación, cambio o eliminación del mensaje de entrada [3], [6].
Otra función hash, es la llamada MAC (MAC - Message Authentication
Codes), representada por la cual permite autenticación de mensajes por
medio de técnicas simétricas. Los algoritmos MAC pueden ser vistos como funciones hash con valores de entrada, un mensaje de longitud variable y una llave produciendo una salida de longitud fija, de tal forma que sea inviable producir la misma salida si no se conoce la llave. Las MAC son usadas para dar integridad a los datos, así como también autenticar el origen de los datos en los criptosistemas de llave secreta [3].
Una función hash (en el sentido no restrictivo), tiene como mínimo las propiedades de:
Compresión, mapea una entrada finito arbitraria en longitud de bits, a una salida h de longitud fija ;
Fácil de calcular, dado y la entrada , es fácil de calcular; Unidireccional, dado un valor hash sea inviable encontrar ; Resistencia débil de colisión, dado , es difícil computacionalmente
encontrar ;
encontrar dos entradas distintas tal que produzcan la misma salida es decir [3], [6].
2.4. Firma Digital
Una técnica de autenticación del origen de los datos son las firmas digitales, estas son un número dependiente del secreto conocido por el firmante, adicional al contenido del mensaje firmado. Las firmas deben ser verificables, de tal forma que si hay un problema, una parte imparcial pueda resolver equitativamente el problema, sin necesidad de acceder a la información secreta del firmante.
Un método de firma es el esquema RSA el cual se utiliza hoy en día como uno de los más versátiles y prácticos. También hay otros como el DSA
(Digital Signature Algorithm), Fiat-Shamir, One-time, entre otros.
Una firma digital es una cadena de caracteres asociada a un mensaje (de forma digital) con la entidad de origen. Un esquema de firma digital se compone de un algoritmo de generación de firma y otro de verificación de firma, los cuales hacen correspondencia a los diferentes métodos.
La generación de la firma digital es el proceso de cifrar con la llave privada un mensaje en claro, lo cual permite verificar el origen de los datos y su autenticidad.
(6)
[image:36.612.118.513.298.549.2]Como ya se mencionó el esquema de firma digital cuenta con la generación y verificación de firma, como se ve en la figura 2.5, en la cual se puede ver como una entidad genera la firma de un mensaje en claro, envía tanto el mensaje como la firma a la entidad y esta última puede verificar si el mensaje recibido coincide con la firma.
Nomenclatura empleada en figura 2.5. Llave privada
Llave pública Espacio de texto cifrado.
Espacio de texto en claro.
Espacio de firma. Par de llave pública y privada de la entidad A. Función de generación de firma
(7)
Función de verificación de firma
(8)
Esto permite verificar el origen de los datos mas no la integridad de los mismos, para verificar la integridad, es necesario incluir en el proceso una función hash, .
Función de generación de firma
(9)
Función de
verificación de firma
(10)
2.5. Terceras entidades de confianza (TTP
–
Trusted Third Party)
La TTP puede ser usada para registrar y certificar usuarios y contenidos de documentos y así sirva como juez ante una disputa entre entidades y resolver el problema.
La distribución de llaves públicas es generalmente más fácil que con las llaves simétricas. La integridad (autenticidad) de las llaves públicas es crítica porque se requiere de su certificación, de aquí se determina el “certificado de llave pública”, el cual consiste en parte de datos y de una firma digital. La parte firmada consiste de la firma realizada por parte de la TTP sobre la parte de los datos del certificado.
Antes de crear un certificado de llave pública, la TTP debe tomar medidas apropiadas para verificar la identidad del solicitante y el hecho de que la llave actualmente le corresponda al mismo [3].
A la TTP se le conoce también como una AC.
2.5.1. Tipos
Los usuarios finales, son quienes obtienen sus certificados digitales, los cuales deben mantener sus respectivas llaves privadas de manera segura.
Los certificados pueden ser emitidos como una credencial digital tanto a personas como dispositivos. Por lo que hay numerosos tipos de certificados, cada cual con su rol de uso o su tipo de autenticación, como pueden ser:
individuos. Tienen como mínimo una dirección e-mail, nombre y un identificador único de la persona.
Certificados VPN (IPSec). Son generados usando información de un dispositivo como la dirección IP.
Certificado de dispositivos “manufacturados”. Son para dispositivos particulares (módems), generados y alojados físicamente en la memoria del dispositivo.
Certificados SSL. Usados para asociar una dirección de un servidor Web a un software en particular de un servidor. Este certificado no solo provee un canal cifrado SSL por una petición del explorador del cliente, también ayuda a identificar una URL en particular perteneciente a la organización, previniendo cualquier intento de suplantación.
Certificados de dispositivos inalámbricos. Diseñados para permitir un tipo de funcionalidad SSL. Estos certificados esencialmente crean un certificado SSL maestro y en el middleware emite certificados temporales y más pequeños para los dispositivos finales.
Certificados exactos a la organización. Estos certificados tienen características específicas de la organización, lo cual permite conducirse con confianza y realizar transacciones seguras [7].
2.5.2. AC públicas
La mayoría de los exploradores contienen de forma predeterminada los certificados raíz de estas AC públicas, lo cual las hace confiables y de mayor uso en internet.
Algunos ejemplos de este tipo de AC son: VerySign, WebTrust. GeoTrust, Comodo, Thawte, entre otros.
2.5.3. AC privadas
Toda organización tiene características especiales que las hacen únicas, y el empleo de una AC como parte de sus mecanismos de autenticación y validación de certificados, requieren también de diseños particulares, por lo que se emplean autoridades de certificación implementadas en la misma organización.
Debido a que no son de dominio público, los certificados raíz de estas autoridades de certificación no se encuentran en los exploradores de usuario por defecto, requiere que se repartan los certificados para su validación y confiabilidad con los usuarios finales.
2.6. Certificados digitales
periodo de validez, la llave pública, información del dueño del certificado y el propósito al que está destinado. El estándar de un certificado digital es el X.509, el cual define que información puede ir dentro del certificado, además de la firma, los campos del estándar son [8], [9]:
Versión. Identifica la versión del certificado según el estándar X.509.
Existen tres versiones, cuyas diferencias serán especificadas más adelante.
SerialNumber. Es un número entero asignado por la AC a cada
certificado. El valor del número serial tendrá que ser único para cada certificado expedido por una determinada AC (es decir, el nombre de la AC junto con el número de serie identificarán a un único certificado).
Signature. Identifica el algoritmo y función de hash utilizados por la
AC para firmar el certificado (por ejemplo, md5WithRSAEncryption, sha1WithRSAEncryption, etc.).
Issuer. Identifica a la entidad que ha firmado y expedido el
certificado, es decir, la AC. Este campo debe contener un nombre distinguido (DN –Distinguished Name)
Validity. Cada certificado es válido sólo durante un intervalo de
tiempo, es decir, no es válido antes de la fecha de activación (
not-valid-before), ni después de la fecha de expiración (not-valid-after).
Subject. Identifica al propietario de la llave pública del certificado.
CN=Java Duke (Common name), OU=Java Software Division
(Organization Unit), O=Sun Microsystems Inc (Organization), C=US
(Country).
subjectPublicKeyInfo. Se utiliza para indicar la llave pública que se
Actualmente, existen tres versiones de certificados X.509. La versión 1 (v1) ha estado disponible desde 1988, por lo que es ampliamente usada y más genérica. La versión 2 (v2) introdujo el concepto de identificadores únicos de sujeto (subjectUniqueIdentifier) y emisor (issuerUniqueIdentifier). Se utilizan para brindar la posibilidad de reutilizar los nombres del sujeto y/o el emisor, sin embargo, la mayoría de los documentos sobre certificación recomiendan que los nombres no sean reutilizados. Por esta razón, estos certificados son poco usados. La versión 3 (v3), ver Fig. 2.6, es la más reciente (1996) e incluye el campo extensions, que permite la adición de nueva información a la estructura del certificado, sin modificar su definición inicial. Una extensión está constituida por un identificador de extensión (extnId), una bandera de criticidad
(critical) y un valor específico para la extensión identificada (extnValue).
[image:42.612.163.473.484.659.2]Cuando una aplicación está procesando un certificado y no reconoce una extensión, si la bandera de criticidad es falsa, puede ignorar dicha extensión. Si la bandera de criticidad es verdadera, las extensiones no reconocidas harán que la estructura se considere no válida, es decir, una extensión crítica no reconocida provocará el fracaso de la validación de dicho certificado. Cuando la aplicación reconoce y es capaz de procesar una extensión, la procesará independientemente del valor de su bandera de criticidad.
2.6.1. Lista de certificados revocados
Todo certificado tiene una fecha límite de expiración, puede que se haya perdido o comprometido la llave privada correspondiente, cambio de algún atributo o el dueño del certificado deja de trabajar en el área. Al suceder cualquiera de los casos anteriores, los datos del certificado ya no son de confiar, se convierte en un certificado revocado, por lo que se requiere de un mecanismo para revisar el estado del certificado. Un mecanismo para esto es la Lista de Certificados Revocados [8], [10].
Los campos del estándar de certificado revocado son:
Version number. Indica la versión del certificado
Signature. Identifica el algoritmo y función de hash utilizados
por la AC para firmar el certificado revocado (por ejemplo, md5WithRSAEncryption, sha1WithRSAEncryption, etc.).
issuer. Identifica a la entidad que emite y firma el certificado
revocado, es decir, la AC.
ThisUpdate. Define la fecha y hora de cuando fue publicado
el certificado revocado.
NextUpdate. Define la fecha y hora para la siguiente lista de
revocación que será publicada adicionando los certificados revocados durante periodo comprendido de “ThisUpdate” a “NextUpdate”.
CRL Extensions. El campo de extensiones de CRL es usado
para dar información adicional a cerca de toda la CRL. Solo aparece en la versión 2.
Authority Key Identifier. Extensión no crítica y es usada para
CRL number. Esta extensión es esencialmente una secuencia de números contador.
Issuer Alternative Name. Lista de diferentes nombres que
pueden ser usados para identificar al emisor de la CRL. Si la extensión es marcada como critica, el campo del emisor contendrá un nombre nulo.
Reason Code. Identifica la razón por la cual se revoca el
certificado. Entre las razones se incluyen las siguientes:
o KeyCompromise. La llave privada que corresponde al
certificado se cree que ha sido comprometida.
o CACompromise. La llave privada de la AC se cree que ha
sido comprometida.
o AffiliationChanged. El nombre del sujeto u otra información
en el certificado ha cambiado.
o Superseded. El certificado ha sido sustituido por uno
nuevo. Esto no implica que la llave privada haya sido comprometida.
o CessationOfOperation. El certificado no será requerido
para el propósito que ha sido emitido.
o PrivilegeWithdrawn. Un privilegio que fue especificado con
un certificado ha sido retirado.
o RemoveFromCRL. Usado para indicar que un certificado
ha expirado.
o Invalidity Date. Corresponde a la fecha en la cual la llave
privada se considera fue comprometida.
Fig. 2.7 Certificado revocado de Internet Explorer
2.6.2. Verificación de certificados
Como ya se ha mencionado anteriormente los certificados deben pasar por pruebas que permitan garantizar su validez, para lo cual es necesario saber los caminos de validación a tomar a cualquiera de las AC de confianza, para lo cual se puede hacer hacia adelante, donde el camino se hace a partir de la entidad objetivo hasta la entidad de confianza base; hacia atrás, se usa cuando se construye el camino desde la entidad de confianza hasta la entidad objetivo.
información contenida en el documento.
Se cuenta con mecanismos como el OCSP de sus siglas en ingles Online Certificate Status Protocol, protocolo del estado del certificado en línea, el cual envía una solicitud a una entidad confiable llamada responder OCSP, la cual contiene la versión de OSCP, tipo de servicio, entre otros identificadores de certificados. Realiza un hash de los campos DN, llave pública del emisor y el número de serie del certificado, obteniendo así el estado de revocación firmada por el mismo. Los estados pueden ser “good”, significa que no ha sido revocado; “revoked”, significa que ha sido revocado y “unknown” lo cual significa que no se tiene información sobre el certificado requerido.
2.6.3. Directorios de certificados
Los certificados y las CRL, deben estar disponibles para los usuarios donde sea que se encuentren, por lo cual se recurre a la publicación, la cual consiste en colocar información en un lugar público y de fácil acceso, conocido como repositorio. Los repositorios son servicios con capacidad de almacenamiento de grandes volúmenes de información, parecidos a las bases de datos y se accede a ellos usando protocolos como puede ser LDAP (Lightweight
Directory Acces Protocol), estos están optimizados para tener un
CAPÍTULO III.
3.1. Componentes básicos
Una AC está constituida como software, hardware y el personal que emplea y manipula el equipo. Este trabajo se enfoca en la AC como software, es decir un sistema comprendido por subsistemas o módulos que realizan actividades de generación, revocación y renovación de certificados y la administración del sistema.
3.1.1. Generación de certificados
Para la generación de certificados digitales, es necesaria por parte del solicitante una forma de petición que comprenda sus datos particulares y su llave pública con una longitud de 1024 o 2048 bits. Estos datos serán validados contra la base de datos de la AC y se generará un certificado o se denegará. De acuerdo a las necesidades de la organización que este implementando el servicio de certificación, ésta determinará las características y requerimientos necesarios para aquellos que soliciten un certificado.
Cuando ya existe un certificado con la misma llave pública del solicitante.
Cuando ya existe un certificado del solicitante con el mismo motivo de expedición (firmar, autenticar, cifrar, etc.) en cualquiera de sus estados (fallo, inicializado, en proceso, generado).
Si después de las revisiones no recibe ninguna notificación negativa, se procederá a realizar el certificado digital de acuerdo al estándar X.509 V3. Este proceso llevará registros por actividad y evento ocurrido, indicando hora, fecha, solicitante, usuario de la AC y tipo de evento.
3.1.2. Revocación de certificados.
Cualquier certificado digital durante el periodo de validez, puede ser revocado y sea inválido para aquellos que lo quieran utilizar. Los casos por los cuales puede ser revocado son:
La llave privada ha sido comprometida. La AC ha sido comprometida.
La información del certificado debe cambiar. Sustitución por otro certificado nuevo.
3.1.3. Lista de certificados revocados (CRL)
La lista de certificados revocados, es generada por la AC cada periodo preestablecido de 20 min, 2, 6, 12 o 24 horas [7], esto es para llevar una mejor actualización constante de certificados. Los campos de la CRL ya fueron descritos en la sección 2.6.1.
La firma de la CRL realizada por la AC, van de acuerdo a los estándares de firma digital, haciendo uso de los algoritmos de firma DSS3, ECDSA3, RSA y como algoritmos hash SHA1 y SHA2. Esta función de la AC, debe ser registrada para su posterior auditoria, a lo que se debe indicar la hora, la fecha, lo que se firmó, quién o qué hizo que comenzará el proceso de firma.
3.1.4. Renovación de certificados
Después de haber revocado o caducado el certificado digital, la AC, debe permitir renovar el certificado digital por medio de la generación de uno nuevo. Por lo que es necesario que inicie el proceso de generación de certificados.
La renovación del certificado, debe ser realizada por el usuario final, el cual de acuerdo a sus necesidades realizará la renovación de su certificado.
3.1.5. Administración
La AC, debe ser capaz de llevar un control de sus actividades, entre ellas el generar, almacenar, proteger y actualizar su par de llaves, así como distribuir su llave pública. Las llaves generadas deben tener una longitud de 2048 bits, para el almacenamiento será con los estándares X.509 V3 y PKCS 124 para el par de llaves
pública y privada respectivamente5.
Ya por culminar el vencimiento de las llaves originales, es necesario crear un nuevo par que permitirán el buen funcionamiento de la AC. Para lograr esto sin problemas durante el proceso de transición, se requieren cuatro certificados firmados de la siguiente forma [10]:
1. “OldWithOld”, , este es el certificado actual de confianza
para los usuarios;
2. “NewWithOld”, , esto permite probar que las llaves nuevas y
previas son de confianza;
3. “NewWithNew”, , se convertirá en el nuevo certificado de
confianza después de la transición; y
4. “OldWithNew”, , este permite que durante el periodo de
transición hacia el nuevo par de llaves, se puedan manejar los certificados válidos generados con el nuevo par de llaves y con las anteriores sin ningún problema. Así las entidades que ya cambiaron y hacen uso de certificados firmados con la nueva
4
PKCS12 Estándar de sintaxis de intercambio de información personal. Define un formato de fichero usado comúnmente para almacenar claves privadas con su certificado de clave pública protegido mediante clave simétrica.
5
llave privada, continúen confiando y validando los certificados de la llave anterior.
Entre sus actividades de la administración también comprende la validación de formas de solicitud como la generación, revocación y renovación de certificados, actividad auxiliada por el personal que interactúa con el módulo administrativo.
Para la generación de certificados hay que validar la identidad de la persona que desea el certificado, lo cual se realiza de forma física, autenticando al solicitante a través de sus credenciales que presenta como un acta de nacimiento, credencial del IFE o CURP, además deberá entregar una forma de registro que sea congruente con la información suministrada por el solicitante y las credenciales, así mismo debe comprobar que en realidad él es quién posee la llave privada de la llave pública a certificar, esto se puede hacer mediante una prueba de posesión, es decir, se realiza un cifrado y descifrado con las llaves respectivas y si concuerda el mensaje en claro se da por aceptado. Si pasa cada validación se envía la forma y la llave pública al módulo de generación de certificados.
De forma similar, para la revocación de un certificado, hay que validar al solicitante de acuerdo a sus credenciales presentadas, entregar la forma que indique el motivo y características del certificado a revocar, una vez acreditada y validada la forma, se envía la solicitud al módulo de revocación de certificados.
la forma al área de generación de certificados para su proceso.
3.1.6. Repositorio de certificados y CRL
Para mantener un control y administración correctos, es indispensable conocer el total de certificados emitidos o revocados, para lo cual se utilizan los repositorios para el almacenamiento público de certificados y listas de revocación de certificados. Algunas implementaciones de estos repositorios se realizan mediante el protocolo ligero de acceso a directorios (LDAP6 - Lightweight
Directory Acces Protocol).
LDAP es un protocolo cliente – servidor, útil para acceder a un conjunto de datos almacenados y se ven como un servicio de directorio, servicio el cual contiene información descriptiva y organizada por atributos. Estos directorios proporcionan una respuesta rápida a operaciones de búsqueda y consulta para concentraciones masivas de lectura y no para transacciones de actualización y generación de registros como con los gestores de bases de datos.
La estructura del directorio o árbol de información de directorio (DIT - Directory Information Tree) está basada en entradas, las cuales tienen nombres con uno o más atributos que comprenden un nombre distintivo DN único, entre sus atributos se pueden contemplar el nombre común (cn) o dirección de correo (mail).
6
También maneja esquemas que se conforman de una colección de tipos de atributos los cuales se usan para ubicar atributos de entrada. Los atributos que debe contener, de acuerdo al estándar,
son cn, objetcClass, objectClassesy atributeTypes, también hay
atributos (creatorsName, createTimeStamps, modifiersName,
ModifyTimeStamp y subschemaSubentry) que son de uso exclusivo
del servidor.
El protocolo de intercambio es descrito usando notación ASN.1, en el cual se describe el mensaje LDAP, donde tiene solicitudes de búsqueda, modificación, peticiones o respuestas extendidas; los resultados LDAP donde indica el suceso, los errores, las comparaciones falsas o verdaderas, si soporta autenticación, si son validos las extensiones, si hubo violaciones de las restricciones. En el caso de una búsqueda se indica la base, el nivel, subárbol, los alias, limite en tiempo y espacio, filtro y atributos.
[image:54.612.210.497.466.650.2]A continuación se presenta la Fig. 3.1 con un ejemplo de un DIT.
Fig. 3.1 Información del DIT dn: cn=John Doe, dc=example, dc=com cn: John Doe
givenName: John sn: Doe
telephoneNumber: +1 888 555 6789 telephoneNumber: +1 888 555 1232 mail: john@example.com
manager: cn=Barbara Doe, dc=example, dc=com objectClass: inetOrgPerson
objectClass: organizationalPerson objectClass: person
3.2. 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].
[image:55.612.114.486.404.582.2]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].
(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.
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.
[image:57.612.135.502.470.659.2]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.
[image:58.612.139.538.434.645.2]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 (ACAC1AC2A), 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.
Fig. 3.5 Certificación cruzada entre los modelos jerárquico y de red.
3.3. Establecimiento de las identidades
El establecimiento de las identidades en el contexto de las AC se da en dos aspectos, el primero cuando se verifican las identidades de aquellos quienes desean un certificado digital de la AC en cuestión y la otra se da cuando se convive en un modelo de confianza para varias AC.
Fig. 3.6 Cadena de identificador de llave
De acuerdo al X.509, AKID puede ser representado usando el identificador de llave, el certificado de autoridad emisora, el número de serie o ambos. El identificador de llave puede ser usado para la construcción de rutas de certificación, y los demás campos solo para dar una preferencia sobre otros en la construcción.
Existen varios métodos para calcular el identificador de llave, un primer método toma 20 bytes de hash (SHA-1) de la llave pública, otro usa 4 bits con valor 0100 seguidos por los 60 bits menos importantes de la llave pública y uno más emplea 4 bits 0100 seguidos por 60 bits menos significantes del hash (SHA-1) de la llave pública.
3.4. Servicios
electrónico, es necesario verificar que el certificado digital que éste emite es válido, para lo cual es necesario accesar el servicio de publicación de certificados y ver que el certificado que se busca no se encuentre revocado. Si estos servicios no están activos, es inconveniente ser parte de esta AC.
Para mantener su reputación ante sus usuarios, la AC debe ser capaz de auditar al personal, procedimientos y operaciones que ésta desempeña. Esto mediante un registro continuo y asociado a los certificados para cualquier verificación posterior, de tal forma que cualquier solicitud o respuesta a la AC se firmen y a la vez sea registrado y estar en condiciones de comprobar las acciones realizadas en caso que se requiera. Si se llega a tener un incidente de seguridad o hay una duda sobre el desempeño del administrador, puede ser cotejado con los registros.
Para tener consistencia y la capacidad de auditar, la AC debe mantener un registro auditable de la revocación de certificados, y proveer información del estado de revocación.
Las categorías a auditar son los movimientos en la base de datos, el respaldo y restablecimiento de la base de datos de la AC, el cambio de configuraciones de la AC, la administración de peticiones de certificados, la revocación de certificados y publicación de la CRL. Así como el comienzo y detención de los servicios de la AC. Estas actividades son realizadas exclusivamente por el usuario con el rol de auditor, a excepción de los movimientos en la base de datos.
3.5. Certificados
3.5.1. Tipos
El certificado digital es la figura con lo que se hace toda una infraestructura que permita su empleo de forma segura. Sin embargo se tiene varios tipos de certificados de acuerdo al tipo de entidad final que requiera uno de estos.
Como primer tipo se tiene el certificado individual, es aquel donde se certifica la llave pública de una persona con el fin de usarse en transacciones electrónicas, de tal forma que pueda autenticarse y firmar datos que así lo requieran.
También se emiten certificados para equipos de comunicación, tales como routers, firewalls, switchs. Estos equipos usaran los certificados para autenticarse entre ellos y para la generación de redes virtuales.
Por último, se tienen los certificados de servicios cliente servidor, en donde el usuario que solicita el servicio o acceso a una página web, antes de comenzar a realizar alguna transacción, tiene que estar seguro que realmente es el servicio de la empresa que desea y no lo están suplantando.
3.5.2. Solicitud
De acuerdo a los tipos de certificado se tienen diferentes formas de solicitud por cada uno.
Para la solicitud de un certificado individual, es importante incluir el nombre, un identificador único como la CURP, organización a la que pertenece, domicilio, teléfono, propósito del certificado y correo electrónico.
Para la solicitud de un certificado de equipo, hay que incluir el nombre de equipo, el número de serie como identificador, dirección IP y ubicación física.
Para la solicitud de los servicios, hay que indicar el nombre de servicio, URL y organización a la que pertenece el servicio.
3.5.3. Modelos para la administración
La administración va relacionada al modelo de confianza que se esté empleando, debido a la cantidad de información que se maneja. Es por ello que si se tiene un modelo de confianza de una sola AC, todos los movimientos de almacenamiento, generación, revocación y renovación de certificados; almacenamiento de las llaves públicas, control de usuarios y el manejo de registros deben ser realizados con precisión lo que lo hace complicado.
3.5.4. Validación
El certificado por sí mismo es un instrumento de confiabilidad, sin embargo es necesario verificar que es válido y no esta revocado para creer en él.
Entre las validaciones que se deben realizar se encuentran: La verificación de la firma del certificado a través del
certificado público de la AC que lo emitió,
También hay que verificar que la ruta de certificación es correcta y las AC intermedias como la AC ancla son de confiar
Así mismo se verifica que el certificado se encuentre dentro del periodo de uso válido y lo más importante que éste no haya sido revocado, usando para ello la CRL emitida buscando que no se encuentre el certificado en cuestión en la lista.
Debido a que la CRL se actualiza cada cierto periodo de tiempo de acuerdo a las políticas, es posible no encontrar certificados que se encuentren revocados, por lo cual también hay mecanismos como el protocolo de revisión del estado actual del certificado (Online Status Certificate
Protocol - OSCP7), entre otros.
7
Para mayor detalle revise RFC 2560, “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol
CAPÍTULO IV.
4.1. Requisitos
La Autoridad Certificadora, como ya se ha mencionado es un sistema
que relaciona al hardware, software y personal operativo.
Las operaciones criptográficas que desempeña una AC demandan
recursos de procesamiento, almacenamiento y memoria superior a la de una
PC normal, esto indica que el software de la AC debe convivir con un equipo
que tenga características de servidor. En cuanto al almacenamiento hay que
tomar en cuenta la cantidad de certificados que pueden ser generados tanto
de forma inmediata a la implementación de la AC como al paso del tiempo de
10 años aproximadamente.
Para el sistema operativo (S.O.) sobre el cual el software será
instalado, se debe tomar en cuenta tanto el conocimiento en la administración
del S.O., como la compatibilidad del software con que se desarrolló la AC, de
esta forma se evitarán conflictos de instalación y mantenimiento.
También se debe incluir la seguridad física para aquellos componentes
que requieren protección física y minimizar accesos mal intencionados para
modificar o destruir el hardware de operación, tomando en cuenta el control de
acceso mediante dispositivos de autenticación a la red, usar cintas magnéticas
o discos compactos de respaldo, y cualquier otra actividad que se considere
necesaria para mantener seguros los datos almacenados o transmitidos en la
![Fig. 3.2 Modelos de confianza [10].](https://thumb-us.123doks.com/thumbv2/123dok_es/4951311.74769/55.612.114.486.404.582/fig-modelos-de-confianza.webp)
