Monografias | Implementación de una Autoridad de Certificación en Linux

Los certificados digitales, también llamados identificadores digitales, pasaportes digitales o certificados de llaves públicas, son documentos digitales que verifican que una llave pública corresponde a un individuo o entidad determinados. De este modo se evita que intrusos utilicen una combinación de claves asegurando ser otra persona.

Un certificado es el equivalente digital a un pasaporte, gafete de empleado o licencia de manejar. El certificado lo identifica con alguien que desee probar su identidad. De forma análoga, se presenta el siguiente ejemplo: suponiendo que es detenido por un policía de tránsito, necesita mostrarle su licencia de manejar para probar que está autorizado para manejar un carro. Así mismo, si desea entrar al trabajo, se pudiera necesitar mostrar un gafete para probar que es un empleado de la compañía.

Todas estas formas de identificación permiten establecer la identidad de cualquier persona que así lo desee. En la red de redes, un certificado establece su identidad. Probablemente, los servidores pueden verificar automáticamente los certificados de clientes que quisieran conectarse con él para verificar la identidad de cada uno asegurando que son realmente clientes autorizados para accesar al servidor.

La criptografía comprende toda una familia de tecnologías que incluyen las siguientes:

• Encriptación. Transforma la información en una forma no legible asegurando la privacidad.
• Desencriptación. Es el inverso de la encriptación; es decir, transforma la información encriptada a su forma original legible.
• Autentificación. Identifica a una entidad como un individuo, una máquina en la red o una organización.
• Firmas digitales. La relación de un documento con el dueño de una ``llave'' particular siendo el equivalente a la firma de un documento.
• Verificación de firmas. Es lo contrario de la firma digital; verifica que una firma en particular sea válida.

Para mantener la seguridad dentro del DNS dinámico se consideró la autentificación de usuarios por medio de un nombre (login) y contraseña (password). Los usuarios inicialmente se conectarían al servidor (DNS dinámico) y si el usuario teclea una combinación válida, podrían llevarse modificaciones dentro del servidor; de lo contrario, no se tendría acceso al mismo. Esta forma de autentificación es una seguridad ``débil'' por las siguientes razones:

1. Privacidad. El nombre y contraseña del cliente pueden ser capturados por un intruso y leídos sin mayor problema.
2. Verificación. No hay ninguna garantía que el nombre y contraseña del cliente no hayan sido enviados por un impostor(hacerse pasar por un cliente).

El principal problema con un simple nombre y contraseña de un cliente es el hecho de que no pueden ser verificados; por lo tanto, es necesario aplicar un mecanismo para identificar a todos los clientes que intenten conectarse al servidor (DNS dinámico) así como verificar que los clientes son realmente los que dicen ser y no sean impostores.

Se han implementado dos métodos utilizando una ``llave'' para llevar a cabo el mecanismo antes mencionado:

• Llave simétrica o secreta. Utiliza una misma llave para encriptar y desencriptar la información enviada a través de la red; pero el problema que se presenta es que tanto quien envía como quien recibe la información deben tener la misma llave asegurándose que nadie más pueda obtenerla porque si intercepta la información pudiera desencriptarla y leerla fácilmente.
• Llave asimétrica o pública. Fue inventada en 1976 por Whitfield Diffie and Martin Hellman para resolver el problema presentado por la llave simétrica. Es un método de transmisión de información en donde el que recibe la información puede estar seguro de la identidad de quien la envió. La idea básica de este método es el uso de un par de llaves:
  • Llave privada. Sólamente su dueño la conoce y se usa para desencriptar la información enviada por otras personas.
  • Llave pública. Esta se publica y se usa por cualquier persona para encriptar la información antes de enviarla a su destino (dueño).

El par de llaves se genera simultáneamente, usando algoritmos especiales en donde los mensajes que se encriptan con la llave pública de una persona puedan ser desencriptados solamente con la llave privada de esa misma persona y viceversa. Por lo tanto, para establecer una comunicación segura ya no es necesario compartir primeramente una llave privada.

Por ejemplo, si un cliente deseara enviar información segura a un servidor, el servidor daría su llave pública (por correo electrónico) y el cliente haría lo siguiente:

1. Encripta la información usando la llave pública del servidor y luego se la envía.
2. El servidor recibiría la información y la desencriptaría usando su llave privada.

Esta transmisión es segura en el sentido de que nadie más que reciba la información podrá leerla porque no sabe el valor de la llave privada.

Existe un problema que reside en el hecho de que la llave pública no puede ser verificada. Cómo se que la llave pública realmente es suya y no una llave pública generada por algún impostor que desee interceptar sus mensajes?. Este problema es más serio cuando es usado para verificar automáticamente la comunicación entre dos ``hosts'', tales como un cliente (``browser'') y un servidor (DNS dinámico). Aquí es donde intervienen los certificados.

Los certificados pueden adoptar múltiples formas. El formato más difundido está definido por la norma del ITU-T X.509 (versión 3), la cual forma parte del servicio de directorio diseñado por ISO(International Organization for Standardization, Organización Internacional de Estandarización) para el modelo OSI(Open System Interconnection, Interconexión de Sistemas Abiertos).

Un certificado X.509 es típicamente un archivo pequeño que contiene la información mostrada a continuación:

• Nombre Distintivo de la entidad. Incluye la información de identificación (el nombre distintivo) y la llave pública.
• Nombre Distintivo de la Autoridad Certificadora. Identificación y firma de la Autoridad Certificadora (CA) que firmó el certificado.
• Período de Validez. El período de tiempo durante el cual el certificado es válido.
• Información adicional. Puede contener información administrativa de la CA como un número de serie o versión.

El Nombre Distintivo de la entidad se usa para proveer una identidad en un contexto específico de acuerdo a las necesidades de la aplicación. Los Nombres Distintivos están definidos en el estándar X.509, así como por las necesidades de la aplicación. En la tabla 3.1 se definen los campos para el DNS dinámico:

Tabla 3.1: Los campos del nombre distintivo de la entidad

Campos

Descripción

Nombre Común (CN)

Nombre a ser certificado.

Organización o Compañía (O)

Nombre asociado con la Organización

Ciudad/Localidad (L)

Ciudad donde está localizado el CN.

Estado/Provincia (SP)

Estado donde está localizado el CN.

País (C)

País donde está localizado CN.

Una Autoridad Certificadora (CA,por sus siglas en inglés) es la encargada de confirmar que el dueño de un certificado es realmente la persona que dice ser. Una Autoridad Certificadora puede definir las políticas especificando cuáles campos del Nombre Distintivo son opcionales y cuáles requeridos. También puede especificar requerimientos en el contenido de los campos.

Existen varias Autoridades Certificadoras, puede que una autoridad certificadora certifique o verifique la identidad de otra Autoridad Certificadora y así sucesivamente; pero habrá un punto en que una Autoridad no tendrá quién la certifique, en este caso, el certificado es firmado por uno mismo (``self-signed''), por lo tanto, la Autoridad Certificadora es verificada o confiada por ella misma.

Las Autoridades Certificadoras (o notarios electrónicos) deben ser entes fiables y ampliamente reconocidos que firman las claves públicas de las personas, certificando con su propia firma la identidad del usuario. Por lo tanto, si se desea establecer una Autoridad Certificadora, éstas deben tomar extremadas precauciones para evitar que sus claves caigan en manos de intrusos, lo cual comprometería todo el sistema. Para ello tendrá que utilizar claves largas y dispositivos especiales para su almacenamiento. Además, cuando emiten un certificado, deben estar seguros de que lo hacen a la persona adecuada. No podemos olvidar que la Autoridad Certificadora es la responsable, en última instancia, de todo el proceso, con una serie de responsabilidades legales y que basa su ``negocio'' en la credibilidad que inspire en sus potenciales clientes. Una Autoridad Certificadora con autentificaciones erróneas no tendrá más remedio que cerrar ya que los usuarios no considerarán sus certificados de la suficiente ``calidad''.

Las Autoridades Certificadoras no solamente ofrecen certificados, sino también los manejan; es decir, determinan cuánto tiempo van a ser válidos y mantienen listas de certificados que ya no son válidos (Listas de Revocación de Certificados o CRLs).

Por ejemplo, si un empleado posee un certificado para una compañía y el empleado sale de la compañía, no solamente con el certificado se indica que ya no existe sino que se tiene que registrar por medio del CRL para que dicho certificado que ya había sido utilizado quede invalidado y no pueda ser utilizado posteriormente.

Varias compañías se han establecido como Autoridades Certificadoras. Entre las cuales destacan:

• VeriSign, Inc. [http://www.verisign.com]
• Thawte Certification. [http://www.thawte.com]
• Xcert Sentry CA. [http://www.xcert.com]
• Entrust. [http://www.entrust.net]
• Cybertrust. [http://www.baltimore.com]

Estas compañías proveen los servicios de:

1. Verificación de solicitud de Certificados.
2. Procesamiento de solicitud de Certificados.
3. Firma, asignación y manejo de Certificados.

Los certificados se ofrecen por parte de una Autoridad Certificadora a la solicitud de una persona, entidad u organización que así lo requiera.

A continuación se presenta un ejemplo de cómo le enviaría información encriptada usando la verificación de certificados represenado en la fig. 3.1:

1. Se envía un mensaje pidiendo su certificado.
2. Usted regresa su certificado.
3. Se verifica con la Autoridad Certificadora que su certificado sea válido. Especialmente, que dicha Autoridad Certificadora fue quien le dió el certificado y que su llave pública es la misma que la del certificado.
4. Se recibe la confirmación de la Autoridad Certificadora que el certificado es válido.
5. La información se encripta usando su llave pública y luego es enviada. Usted recibe la información y la desencripta usando su llave privada.

Subsecciones

Si el sistema no marca ningún error, procedemos con:  
$ make

Nuevamente, si todo funciona correctamente 
$ make test

El directorio de instalación por default es /usr/local/ssl. En este directorio encontraremos los binarios base del programa en bin/ y varios scripts para ayudarnos a manejar una autoridad certificadora en misc/.

El archivo de configuración de OpenSSL está en /usr/local/ssl/openssl.cnf; vale la pena revisarlo para asegurarnos que funcione como lo deseamos. En este texto utilizaremos sus defaults.

El primer paso que debemos dar es crear un certificado firmado por nosotros mismos. Será con este certificado que en el futuro nosotros podremos firmar los certificados que nos sean solicitados. Utilizaremos el script CA.pl localizado en /usr/local/ssl/misc para poder concentrarnos más en el procedimiento que en los detalles sintácticos.

El primer paso es crear la estructura necesaria para levantar sobre esta nuestra autoridad certificadora:

$ /usr/local/ssl/misc/CA.pl -newca

CA certificate filename (or enter to create)

Dejamos en blanco

Making CA certificate ...

Using configuration from /usr/local/ssl/openssl.cnf

Generating a 1024 bit RSA private key

...........................++++++

................................++++++

writing new private key to './demoCA/private/cakey.pem'

Enter PEM pass phrase: ejemplo

Verifying password - Enter PEM pass phrase: ejemplo

---

You are about to be asked to enter information that will be incorporated into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

---

Country Name (2 letter code) [AU]:MX

State or Province Name (full name) [Some-State]:Distrito Federal

Locality Name (eg, city) []:Mexico

Organization Name (eg, company) [Internet Widgits Pty Ltd]:UNAM

Organizational Unit Name (eg, section) []:DGSCA

Common Name (eg, YOUR name) []:Area de Seguridad en Computo

Email Address []:asc@asc.unam.mx

La contraseña que dimos aquí arriba es de vital importancia - la utilizaremos siempre que queramos firmar un certificado. Sin esta, OpenSSL se quejará y abortará la operación.

Quedamos ahora con un directorio demoCA en el cual trabajaremos con nuestra autoridad certificadora. Ahora generamos una petición de certificado:

$ /usr/local/ssl/misc/CA.pl -newreq

Using configuration from /usr/local/ssl/openssl.cnf

Generating a 1024 bit RSA private key

.++++++

.......................++++++

writing new private key to 'newreq.pem'

Enter PEM pass phrase: otroejemplo

Verifying password - Enter PEM pass phrase: otroejemplo

---

You are about to be asked to enter information that will be incorporated into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

---

Country Name (2 letter code) [AU]:MX

State or Province Name (full name) [Some-State]:Distrito Federal

Locality Name (eg, city) []:Mexico

Organization Name (eg, company) [Internet Widgits Pty Ltd]:UNAM

Organizational Unit Name (eg, section) []:DGSCA

Common Name (eg, YOUR name) []:Area de Seguridad en Computo

Email Address []:asc@asc.unam.mx

Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:secreta

An optional company name []:UNAM

Request (and private key) is in newreq.pem

Queda entonces hecha la petición de certificado, así como nuestra llave privada, en el archivo newreq.pem - El siguiente paso es firmarlo:

$ /usr/local/ssl/misc/CA.pl -sign

Using configuration from /usr/local/ssl/openssl.cnf

Enter PEM pass phrase: ejemplo

Check that the request matches the signature

Signature ok

The Subjects Distinguished Name is as follows

countryName :PRINTABLE:'MX'

stateOrProvinceName :PRINTABLE:'Distrito Federal'

localityName :PRINTABLE:'Mexico'

organizationName :PRINTABLE:'UNAM'

organizationalUnitName:PRINTABLE:'DGSCA'

commonName :PRINTABLE:'Área de Seguridad en Computo'

emailAddress :IA5STRING:'asc@asc.unam.mx'

Certificate is to be certified until Jul 3 19:42:25 2001 GMT (365 days)

Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y

Write out database with 1 new entries

Data Base Updated

Signed certificate is in newcert.pem

Por último, toca poner nuestro certificado firmado por nosotros mismos en donde OpenSSL espera encontrarlo - en el directorio especificado en /usr/local/ssl/openssl.cnf.

$ su root

Password:

# cp newcert.pem /usr/local/ssl/private/

# cp demoCA/private/cakey.pem /usr/local/ssl/private/

Los certificados del lado del cliente hasta ahora apenas y han sido utilizados. ¿Por qué? Simple: En la mayor parte de las transacciones que se llevan a cabo hoy en día en Internet, es el cliente quien dará datos confidenciales al servidor, y es el cliente el interesado en la refutabilidad de la transacción. El servidor necesita únicamente el número de la tarjeta de crédito, una contraseña o algún dato similar para dar por buena la identidad del cliente. Sin embargo, esta situación puede cambiar con el tiempo. Algunas aplicaciones que puedan requerir del uso de certificados por parte del cliente son:

• Transacciones bancarias seguras - ¿Cuántos de nosotros no hemos perdido la cartera, cuando menos una vez? Una de las primeras cosas que brincan a la mente es que ahí iba nuestra tarjeta de crédito, y hay que cancelarla de inmediato. Nuestro banco, así como diferentes sitios de comercio electrónico, podrán reconocernos por nuestro certificado, el cual no será fácil de perder -estará dentro de nuestra computadora, y puede estar además protegido por contraseña. Los sitios de comercio electrónico pueden, con el tiempo, dejar de aceptar tarjetas de crédito, para aceptar únicamente certificados.
• Votaciones electrónicas - En cada vez más países, los certificados digitales son reconocidos como formas válidas y legales de identificación personal. Es posible que para las próximas elecciones presidenciales no tengamos que formarnos en cola, es más, no tengamos siquiera que salir de casa. Cada elector tendrá asociada -tal como ahora tiene a su fotografía- una firma digital, y podrá votar desde casa.
• Comunicación oficial - Muchos de nosotros hemos intentado implementar sistemas que substituyan al papeleo en nuestras organizaciones. El argumento eterno de los usuarios es que no podrán aseverar a ciencia cierta si un documento fue firmado por una persona o no. Conforme las firmas electrónicas vayan cobrando importancia, este argumento perderá fuerza, y posiblemente dentro de diez años, aún en las burocracias más atrincheradas, logremos un trabajo sin papeles.

El proceso de generación de certificados es muy diferente del que manejamos para los servidores; los certificados son generados por scripts CGI y enviados directamente al navegador, que los depositará en una base de datos interna. Esta base de datos generalmente irá cifrada con una contraseña. Si el usuario decide no cifrarla, para mantener los certificados seguros, estos no podrán ser exportados para ser llevados a otros sistemas.

En un servidor Apache es bastante sencillo configurar zonas del servidor que solamente puedan ser accesadas presentando un certificado válido, y de hecho, cuando éste es presentado en la ejecución de un CGI, exporta como variables de ambiente al CGI, con lo cual se vuelve muy sencillo trabajar con estos datos dentro de nuestra aplicación.

La estructura de directorios se utiliza para la manipulación de certificados por parte de la Autoridad Certificadora.

La Autoridad Certificadora crea, valida y revoca los certificados por medio del OpenSSL. Para accesar al OpenSSL a través de perl se utilizan los módulos siguientes del OpenCA: OpenCA::OpenSSL y OpenCA::X509. OpenCA::OpenSSL contiene funciones que crean y revocan los certificados, mientras que OpenCA::X509 valida el certificado de un cliente.

Antes de crear la estructura con sus subdirectorios y archivos, se ``abre'' una terminal y se coloca dentro del subdirectorio en el cual se creará la estructura.

Una vez que se encuentra dentro del subdirectorio deseado, se crea la siguiente estructura incluyendo el archivo de número de serie para los certificados, inicializado en ``01''(serial) y el archivo de ``base de datos'' de certificados (index.txt):

$ mkdir demoCA/certs. #contiene el certificado del CA.

$ mkdir demoCA/crl #subdirectorio no utilizado.

$ mkdir demoCA/newcerts #contiene los certificados nuevos

$ mkdir demoCA/private #tiene la llave privada de la CA.

$ echo ``01'' > SSLDIR/serial #Numero para un nvo. certificado.

$ touch SSLDIR/index.txt #Indice de certificados creados.

Cuando un cliente se registra, la Autoridad Certificadora le crea y otorga un certificado al cliente. El nuevo certificado es creado utilizando la llave privada de la CA encontrada en demoCA/private y su certificado localizado en demoCA/newcerts. Una vez creado el certificado, se registra en el archivo index.txt y el número de serie de serial se incrementa en uno. El nuevo certificado se coloca en demoCA/certs indicando el número de serie que le tocó al certificado.

Al realizar la autentificación de un cliente en base a su certificado, éste se busca en el archivo index.txt, si se encuentra y no ha sido revocado, el certificado es válido.

1

Ritter's Crypto Glossary and Dictionary of Technical Cryptography

2

Glossary for the Linux FreeS/WAN project

3

J/CRYPTO Developer's Guide v4.0

4

Cryptography FAQ Index

5

New Directions in Cryptography, Diffie y Hellman, 1976

6

Aspectos Legales en torno a Internet, Lic. Libia E. Barajas Mariscal, Seminario GASU 18/5/2000

7

RFC 1320/RFC 1321, The MD4 Message-Digest Algorithm/The MD5 Message-Digest Algorithm, R. Rivest, 1992

8

The OpenSSL Project

9

SSLeay Certificate Cookbook

10

Página de criptografía de Eduardo Sacristán

11

OpenSSL