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.
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).
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** |
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 |
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.
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.
- 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
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.
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
| 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
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:
- Página de referencia del grupo de trabajo IRIS-PCA: http://www.rediris.es/cert/pca
- Estándares, RFC y borradores (drafts) de Internet: ftp://ftp.rediris.es/docs/network
- Páginas de RSA laboratories. Incluyen la FAQ íntegra (110 páginas)y todos los documentos PKCS.: http://www.rsa.com/rsalabs
Servicio de Seguridad
ruben [dot] martinez [at] rediris.es