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.
Autoridades Certificadoras (CA)
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.
Cómo funcionan los 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.
6. Usted recibe la información y la desencripta usando su llave privada.
Figura 3.1: Ejemplo de información encriptada usando certificados
Implementación de una autoridad certificadora
A continuación, mostraré los pasos básicos para implementar una autoridad certificadora. Para esto, utilizaremos el programa OpenSSL. Escogí OpenSSL [8]puesto que es software libre, y parte del proyecto OpenBSD, creadores del Unix más seguro disponible hoy en día. OpenSSL es la evolución del juego de bibliotecas para SSL desarrollado por Eric A. Young, SSLeay. Hago las muestras de instalación en un sistema operativo Linux, aunque es básicamente igual en cualquier Unix. Para mayores detalles acerca de éste proceso, les invito a consultar el SSLeay Certificate Cookbook[9].
Subsecciones
Instalación de OpenSSL
Creación y auto-firma de nuestro certificado
Creación e instalación de certificados para servidor Web
Instalación de OpenSSL
La instalación de OpenSSL es muy sencilla – Basta descargar el paquete de http://www.openssl.org/source/ y compilarlo. La última versión es la 0.9.5a, publicada el 3 de abril del 2000. La secuencia de comandos para compilarlo e instalarlo siguiendo la configuración default es: $ tar xvzf openssl-0.9.5a.tar.gz $ cd openssl-0.9.5a $ ./config
Si el sistema no marca ningún error, procedemos con: $ make
Nuevamente, si todo funciona correctamente $ make test
Y por último, si las pruebas concluyen exitosamente –y este paso tendremos que hacerlo como root– instalamos el programa: $ su Password: # make install
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.
Creación y auto-firma de nuestro certificado
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 []:[email protected]
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:'[email protected]'
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/
Creación e instalación de certificados para cliente Web
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 para la manipulación de certificados
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.
Conclusión
La seguridad es uno de los aspectos más conflictivos del uso de Internet. La falta de una política de seguridad global está frenando el desarrollo de Internet en áreas tan interesantes y prometedoras como el comercio electrónico o la interacción con las administraciones públicas, por ello es importante crear un entorno seguro. Las técnicas criptográficas actuales proporcionan un alto grado de confidencialidad; pero es durante la transferencia de información donde más peligro de seguridad existe. En un servidor seguro es donde mejor se preserva la intimidad y confidencialidad de sus clientes y donde se dan los mayores servicios de seguridad. Bibliografía
1
Ritter's Crypto Glossary and Dictionary of Technical Cryptography
http://www.io.com/~ritter/GLOSSARY.HTM
2
Glossary for the Linux FreeS/WAN project
http://www.freeswan.org/freeswan_trees/freeswan-1.3/doc/glossary.html
3
J/CRYPTO Developer's Guide v4.0
http://www.baltimore.com/products/jcrypto/devguide/JCryptoDevGuide-Contents.html
4
Cryptography FAQ Index
http://www.faqs.org/faqs/cryptography-faq/
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
http://www.asc.unam.mx/Actividades_y_Eventos/seminarios_gasu.html
7
RFC 1320/RFC 1321, The MD4 Message-Digest Algorithm/The MD5 Message-Digest Algorithm, R. Rivest, 1992
8
The OpenSSL Project
http://www.openssl.org
9
SSLeay Certificate Cookbook
http://www.ultranet.com/~fhirsch/Papers/cook/ssl_cook.html
10
Página de criptografía de Eduardo Sacristán
http://cripto.matcuer.unam.mx
11
OpenSSL
http://www.modssl.org/
Autor:
Otniel Jaday Garcia Tejedor
| Página siguiente |