Rubén Martínez
Introducción
Nunca ha habido tal proliferación de técnicas y herramientas para
mejorar la seguridad de los sistemas informáticos. Algunas de estas
técnicas son dignas de los entornos militares por su
sofisticación y fiabilidad, y muchas de ellas son baratas o gratuitas.
Sin embargo, están fuera del alcance de la mayor parte de los usuarios,
debido a su complejidad, a la necesidad de infraestructuras de
coordinación, o a ambas cosas.
Y sin embargo, la problemática inherente a la mayor parte de los
servicios de seguridad es común; tanto que sería posible unificar
muchos de estos servicios en una estructura global que facilitara su uso
enormemente. Por ejemplo, las estadísticas indican que los servicios
más utilizados son WWW y correo electrónico. Ambos servicios
implican la transmisión de información entre dos interlocutores
no autentificados, sobre un canal inseguro. Los problemas son los mismos:
suplantación, espionaje. Las soluciones, como veremos, también.
Estas soluciones dependen en general de lo que se conoce como procedimientos de
cifrado asimétrico. Hay muchas variedades de cifrado asimétrico,
y no vamos a entrar en detalles, pero todas tienen algo en común: la
necesidad de una infraestructura sólida de certificación de
claves.
En las pasadas Jornadas Técnicas de 1996 planteamos por primera vez la
necesidad de crear una estructura de certificación para RedIRIS que
sirviera eventualmente de base para todos los demás servicios de
seguridad, y a ser posible, con intervención mínima por parte de
los usuarios.
Este documento es la propuesta inicial del servicio de certificación, a
desarrollar por el grupo de trabajo IRIS-PCA.
1.- Servicios básicos de seguridad
1.1.- Control de acceso
Cualquier sistema informático consta, al fin y al cabo, de una serie de
recursos (memoria, ficheros, etc.) y una serie de usuarios de los mismos
(personas, programas, otras máquinas). Algunos recursos serán
públicos (pueden ser disfrutados por todo el mundo), otros privados
(sólo pueden ser utilizados por un usuario o grupo de usuarios
específicos). Los mecanismos de control de acceso regulan qué
usuarios pueden acceder a cada recurso, y de qué forma (examinar,
modificar, crear, eliminar).
1.2.- Autentificación
El sistema debe tener alguna forma de identificar a los usuarios: no se puede
concebir control de acceso sin autentificación. La
autentificación es el proceso mediante el que una entidad garantiza su
identidad frente a otra. Por ejemplo, un usuario de un sistema Unix se
identifica normalmente introduciendo una contraseña que se supone nadie
más conoce (autentificación basada en el conocimiento). Este es
uno de tres tipos básicos de autentificación:
- Basada en el conocimiento (como en el ejemplo de la contraseña). Tiene
el inconveniente de que el conocimiento puede olvidarse, o ser asimilado por
otros.
- Basada en una posesión (por ejemplo, la llave del portal nos
autentifica ante la puerta). Los inconvenientes son similares: la llave puede
perderse o ser robada.
- Basada en la propia identidad (por ejemplo, un reconocedor de voz, o un
detector de la huella dactilar). Tiene el inconveniente de que es muy caro, y
puede resultar poco práctico: una afonía puede enmascarar la voz,
o una herida destruir la huella.
Por supuesto, nada impide combinar varios métodos. Una tarjeta de
crédito es una posesión que implica un conocimiento (el
número personal). El DNI es una posesión que implica tres
métodos de autentificación basados en la propia identidad: la
firma, la foto y la huella.
1.3.- Confidencialidad
No siempre es viable el control de acceso. Por ejemplo, si queremos restringir
el acceso a un determinado mensaje de manera que sólo su destinatario
pueda leerlo, y el destinatario está en otra máquina. No tenemos
capacidad de control sobre las redes y máquinas intermedias por las que
pasará el mensaje, aun en el caso ideal de que tuviéramos control
total sobre la nuestra. El servicio de confidencialidad nos permite codificar
ese mensaje de forma que nadie más pueda leerlo, entre otras cosas.
Normalmente, esto implica usar una clave, que sólo deben conocer
determinadas personas, por lo que de nuevo es imprescindible la
autentificación. Se llama autentificación de origen a identificar
al remitente frente al destinatario, y autentificación de destino al
proceso inverso.
1.4.- No repudio
Se pueden llevar un poco más lejos los procedimientos de
autentificación de origen y destino para implementar los servicios de no
repudio en origen y entrega, respectivamente. El primero nos garantiza que el
remitente del mensaje no podrá negar que lo ha enviado. El segundo, de
difícil realización práctica, nos garantiza que el
destinatario no podrá negar haberlo recibido, de haber sido
así.
1.5.- Integridad
Por último y siguiendo con el ejemplo del mensaje, es igualmente
importante que no pueda ser alterado o al menos que cualquier alteración
del mismo sea inmediatamente reconocible como tal. Esto es el servicio de
integridad y las técnicas que lo hacen posible se utilizan normalmente
combinadas con la autentificación de origen para crear lo que se conoce
como una firma digital. Una firma digital garantiza que el remitente no ha sido
suplantado y el mensaje no ha sido modificado. Normalmente también lleva
lo que se conoce como un `sello de tiempo', que sirve como garantía de
que el mensaje se envió en una fecha y hora determinadas.
Se podría seguir, pero estos son los servicios básicos que
esperamos en un proceso seguro de comunicación, y es interesante
destacar que del servicio de autentificación dependen en gran medida los
demás. Un sistema que asigne a cada usuario una prueba de identidad
incuestionable, a ser posible sin tener que introducir varias
contraseñas para cada actividad, es el primer paso hacia una red
segura.
2.- Conceptos de criptografía
En realidad, casi todos los servicios de seguridad dependen directa o
indirectamente de alguna técnica criptográfica, y para
utilizarlos correctamente es útil tener un conocimiento de los conceptos
esenciales. Voy a intentar explicarlos con brevedad, prescindiendo
deliberadamente del modo de funcionamiento de algoritmos concretos (aunque los
conocedores de RSA reconocerán la forma típica de
utilización de este algoritmo en particular). Quienes estén
familiarizados con estos temas tal vez prefieran avanzar al siguiente
apartado.
Asumiré que todo el mundo entiende conceptos tales como mensaje en claro
(original), mensaje cifrado, y clave. De no ser así, la
bibliografía incluye algunas referencias útiles.
Utilizaré el término `mensaje' por claridad, pero en principio,
cualquier cosa puede ser (des)cifrada: programas, páginas WWW, etc. En
el caso de una consulta WWW, por ejemplo, hay dos fases: una petición
del cliente al servidor, y una respuesta del servidor al cliente. Podemos verlo
como el intercambio de dos mensajes, y se denomina `transacción' a la
operación completa.
Una clasificación muy superficial de las distintas técnicas
criptográficas nos da cuatro grandes grupos (La tabla 1 muestra una
clasificación más rigurosa).
TABLA DE REFERENCIA DE TÉCNICAS CRIPTOGRÁFICAS (FUENTE: RSA LABORATORIES) |
Cifrado asimétrico y/o firmas digitales
Basado en factorización
RSA
Protocolo de firmado Rabin**
Basado en logaritmos discretos
Diffie-Hellman*
STS (DH con acuerdo de claves
autentificado)
ElGamal
DSA (DSS)**
Otros
Basados en curvas elípticas
Variantes de RSA
Variantes de ElGamal
Basados en el problema de la mochila
Merkle-Hellman (obsoleto)
Chor-Rivest
Basados en secuencias de Lucas
Variantes de RSA (LUCRSA)
Variantes de Diffie-Hellman (LUCDIF*)
Variantes de ElGamal (LUCELG)
Basados en la teoría de codificación
McEliece
Basados en esquemas de firma en árbol
Merkle**
* No soporta firmas digitales
** Sólo soporta firmas digitales
Cifrado simétrico por bloques (block cipher)
Iterativos con cifrado equivalente a descifrado
Códigos Feistel
DEA (DES)
Triple DES y variantes
G-DES
DESX
Blowfish
RC2
RC5
IDEA
FEAL y variantes (obsoletos)
Otros
SAFER
No publicados
Skipjack
Cifrado simétrico continuo (stream cipher)
Basados en `one time pad' (clave no reusable no más
corta que el mensaje a cifrar).
Vernam*
Simplificaciones genéricas de la técnica de`one-time-pad'.
RC4
SEAL
Basados en registros de desplazamiento de realimentación lineal.
Algoritmos de reducción y autoreducción.
* Se considera el único método perfecto, pero no resulta
práctico para uso cotidiano.
|
Funciones unidireccionales (hash) de uso
criptográfico
Basadas en cifrado simétrico por bloques
Havies-Meyer (basada en DES)
Basadas en aritmética modular
(Ninguna aceptable actualmente)
Dedicadas
MD2
MD4 (obsoleto)
MD5
SHA (obsoleto)
SHA1
RIPE-MD
Haval
Otros
Variantes especiales de firma digital
Firma a ciegas
Firmas con verificador designado
Firmas de grupo
Firmas no reusables
Firmas sin propagación de fallo
Firmas no repudiables
Sello de tiempo
Códigos de autentificación de mensajes (MACs)
Basados en `one time pad'.
Basados en otros criptosistemas
simétricos continuos.
Basados en criptosistemas simétricos de
bloques en modo CBC.
Basados en `hash' criptográfico.
Esquemas de secreto compartido
Basados en interpolación polinómica (Shamir)
Basados en intersección de hiperplanos (Blakey)
Visuales (Naor/Shamir)
Pruebas interactivas de conocimiento nulo.
Fiat-Shamir
Feige-Fiat-Shamir
Guillou-Quisquater
Criptografía cuántica
GLOSARIO DE ACRÓNIMOS
Algoritmos
DEA = Data Encryption Algorithm
DES = Data Encryption Standard (describe DEA)
DH = Diffie/Hellman
DSA = Digital Signature Algorithm
DSS = Digital Signature Standard (describe DSA)
FEAL = Fast data Encipherment Algorithm
IDEA = International Data Encryption Algorithm
MAC = Message Authentication Code
MD2/4/5 = Message Digest (también RIPE-MD)
RC2/4/5 = Rivest's Cipher o Ron's Code (por Ron Rivest)
RSA = Rivest/Shamir/Adleman
SAFER = Secure And Fast Encryption Routine
SEAL = Software optimized Encryption Algorithm
SHA = Secure Hash Algorithm
STS = Session-to-Session
Modos de cifrado por bloques
CBC Cipher Block Chaining
CFB Cipher Feedback
ECB Electronic Code Book
OFB Output Feedback
PCBC Propagating Cipher Block Chaining
|
2.1.- Comunicación confidencial con un criptosistema simétrico
- El emisor utiliza una clave para cifrar el mensaje.
- El receptor utiliza la misma clave para descifrarlo.
- La seguridad del sistema depende de que nadie más conozca la clave.
Esto tiene el problema de que hay que transmitirla al receptor en algún
momento, y que puede ser interceptada.
- Los criptosistemas simétricos se conocen también como sistemas
`de clave secreta' o `convencionales'.
2.2.- Comunicación confidencial con un criptosistema asimétrico
- Emisor y receptor tienen cada uno una pareja de claves. Una es privada y debe
ser mantenida en secreto. La otra es pública y se distribuye a todos los
posibles destinatarios.
- Lo que cifra una clave privada sólo puede ser descifrado con la clave
pública correspondiente, y viceversa.
- La clave privada no puede deducirse de la pública, por lo que no hay
peligro en transmitir las claves públicas por la red.
- El emisor cifra con la clave pública del receptor.
- El receptor descifra con su clave privada.
- Los sistemas asimétricos se conocen también como sistemas `de
clave pública'.
2.3.- Funciones criptográficas de un solo sentido
- Es un cifrado unidireccional e irreversible: lo que se cifra de esta manera
no puede ser descifrado.
- No hace falta una clave. El mensaje cifrado depende exclusivamente del
original.
- El mensaje cifrado es normalmente de longitud fija y mucho más corto
que cualquier mensaje típico.
- Se trata de una función libre de colisiones en sentido estricto (es
muy difícil encontrar un par de mensajes cuyo cifrado sea
equivalente).
- Cualquier alteración del mensaje original, por pequeña que sea,
genera un mensaje cifrado completamente distinto.
2.4.- Generación de números aleatorios uniformes
- Una secuencia de números es aleatoria si es imposible predecir el
siguiente número basándose en los anteriores.
- Es además uniforme si todos los números pueden aparecer con
idéntica probabilidad.
- Diversas técnicas criptográficas requieren de números
aleatorios en algún punto del proceso. Si son previsibles de alguna
forma el, sistema no será seguro. Si no son uniformes, se puede utilizar
un estudio estadístico para atacar el sistema.
- Existen algoritmos criptográficos dedicados exclusivamente a obtener
números que sean realmente aleatorios y uniformes.
Un proceso de comunicación segura participa usualmente de los cuatro
tipos de técnicas, como se verá a continuación.
3.- Comunicación segura como síntesis de técnicas
criptográficas
Vamos a definir arbitrariamente un proceso de comunicación segura entre
un emisor y un receptor como aquel que reúne las siguientes
características: autentificación, confidencialidad, integridad y
no repudio de origen.
El cifrado asimétrico resuelve el problema de poder mantener una
comunicación confidencial, sin el riesgo asociado de que las claves sean
interceptadas por un tercero: cada emisor sólo necesita saber las claves
públicas de los receptores, y sólo el poseedor de la clave
privada adecuada podrá descifrar el mensaje (con lo que el receptor
está autentificado implícitamente).
El cifrado asimétrico también puede utilizarse para autentificar
al emisor. Si éste cifra un mensaje con su clave privada, no lo
está protegiendo (cualquiera que tenga su clave pública puede
descifrarlo), pero sí que está garantizando su identidad, ya que
nadie más tiene su clave privada. Por supuesto, nada impide combinar
este procedimiento con el anterior, para tener un mensaje autentificado y
protegido a la vez.
A veces es interesante enviar mensajes autentificados para aquellos que puedan
verificarlos (los poseedores de la clave pública del emisor), pero de
forma que quienes no dispongan de dicha clave tengan al menos la oportunidad de
ver el texto, aunque no puedan verificar su autenticidad. Esto tiene el riesgo
de que es susceptible de una alteración del contenido del mensaje, ya
que no está cifrado. La solución es que el emisor no cifre todo
el mensaje con su clave privada, sino sólo un `hash' del mismo, obtenido
mediante una función criptográfica unidireccional, y añada
este resultado (denominado `firma digital') después del mensaje en
claro.
De esta forma, todo el mundo puede leerlo, y quienes lo deseen pueden
además verificar la identidad del emisor y asegurarse de que el mensaje
no ha sido alterado (extrayendo otro `hash' del mismo y comprobando que
coincide con la firma digital descifrada).
Un inconveniente de los sistemas asimétricos es cuando el mismo mensaje
tiene muchos receptores. Por ejemplo: un mensaje de correo dirigido a una
lista. Habría que cifrar una vez para cada uno de los destinatarios, con
cada una de sus respectivas claves públicas, y resultaría un
mensaje demasiado grande (por no hablar de la lentitud del proceso ya que los
algoritmos asimétricos son mucho más lentos que los
simétricos en general).
Como solución podemos recurrir a la criptografía convencional. El
único problema que ésta tiene es la transmisión de claves
por medios inseguros; pero podemos usar criptografía asimétrica
para cifrar sólo la clave, en vez del mensaje completo. Lo que se
distribuye en este caso es un solo mensaje, cifrado con una clave convencional
(denominada clave de sesión), junto con el resultado de cifrar esta
clave (normalmente mucho más corta que el mensaje) para cada uno de los
receptores.
Si se usara siempre la misma clave de sesión, aumentaría la
probabilidad de que alguien la descifrara. Como va codificada en el mensaje no
hace falta que los receptores la aprendan, por lo que el emisor puede generar
una clave de sesión al azar para cada transmisión.
La figura 2 muestra un ejemplo en el que intervienen todas estas
técnicas. No tiene por qué ser exactamente así, aunque es
lo más común. Los algoritmos exactos empleados en cada punto
pueden variar. Una transacción segura implica normalmente un proceso de
`negociación' entre el cliente y el servidor para elegir los algoritmos
a utilizar. Cada uno expone una lista de algoritmos admisibles en orden de
preferencia, y se usa el primero que esté presente en ambas listas. La
negociación determinará un algoritmo simétrico (DES, TDES,
IDEA, RC2, RC4, etc.) para el cifrado de la transacción, otro
asimétrico (normalmente RSA, posiblemente DH) para el intercambio de
claves y autentificación, y otro unidireccional (MD4, MD5, SHA) para la
creación de firmas digitales.
4.- El problema de la certificación
Al describir los sistemas de criptografía asimétrica, he omitido
deliberadamente su mayor debilidad: las autentificación de las claves
públicas.
Analicemos la figura 2. Las claves privadas no se transmiten nunca. La clave de
sesión se transmite una sola vez cifrada. Pero las claves
públicas, por definición, están a disposición de
todo el mundo. No hay riesgo alguno en distribuir una clave pública, ya
que no revela nada sobre la privada; pero otra cosa es aceptar como
válida cualquier clave pública que encontremos en la red.
Si A quiere mandar un mensaje firmado y protegido a B, A firma el mensaje con
su clave privada, y lo cifra con la clave pública de B. A sabe que
sólo B puede descifrar ese mensaje, y B sabe que sólo A ha podido
mandarlo. Eso es cierto, si la clave pública de B en posesión de
A es la auténtica, y viceversa.
Supongamos que C hace pública una clave que en apariencia pertenece a A,
y B la acepta como válida. Eso significa que C puede suplantar a A
mandando a B mensajes aparentemente firmados por A. Además, C
podrá descifrar cualquier mensaje que B dirija a A cifrado con esta
clave.
Esto es en el fondo un problema de autentificación, similar al de
garantizar la identidad de los usuarios. En este caso se trata de garantizar la
identidad de las claves públicas, o más propiamente, asociar
éstas a usuarios. Podemos resolver este problema usando las mismas
técnicas que para autentificar usuarios: criptografía
asimétrica y firma digital, aplicadas a las claves públicas y a
una descripción del usuario, en vez de a los mensajes. Esto se llama
certificar las claves.
Pero no hacemos más que atrasar el problema. Podemos asumir que una
clave pública es válida si está certificada por alguien de
confianza. Pero ¿cómo sabemos que es alguien `de
confianza', y no está siendo suplantado a su vez? Porque su clave
está certificada por otra clave `de confianza', y ésta por otra,
etc. Evidentemente esto no se puede llevar hasta el infinito, pero podemos
asumir un límite razonable.
Existen bastantes polémicas de tipo ético sobre quién o
quienes debe tener la capacidad para certificar en nombre de otros. Sistemas
como PGP dejan esta elección en manos del usuario, lo que es perfecto ya
que el hecho de confiar o no en un `certificador' es por definición
subjetivo. Pero no siempre se puede aplicar esto por dos motivos:
- la complejidad de estos sistemas no está al alcance de todo el mundo,
y se requiere un procedimiento de verificación de identidad muy estricto
que el usuario debe poner en práctica por sus propios medios.
- no se adapta bien a entornos como WWW donde es deseable que el usuario pueda
beneficiarse de la comunicación segura de forma transparente y sin tener
que tomar ninguna decisión por su parte, incluso si esto implica un
nivel de seguridad ligeramente menor.
La alternativa es definir una jerarquía estricta de `autoridades de
certificación' (CA, Certifying Authority), que crearán
certificados para otras entidades ante la presentación de suficientes
pruebas de identidad. La credibilidad de una CA depende completamente de su
rigor a la hora de no aceptar datos dudosos, y ésta es la mejor
garantía de fiabilidad para sus usuarios. Normalmente la CA hará
públicas sus políticas de actuación en temas tales como:
- Qué tipo de certificados se emiten.
- Quiénes pueden recibir un certificado.
- Qué prueba de identidad se considera aceptable.
- Qué medidas de seguridad protegen los datos de los usuarios.
- Qué procedimientos garantizan que estas normas se cumplen.
- Cuál es la responsabilidad de la CA en caso de no ser así.
- Etcétera
Una CA no suele operar de forma aislada, sino que pertenece a una comunidad
homogénea en cuanto a sus necesidades de certificación, y en la
que existen varias CAs, típicamente organizadas en árbol. En la
raíz del árbol reside una PCA (Policy Certifying Authority). La
PCA sólo certifica a otras CAs, no a entidades finales, y define la
`política de certificación' para todas las CAs de la comunidad.
Todas las PCAs son a su vez certificadas por una PCA superior (por ejemplo, una
PCA de RedIRIS podría estar certificada por una PCA de todas las redes
de investigación europeas), y en última instancia, por una
entidad supranacional (IPRA, Internet PCA Registration Authority) dependiente
de la Internet Society.
El interés despertado por los medios de pago electrónico en
Internet ha hecho proliferar las PCAs de tipo comercial, la más conocida
de las cuales es Verisign. Estas compañías venden certificados de
distinto tipo y fueron las primeras autoridades de certificación.
La actividad de una CA se reduce básicamente a tres tareas:
- Por un lado tiene una actividad de registro de identidad (contactar con el
solicitante, analizar las pruebas, dar de alta una identidad válida).
- Por otro lado, tiene la actividad de certificación propiamente dicha.
Una vez que una entidad ha sido certificada, será automáticamente
reconocida por todas las demás entidades compatibles con esta CA; por
ejemplo, si es una persona, podrá utilizar aplicaciones de
comunicaciones seguras de forma transparente con otras personas igualmente
certificadas.
- Por último, la CA emite periódicamente listas de certificados
revocados (CRL). Un certificado puede ser revocado por varias causas: la
información en el mismo ya no es válida, la clave privada
asociada al mismo se ha perdido, o simplemente ha caducado su período de
validez.
En algunos casos la CA delega la actividad de registro en otras entidades
menores, por razones de ubicación o de reparto de trabajo. Estas
entidades (RA, Registry Authority) están certificadas por la CA, y su
misión es llevar a cabo el registro de identidades de los solicitantes y
enviar esta información a la CA por medios seguros.
La certificación es un aspecto esencial de cualquier proceso de
comunicaciones seguras, ya que de una buena estructura de certificación
depende la validez de las claves empleadas para autentificar y cifrar las
transacciones.
5.- Propuesta de certificación para RedIRIS
La comunidad RedIRIS responde a la definición de `comunidad con
necesidades homogéneas de certificación' y podría
beneficiarse de una estructura jerárquica como la que se ha expuesto
más arriba. La actual topología y organización de la red
se adapta bien a una estructura centralizada en el Centro de Comunicaciones
CSIC RedIRIS, que gestionaría la PCA (IRIS-PCA) y certificaría
CAs locales.
Para participar en el sistema, una persona debe estar certificada por su CA
más próxima. No es un requisito que todos los centros operen una
CA completa, con todo lo que ello conlleva, pero sí es deseable que
dispongan de una RA al menos. RedIRIS contemplará la posibilidad de
establecer una CA de último recurso para atender usuarios finales con
necesidades específicas, procedentes de comunidades sin recursos de
certificación. Esto requerirá un procedimiento de
excepción y será inevitablemente más lento que el
trámite a través de una CA local.
La primera fase de este proyecto será abordada por el grupo de trabajo
IRIS-PCA, y tiene como objetivo la puesta en marcha de una serie de CAs piloto
(centro, sur, nordeste y noroeste). Pero antes de que esto sea posible es
necesario tomar una serie de decisiones que afectarán al desarrollo
posterior del proyecto. La mayor parte de estos temas están abiertos, y
pueden cambiar aún durante la marcha:
5.1.- Tipo de certificados:
El proceso de certificación usa un mecanismo de cifrado
asimétrico (normalmente algoritmo RSA), combinado con una función
unidireccional para crear firmas digitales (normalmente MD5 o SHA1).
Ambos se aplican a una identidad, que es la que hay que asociar al certificado,
y que debe estar descrita en un determinado formato. Esta descripción
debe de ser:
- Única e intransferible.
- Tener estructura jerárquica. Por ejemplo:
nombre/puesto/organización/país. Esto facilita la unicidad de los
certificados así como la asignaciónde usuarios o CAs.
- Poder incorporar información complementaria como:
- Identidad de la CA que lo ha originado
- Fecha de emisión
- Plazo de validez
El formato más universal con estos requisitos es X.509v3. Los
componentes de un certificado en formato X.509v3 se detallan en la figura 4. En
particular, la definición del nombre es mediante `nombres distinguidos'
X.500, lo que facilita el uso del directorio como medio de difusión de
claves, sin perjuicio de que se puedan usar otros medios como correo o WWW
simultáneamente.
EN TODAS LAS VERSIONES |
Versión | Deben coexistir certificados recientes (versión 3) con otros más antiguos basados en las versiones 1 y 2, por lo que es imprescindible identificarlos. |
Número de serie | En presencia de dos certificados distintos pero asociados a la misma identidad, y sin confirmación de
revocación para ninguno, se puede identificar el más reciente
gracias al número de serie y revocar `de oficio' el anterior. |
Algoritmo de firma | Identificación del algoritmo de firma digital
utilizado. Es necesario saberlo para poder verificar el certificado
posteriormente usando el mismo algoritmo. |
Nombre del emisor | Nombre de la CA que ha emitido el certificado. |
Período de validez | Intervalo de fechas durante las que el certificado es válido. Nótese que este campo por sí mismo no basta para determinar el más reciente de dos certificados, ya que el período de validez del primero puede estar completamente incluido en el del
segundo. |
Nombre del usuario | Nombre del usuario para el que se emite el certificado. |
Clave pública del usuario receptor | Información de la clave pública del usuario para el que se emite el certificado(nombre, algoritmo, etc.). |
Firma | Una firma digital que garantice la integridad de todos los campos del certificado. |
* A PARTIR DE LA VERSIÓN 2: |
Identificador único del emisor | En el caso de colisión entre nombres de dos
CAs distintas, para diferenciarlas hacen falta identificadores generados de forma que garantice su unicidad. |
Identificador único del usuario | Idem, con respecto a la identidad del usuario. |
* A PARTIR DE LA VERSIÓN 3: |
Extensiones | Otros campos específicos de cada protocolo (SHTTP, PKCS, etc.), sujetos a sus propias regulaciones. |
El formato X.509 es válido tanto en enfoques basados en la seguridad a
nivel del interfaz de transporte (como SSL, usado frecuentemente en WWW), como
a nivel de aplicación (S-HTTP, S/MIME, etc.) y la práctica
totalidad de la especificación OSI, de la que proviene.
5.2.- Protocolos de certificación
Una vez decidido el formato de los certificados, hay que definir procedimientos
para todas las tareas de la CA. Por ejemplo: qué formato tiene una
petición de certificado, cómo se envía la respuesta,
qué datos van en una CRL, etc. Una comunidad de certificación
aislada puede decidir todo esto arbitrariamente, pero lo normal es usar un
estándar que asegure la interoperabilidad con otras CAs externas.
Uno de los más extendidos es el conjunto de especificaciones PKCS
(Public Key CryptoSystem), de RSA. Son las siguientes:
PKCS#1 define mecanismos de cifrado asimétrico y firma digital mediante
el algoritmo RSA.
PKCS#3 define mecanismos de intercambio de clave mediante el algoritmo
Diffie-Hellman.
PKCS#5 explica cómo cifrar un texto mediante una clave secreta obtenida
de una contraseña.
PKCS#6 define el formato de los certificados; está basado en una
versión ya obsoleta de X.509 más extensiones propias.
PKCS#7 define una sintaxis genérica para mensajes que incluyan mejoras
criptográficas, tales como firma digital y/o cifrado.
PKCS#8 define el formato de las claves privadas.
PKCS#9 define diversos tipos de atributos, que son usados en toda la serie
PKCS.
PKCS#10 define la sintaxis de una petición de certificado.
PKCS#11 define un interfaz de programación independiente de la
tecnología de base, para utilizar tarjetas inteligentes como medio
de autentificación.
IRIS-PCA debería soportar X.509v3 de forma compatible con las normas
PKCS#7 y PKCS#10 al menos. Esto la haría compatible con los proyectos
actuales de certificación a nivel europeo.
5.3.- Medios de difusión de claves
La CA no sólo genera certificados, sino que almacena una base de datos
de las claves certificadas por la misma, de forma que cualquier usuario pueda
solicitar la clave de otro. Podemos distribuir claves de varias maneras, y al
estar certificadas, no es vital que el medio de difusión sea
especialmente seguro (al contrario que el medio de certificación en
sí mismo, que debe estar en una máquina dedicada y aislada de la
red). Los tres medios básicos serían:
- World Wide Web
- Correo electrónico
- Directorio X.500
Los mismos medios permitirían difundir las claves públicas de las
CAs (necesarias para la verificación de los certificados), y las CRLs.
5.4.- Integración con aplicaciones
Los visualizadores de WWW más avanzados incluyen todos soporte para
distribuir certificados, así como los DSAs X.500 compilados con soporte
de X.509. El proyecto S/MIME parece ser la más realista de las dos
alternativas existentes para añadir opciones de seguridad a MIME, y
facilitará el uso en agentes de correo. Como opción para los
agentes de correo sin soporte de S/MIME tenemos los formatos compatibles con
PEM.
Existen diversas herramientas para gestionar CAs e integrar las opciones de
verificación de certificados en las aplicaciones usuales de Internet. El
proyecto ICE-TEL, que gestiona la creación de una PCA europea,
recomienda el uso del software comercial (posiblemente gratuito para
instituciones de investigación) SECUDE. Existen alternativas,
desarrolladas en universidades españolas. Una de las funciones del grupo
de trabajo IRIS-PCA será evaluar estas alternativas y ofrecer una a la
comunidad de RedIRIS.
Bibliografía
- PEM y entidades de certificación multinivel en general
- D. Balenson, S. Kent
Privacy Enhanced Mail (PEM) for Internet Electronic Mail.
RFC 1421-1424. Febrero 1993
- Certificados X.509
- ISO/IEC, ITU-T.
Information Technology - OSI. The Directory - Authentication Framework.
ISO/IEC International Standard 9594-8. ITU X.509. Diciembre 1991
- Estándares de operación basados en X.509
- W. Ford, R. Housley, W. Polk, D. Solo. Internet Public Key Infrastructure. I: X.509 Certificate and CRL Profile. Internet Draft, PKIX workgrouup. Diciembre 1996
- RSA Laboratories. Cryptographic Message Syntax Standard. PKCS #7, versión 1.5. Noviembre 1993
- Sistemas asimétricos y de firma digital. Criptosistema RSA.
- Rivest R., Shamir A., Adleman L. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, vol. 21, núm 2. Febrero 1978
- RSA Laboratories. RSA Encryption Standard. PKCS #1, versión 1.5. Noviembre 1993
- Referencias sobre criptografía en general
- RSA Laboratories. Frequently asked questions about today's cryptography (version 3.0). 1995.
- Ejemplo de política de certificación para una PCA.
- Berge, N. UNINETT PCA Policy Statement. RFC 1875. Diciembre 1995
- Referencias en Internet:
Rubén Martínez
Servicio de Seguridad
ruben [dot] martinez [at] rediris.es