curso firma digital2

Curso de introducción a la firma digital


Ricardo Lorenzo Rodríguez

WHITEBEARSOLUTIONS S.L.Tel. 902906969

Página 1 de 77


Índice de contenido1Introducción a la criptografía..........................................................................................52Criptografía simétrica........................................................................................................6

2.1Definición.....................................................................................................................62.2Tipos de algoritmos simétricos..................................................................................6

2.2.13DES.......................................................................................................................62.2.2Blowfish.................................................................................................................72.2.3IDEA.......................................................................................................................82.2.4AES........................................................................................................................8

2.3Intercambio de claves...............................................................................................92.4Sistema híbrido..........................................................................................................10

3Criptografía asimétrica o de clave pública.................................................................113.1Definición...................................................................................................................113.2Algoritmos actuales..................................................................................................12

3.2.1DiffieHellman.....................................................................................................123.2.2RSA......................................................................................................................123.2.3DSA......................................................................................................................133.2.4ElGamal..............................................................................................................133.2.5Criptografía de curvas elípticas......................................................................14

3.3Debilidades...............................................................................................................143.3.1.1Ataque ManInTheMiddle.......................................................................14

4Encapsulación SSL/TLS.....................................................................................................144.1Prácticas OpenSSL....................................................................................................17

4.1.1Primer contacto con OpenSSL.........................................................................174.1.2Huellas digitales..................................................................................................184.1.3Generar contraseñas........................................................................................184.1.4Cifrado simétrico................................................................................................19

4.2IKE (Internet key Exchange).....................................................................................194.2.1IpSec...................................................................................................................204.2.2Implementaciones sobre GNU/Linux..............................................................214.2.3Práctica Stunnel................................................................................................224.2.4Prácticas Racoon..............................................................................................26

4.2.4.1Cifrado punto a punto..............................................................................265Identidad y criptografía asíncrona...............................................................................28

5.1X.509 y OpenPGP......................................................................................................285.1.1X.509.....................................................................................................................285.1.2OpenPGP............................................................................................................30


Página 2 de 77


5.2Estándares PKCS.......................................................................................................305.3Extensiones de ficheros............................................................................................32

6Infraestructura de clave pública...................................................................................336.1 Autoridad de certificación.....................................................................................34

6.1.1Normativa...........................................................................................................356.2 Clases de certificados............................................................................................356.3Listas de revocación................................................................................................366.4Prácticas OpenSSL....................................................................................................37

6.4.1Creación del certificado de CA.....................................................................386.4.2Creación y firma de un certificado certificado...........................................386.4.3Mostrando el contenido de un certificado...................................................396.4.4Exportar los certificados a otros formatos......................................................396.4.5Revocación de certificados............................................................................406.4.6Cifrado asimétrico............................................................................................406.4.7Integración con directorios LDAP....................................................................41

7Tarjetas criptográficas (smart cards).............................................................................497.1Definición...................................................................................................................497.2PCSD, OpenSC y generación de tarjetas smart card..........................................50

7.2.1PC/SC..................................................................................................................507.2.2OpenSC...............................................................................................................51

7.3Autenticación con tarjetas y PAM..........................................................................517.4Práctica PCSDd y OpenSC......................................................................................51

7.4.1Dispositivo C3PO LTC31......................................................................................527.4.2Software de verificación y gestión del dispositivo........................................537.4.3Software de gestión de las tarjetas.................................................................55

8Autoridades de Certificación y Listas de RevocaciónRCM como prestador de Servicios de Certificación. CERES....................................................................................57

8.1 7.1 La Fábrica Nacional de Moneda y Timbre como autoridad de certificación...................................................................................................................578.2 7.2 Proyecto CERES..................................................................................................578.3 7.3 Buenas prácticas en el uso de certificados...................................................578.4 7.4 Uso de certificados orientados a la Administración Pública.......................57

9GNUPG..............................................................................................................................579.1Definición...................................................................................................................579.2Funcionamiento........................................................................................................589.3GPG versión SMIME..................................................................................................589.4Practica GPG............................................................................................................58

10Otras aplicaciones.........................................................................................................6610.1Práctica Apache/SSL.............................................................................................66


Página 3 de 77


10.1.1Acerca de mod_ssl..........................................................................................6610.1.2Requisitos..........................................................................................................6610.1.3Procedimientos.................................................................................................6710.1.4Generando clave y certificado.....................................................................6710.1.5Configuración de Apache.............................................................................6810.1.6Comprobaciones............................................................................................70


Página 4 de 77


1 Introducción a la criptografíaLa etimología de la palabra criptografía, tiene su origen en las palabras griegas krypto que significa “oculto”, y la palabra graphos que significa “escribir”, por lo que en el sentido literal, la palabra criptografía significa “escritura oculta”. Siendo este el significado literal, coloquialmente se denomina también así al contexto en el que algún intercambio de mensajes se asegura a través de técnicas de cifrado.

El estudio de estas técnicas de cifrado se conoce como “criptología”, y el estudio de los mecanismos que permiten romper el cifrado de los mensajes se conoce como “criptoanálisis”.

El objetivo de la criptografía es el de garantizar el secreto de los mensajes en la comunicación entre dos entidades, así como también asegurar que la información que se envía es auténtica en un doble sentido, es decir, que el remitente sea realmente quien dice ser y que el contenido del mensaje enviado, comúnmente denominado “criptograma”, no haya sido modificado en su tránsito.

Habitualmente el mensaje original que debe protegerse se denomina “texto en claro”. El cifrado por tanto, es el proceso de convertir el “texto claro” en un conjunto de información ilegible o criptograma. Las dos técnicas más sencillas de cifrado, en la criptografía clásica, son la sustitución (que supone el cambio de significado de los elementos básicos del mensaje) y la trasposición (que supone una reordenación de los mismos); la gran mayoría de los algoritmos clásicos son combinaciones de estas dos operaciones básicas.

Existen dos grandes grupos de algoritmos de cifrado: los algoritmos que utilizan una única clave tanto en el proceso de cifrado como en el de descifrado, y los que utilizan una clave para cifrar mensajes y una clave distinta para descifrarlos. Los primeros se denominan algoritmos simétricos, o de clave simétrica. Los segundos se denominan algoritmos asimétricos, o de clave pública.


Página 5 de 77


2 Criptografía simétrica

2.1 DefiniciónLa criptografía simétrica es el método criptográfico que usa una misma clave para cifrar y descifrar mensajes. Las dos partes que se comunican han de ponerse de acuerdo de antemano sobre la clave a usar.

Teniendo en cuenta que los algoritmos modernos basan su seguridad en la clave y no en el algoritmo, es importante que sea muy difícil adivinar el tipo de clave. Esto quiere decir que el conjunto de claves posibles, lo que se conoce como “el espacio de posibilidades de claves”, debe ser muy amplio.

En la actualidad los ordenadores cuentan con la capacidad de descifrar claves con extrema rapidez, y es la razón por la cual el tamaño de la clave es tremendamente relevante en los criptosistemas modernos. Por ejemplo, el algoritmo de cifrado DES usa una clave de 56 bits, lo que significa que hay 2 elevado a 56 claves posibles. Esto representa un número muy alto de claves, pero un ordenador de uso general puede comprobar el conjunto posible de claves en cuestión de días. Una superordenador podría hacerlo en horas. Algoritmos de cifrado de diseño más reciente como 3DES, Blowfish e IDEA usan claves de 128 bits, lo que significa que existen 2 elevado a 128 claves posibles. Esto equivale a muchísimas más claves, así que en este caso, aunque todas las máquinas del planeta estuvieran trabajando concurrentemente, tardarían en encontrar la clave más o menos la edad teórica del universo.

2.2 Tipos de algoritmos simétricos

2.2.1 3DES

Su base histórica es el algoritmo DES (Data Encryption Standard), escogido como FIPS (Federal Information Processing Standards) en los Estados Unidos en 1976, y cuyo uso se ha propagado ampliamente por todo el mundo. Este algoritmo fue controvertido al principio, debido a algunos elementos de diseño clasificados, una longitud de clave relativamente corta, y las


Página 6 de 77


continuas sospechas sobre la existencia de alguna puerta trasera para la National Security Agency (NSA).

3DES pretendía eliminar los posibles ataques haciendo un triple cifrado. 3DES fue desarrollado por IBM en 1978. Actualmente se cree que este algoritmo es seguro en la práctica, aunque existen ataques teóricos.

Al descubrirse que una clave de 56 bits no era suficiente para evitar un ataque de fuerza bruta, 3DES fue elegido como la manera de extender el tamaño de la clave sin necesidad de cambiar de algoritmo de cifrado. Este método de cifrado dobla la longitud efectiva de la clave (112 bits), pero en cambio es preciso triplicar el número de operaciones de cifrado, haciendo este método de cifrado muchísimo más seguro que el DES. Por tanto, la longitud de la clave usada será de 192 bits, aunque su eficacia solo sea de 112 bits

En la actualidad, este algoritmo es reemplazado por AES. Sin embargo, la mayoría de las tarjeta de crédito y otros medios de pago electrónico tienen como estándar el algoritmo 3DES (anteriormente usaban el DES). Por el diseño DES y por lo tanto 3DES son algoritmos lentos. AES puede llegar a ser hasta 6 veces más rápido y hasta el día de la fecha no se encontró ninguna vulnerabilidad.

2.2.2 Blowfish

Originalmente diseñado por Bruce Schneier en 1993. Hoy en día, se ha dado más atención de la decodificación de bloques con bloques más grandes, como AES y Twofish.

Schneier diseñó Blowfish como un algoritmo de uso general, que intentaba reemplazar al antiguo DES y evitar los problemas asociados con otros algoritmos. Al mismo tiempo, muchos otros diseños eran propiedad privada, patentados o los guardaba el gobierno. Schneier declaró “Blowfish no tiene patente, y así se quedará en los demás continentes. El algoritmo está a disposición del público, y puede ser usado libremente por cualquiera”.


Página 7 de 77


2.2.3 IDEAEl algoritmo IDEA (International Data Encryption Algorithm) descrito por primera vez en 1991 y diseñado en contrato con la Fundación Hasler, la cual se hizo parte de AscomTech AG. IDEA es libre para uso no comercial, aunque fue patentado y sus patentes se vencerán en 2010 y 2011. El nombre “IDEA” es una marca registrada y está licenciada a nivel mundial por MediaCrypt.

IDEA fue utilizado como el cifrador simétrico en las primeras versiones de PGP (PGP v2.0) y se lo incorporó luego de que el cifrador original usado en la v1.0 ("BassOMatic") se demostró insegura. Es un algoritmo óptimo en OpenPGP.

Este algoritmo opera con bloques de 64 bits usando una clave de 128 bits y consiste de ocho transformaciones idénticas (cada una llamada un ronda) y una transformación de salida (llamada media ronda).

En primer lugar, el ataque por fuerza bruta resulta impracticable, ya que sería necesario probar 1038 claves, cantidad imposible de manejar con los medios informáticos actuales.

Los diseñadores analizaron IDEA para medir su fortaleza frente al criptoanálisis diferencial y concluyeron que es inmune bajo ciertos supuestos. No se han reportado debilidades frente criptoanálisis lineal o algebraico. Se han encontrado algunas claves débiles, las cuales en la práctica son poco usadas siendo necesario evitarlas explícitamente.

2.2.4 AES

El algoritmo AES (Advanced Encryption Standard), es también conocido como Rijndael. Este algoritmo es un esquema de cifrado por bloques que hoy en día es adoptado como estándar de cifrado por el gobierno de los Estados Unidos. Se espera que sea usado en el mundo entero y analizado exhaustivamente, como fue el caso de su predecesor, el Data Encryption Standard (DES). El AES fue anunciado por el Instituto Nacional de Estándares y Tecnología (NIST) como FIPS PUB 197 de los Estados Unidos (FIPS 197) el 26 de noviembre de 2001 después de un proceso de estandarización que duró


Página 8 de 77


5 años.

La estructura matemática de AES constituye una preocupación para algunos investigadores, ya que a diferencia de la mayoría de cifradores de bloques, AES tiene una descripción matemática muy ordenada. Esto no ha llevado todavía a ningún ataque, pero algunos investigadores están preocupados por que futuros ataques quizá encuentren una manera de explotar esta estructura.

En 2002, se publicó un ataque teórico, denominado “ataque XSL”, que fue anunciado por Nicolas Courtois y Josef Pieprzyk, mostrando una potencial debilidad en el algoritmo AES. Varios expertos criptográficos han encontrado problemas en las matemáticas que hay por debajo del ataque propuesto, sugiriendo que los autores quizá hayan cometido un error en sus estimaciones. Si esta línea de ataque puede ser tomada contra AES, es una cuestión todavía abierta. Hasta el momento, el ataque XSL contra AES parece especulativo; es improbable que nadie pudiera llevar a cabo en la práctica este ataque.

Hasta 2005, no se ha encontrado ningún ataque exitoso contra el AES. La Agencia de Seguridad Nacional de los Estados Unidos (NSA) revisó todos los finalistas candidatos al AES, incluyendo el Rijndael, y declaró que todos ellos eran suficientemente seguros para su empleo en información no clasificada del gobierno de los Estados Unidos. En junio de 2003, el gobierno de los Estados Unidos anunció que el AES podía ser usado para información clasificada.

2.3 Intercambio de clavesEl principal problema con los sistemas de cifrado simétrico no está ligado a su seguridad, sino al intercambio de claves. Una vez que el remitente y el destinatario hayan intercambiado las claves pueden usarlas para comunicarse con seguridad, pero ¿qué canal de comunicación que sea seguro han usado para transmitirse las claves? Sería mucho más fácil para un atacante intentar interceptar una clave que probar las posibles combinaciones del espacio de claves.


Página 9 de 77


Otro problema es el número de claves que se necesitan. Si tenemos un número X de personas que necesitan comunicarse entre sí, se necesitan X/2 claves para cada pareja de personas que tengan que comunicarse de modo privado. Esto es viable con un grupo reducido de personas, pero sería imposible llevarlo a cabo con grupos más grandes.

2.4 Sistema híbridoLa criptografía híbrida es un método criptográfico que usa tanto un cifrado simétrico como un asimétrico. Emplea el cifrado de clave pública para compartir una clave para el cifrado simétrico. El mensaje que se esté enviando en el momento, se cifra usando la clave y enviándolo al destinatario. Ya que compartir una clave simétrica no es seguro, la clave usada es diferente para cada sesión.

Tanto PGP como GnuPG usan sistemas de cifrado híbridos. La clave de sesión es cifrada con la clave pública, y el mensaje saliente es cifrado con la clave simétrica, todo combinado automáticamente en un sólo paquete. El destinatario usa su clave privada para descifrar la clave de sesión y acto seguido usa la clave de sesión para descifrar el mensaje.

Un sistema de cifrado híbrido no es más fuerte que el de cifrado asimétrico o el de cifrado simétrico de los que hace uso, independientemente de cuál sea más débil. En PGP y GnuPG el sistema de clave pública es probablemente la parte más débil de la combinación.


Página 10 de 77

Canal seguro

Intercambiode claves


3 Criptografía asimétrica o de clave pública

3.1 DefiniciónSe trata de un método criptográfico que usa un par de claves para el envío de los mensajes. Ambas claves pertenecen a la misma entidad o persona que intercambia un mensaje. Una de las claves es pública y se puede entregar a cualquiera, la otra clave es privada y el propietario debe guardarla de modo que nadie tenga acceso a ella. Los métodos criptográficos garantizan que esa pareja de claves sólo se puede generar una vez, de modo que se puede asumir que no es posible que dos personas hayan obtenido casualmente la misma pareja de claves.

Si el remitente usa la clave pública del destinatario para cifrar el mensaje, una vez cifrado, sólo la clave privada del destinatario podrá descifrar este mensaje, ya que es el único que la conoce. Si el propietario del par de claves usa su clave privada para cifrar el mensaje, cualquiera puede descifrarlo utilizando su clave pública. En este caso se consigue por tanto la identificación y autenticación del remitente, ya que se sabe que sólo pudo haber sido él quien utilizó su clave privada.

Los sistemas de cifrado de clave pública o sistemas de cifrado asimétricos se inventaron con el fin de evitar por completo el problema del intercambio de claves de los sistemas de cifrado simétricos. Con las claves públicas no es


Página 11 de 77

Canal seguro

Llave pública

Llave privada

Llave pública

Llave privada


necesario que el remitente y el destinatario se pongan de acuerdo en la clave a emplear.

Es de destacar que al igual que en la criptografía simétrica, la seguridad se apoya en la clave y no en el algoritmo, por lo que el tamaño de la clave es una medida de seguridad.

✔ Una clave de 512bits representa 155 dígitos decimales.

✔ Por tanto 128bits no son suficientes como en la criptografía simétrica, se recomienda 1024bits.

✔ La alternativa es la criptografía de curva elíptica.

3.2 Algoritmos actuales

3.2.1 DiffieHellmanSu nombre es debido a sus creadores Whitfield Diffie y Martin Hellman. Este algoritmo permite el intercambio secreto de claves entre dos partes que no han tenido contacto previo, utilizando un canal inseguro, y de manera anónima (no autenticada).

Se emplea generalmente como medio para acordar claves simétricas que serán empleadas para el cifrado de una sesión. Su seguridad radica en la extrema dificultad (conjeturada, no demostrada) de calcular logaritmos discretos en un campo finito.

3.2.2 RSAEl sistema criptográfico RSA es un algoritmo asimétrico de cifrado de bloques, que utiliza una clave pública, la cual se distribuye (en forma autenticada preferentemente), y otra privada, la cual es guardada en secreto por su propietario.


Página 12 de 77


Una clave es un número de gran tamaño, que una entidad o persona puede concebir como un mensaje digital, como un archivo binario o como una cadena de bits o bytes.

Los mensajes enviados usando el algoritmo RSA se representan mediante números y su funcionamiento se basa en el producto de dos números primos grandes (mayores que 10100) elegidos al azar para conformar la clave de descifrado.

La seguridad de este algoritmo radica en que no hay maneras rápidas conocidas de factorizar un número grande en sus factores primos utilizando computadoras tradicionales. La computación cuántica podría proveer una solución a este problema de factorización.

3.2.3 DSA

DSA (Digital Signature Algorithm) es un estándar del Gobierno Federal de los Estados Unidos de América o FIPS para firmas digitales. DSA se hizo público el 30 de agosto de 1991. Este algoritmo sirve únicamente para firmar y no para cifrar información. Una desventaja de este algoritmo es que requiere mucho más tiempo de cómputo, comparado por ejemplo con RSA.

3.2.4 ElGamal

Este algoritmo es un esquema de cifrado basado en problemas matemáticos de algoritmos discretos. Es un algoritmo de criptografía asimétrica basado en la idea de DiffieHellman. El algoritmo de ElGamal puede ser utilizado tanto para generar firmas digitales como para cifrar o descifrar.

Fue descrito por Taher Elgamal en 1984 y se usa en aplicaciones como GNU Privacy Guard, versiones recientes de PGP, y otros sistemas criptográficos. Este algoritmo no esta bajo ninguna patente lo que lo hace de uso libre.

La seguridad del algoritmo se basa en la suposición que la función utilizada es de un sólo sentido y la dificultad de calcular un logaritmo discreto.


Página 13 de 77


3.2.5 Criptografía de curvas elípticas

La utilización de curvas elípticas en criptografía fue propuesta de forma independiente por Neal Koblitz y Victor Miller en 1985. Estos algoritmos son una variante de la criptografía asimétrica o de clave pública basada en las matemáticas de las curvas elípticas. Sus autores argumentan que este tipo de criptografía puede ser más rápida y usar claves más cortas que los métodos antiguos como RSA, al tiempo que proporcionan un nivel de seguridad equivalente.

3.3 DebilidadesEn resumen, la gran ventaja de la criptografía asimétrica es que se puede cifrar con una clave y descifrar con la otra, sin embargo no está exento de desventajas como las siguientes:

✔ Para una misma longitud de clave y mensaje se necesita mayor tiempo de proceso.

✔ Las claves deben ser de mayor tamaño que las simétricas.

✔ El mensaje cifrado ocupa más espacio que el original.

3.3.1.1 Ataque ManInTheMiddle

En criptografía, un ataque maninthemiddle (MitM, u hombre en el medio, en castellano) es un ataque en el que el enemigo adquiere la capacidad de leer, insertar y modificar a voluntad, los mensajes entre dos partes sin que ninguna de ellas conozca que el enlace entre ellos ha sido violado. El atacante debe ser capaz de observar e interceptar mensajes entre las dos víctimas. El ataque MitM es particularmente significativo en el protocolo original de intercambio de claves de DiffieHellman, cuando éste se emplea sin autenticación.

4 Encapsulación SSL/TLSSecure Sockets Layer (SSL) y Transport Layer Security (TLS Seguridad de la Capa de Transporte), su sucesor, son protocolos criptográficos que proporcionan


Página 14 de 77


comunicaciones seguras en Internet. Existen pequeñas diferencias entre SSL 3.0 y TLS 1.0, pero el protocolo permanece sustancialmente igual. El término “SSL” según se usa aquí, se aplica a ambos protocolos a menos que el contexto indique lo contrario.

SSL proporciona autenticación y privacidad de la información entre extremos sobre Internet mediante el uso de criptografía. Habitualmente, sólo el servidor es autenticado (es decir, se garantiza su identidad) mientras que el cliente se mantiene sin autenticar; la autenticación mutua requiere un despliegue de infraestructura de claves públicas (o PKI) para los clientes. Los protocolos permiten a las aplicaciones clienteservidor comunicarse de una forma diseñada para prevenir escuchas, la falsificación de la identidad del remitente y mantener la integridad del mensaje.

SSL implica una serie de fases básicas:

✔ Negociar entre las partes el algoritmo que se usará en la comunicación

✔ Intercambio de claves públicas y autenticación basada en certificados digitales

✔ Cifrado del tráfico basado en cifrado simétrico

Durante la primera fase, el cliente y el servidor negocian qué algoritmos criptográficos se van a usar. Las implementaciones actuales proporcionan las siguientes opciones:

✔ Para criptografía de clave pública: RSA, DiffieHellman, DSA (Digital Signature Algorithm) o Fortezza;

✔ Para cifrado simétrico: RC2, RC4, IDEA (International Data Encryption Algorithm), DES (Data Encryption Standard), Triple DES o AES (Advanced Encryption Standard);

✔ Con funciones hash: MD5 o de la familia SHA

El protocolo SSL intercambia registros; opcionalmente, cada registro puede ser


Página 15 de 77


comprimido, cifrado y empaquetado con un código de autenticación del mensaje (MAC). Cada registro tiene un campo de content_type que especifica el protocolo de nivel superior que se está usando.

Cuando se inicia la conexión, el nivel de registro encapsula otro protocolo, el protocolo handshake, que tiene el “content_type 22”.

El cliente envía y recibe varias estructuras handshake:

✔ Envía un mensaje ClientHello especificando una lista de conjunto de cifrados, métodos de compresión y la versión del protocolo SSL más alta permitida. Éste también envía bytes aleatorios que serán usados más tarde (llamados Challenge de Cliente o Reto). Además puede incluir el identificador de la sesión.

✔ Después, recibe un registro ServerHello, en el que el servidor elige los parámetros de conexión a partir de las opciones ofertadas con anterioridad por el cliente.

✔ Cuando los parámetros de la conexión son conocidos, cliente y servidor intercambian certificados (dependiendo de las claves públicas de cifrado seleccionadas). Estos certificados son actualmente X.509, pero hay también un borrador especificando el uso de certificados basados en OpenPGP.

✔ El servidor puede requerir un certificado al cliente, para que la conexión sea mutuamente autenticada.

✔ Cliente y servidor negocian una clave secreta común llamada master secret, posiblemente usando el resultado de un intercambio DiffieHellman, o simplemente cifrando una clave secreta con una clave pública que es descifrada con la clave privada de cada uno. Todos los datos de claves restantes son derivados a partir de este master secret (y los valores aleatorios generados en el cliente y el servidor), que son pasados a través una función pseudo aleatoria cuidadosamente elegida.

TLS/SSL poseen una variedad de medidas de seguridad:

✔ Numerando todos los registros y usando el número de secuencia en el MAC.


Página 16 de 77


✔ Usando un resumen de mensaje mejorado con una clave (de forma que solo con dicha clave se pueda comprobar el MAC). Esto se especifica en el RFC 2104).

✔ Protección contra varios ataques conocidos (incluidos ataques man in the middle attack), como los que implican un degradado del protocolo a versiones previas (por tanto, menos seguras), o conjuntos de cifrados más débiles.

✔ El mensaje que finaliza el protocolo handshake (Finished) envía un hash de todos los datos intercambiados y vistos por ambas partes.

✔ La función pseudo aleatoria divide los datos de entrada en 2 mitades y las procesa con algoritmos hash diferentes (MD5 y SHA), después realiza sobre ellos una operación XOR. De esta forma se protege a sí mismo de la eventualidad de que alguno de estos algoritmos se revelen vulnerables en el futuro.

4.1 Prácticas OpenSSLOpenSSL es un proyecto de software desarrollado por los miembros de la comunidad Open Source para libre descarga y está basado en SSLeay desarrollado por Eric Young y Tim Hudson. Consiste en un robusto paquete de herramientas de administración y librerías relacionadas con la criptografía, que suministran funciones criptográficas a otros paquetes como OpenSSH y navegadores web (para acceso seguro a sitios HTTPS). Estas herramientas ayudan al sistema a implementar el Secure Sockets Layer (SSL), así como otros protocolos relacionados con la seguridad, como el Transport Layer Security (TLS). Este paquete de software es importante para cualquiera que esté planeando usar cierto nivel de seguridad en su máquina con un sistema operativo Libre basado en GNU/Linux. OpenSSL también nos permite crear certificados digitales que podremos aplicar a nuestro servidor, por ejemplo Apache.

4.1.1 Primer contacto con OpenSSLVemos tres ayudas: Standard Commands, Message Digests y Cipher commands. Para ver la de estas tres secciones de forma independiente puedes usar los comandos:

$ openssl liststandardcommands


Página 17 de 77


$ openssl listmessagedigestcommands

$ openssl listciphercommands

4.1.2 Huellas digitalesOpenSSL puede combinarse con el comando find para hacer ``huellas digitales'' (fingerprints) de muchos archivos a la vez:

$ find /etc type f | xargs openssl md5 > /etc/secure/md5_sigs.txt

El anterior comando creará un archivo MD5 hash de todos los archivos del directorio /etc. Estos finger prints deben ser almacenados como solo lectura y en un lugar seguro.

4.1.3 Generar contraseñasPodemos usar OpenSSL para generar contraseñas a través del comando passwd. Esta opción puede ser usada para automatizar el aprovisionamiento de usuarios o la actualización de contraseñas. El siguiente ejemplo muestra como generar el MD5 de la contraseña ``blah'':

$ echo blah | openssl passwd stdin 1

La opción ``1'' indica que usaremos MD5 como algoritmo y la opción ``stdin'' indica que le pasamos la contraseña a través de la entrada estándar. Si tu sistema operativo no soporta MD5 las contraseñas puede ser creadas con CRYPT:

$ echo blah | openssl passwd stdin crypt salt GH

Este comando generará una contraseña crypt de ``blah'' con ``GH'' como salt.


Página 18 de 77


4.1.4 Cifrado simétricoEl programa OpenSSL soporta de manera estándar muchos algoritmos de cifrado, incluidas diferentes variantes de cada uno. El comando necesario para cifrar con el algoritmo DES el documento texto.txt y generar texto\_cifrado.txt es el siguiente:

$ openssl des in texto.txt out texto_cifrado.txt pass pass:clave

Para utilizar otro algoritmo basta cambiar ``des'' por el nombre del algoritmo deseado (des3, rc2, rc4, rc5, idea, bf, aes256ecb, etc.). Para descifrar el archivo se utiliza el mismo comando, pero añadiendo la opción d (descifrar), como por ejemplo:

$ openssl des d in texto_cifrado.txt out texto_original.txt pass pass:clave

4.2 IKE (Internet key Exchange)Internet key exchange (IKE) es un protocolo usado para establecer una Asociación de Seguridad (SA) en el protocolo Ipsec.

Supone una alternativa al intercambio manual de claves. Su objetivo es la negociación de una Asociación de Seguridad para IPSEC. Permite, además, especificar el tiempo de vida de la sesión IPSEC, autenticación dinámica de otras máquinas, etc.

La mayoría de la implementaciones de IPsec consisten en un dominio IKE que corre en el espacio de usuario y una pila IPsec dentro del kernel que procesa los paquetes IP.

El protocolo IKE usa paquetes UDP, normalmente a través del puerto 500, y generalmente requiere entre 4 y 6 paquetes con dos turnos para crear una SA en ambos extremos.


Página 19 de 77


4.2.1 IpSecEs un estándar para la securización del protocolo IP (IP Security), básicamente cifra o autentica los paquetes IP. IPSec opera en la capa 3, lo que lo hace más flexible que SSL/TLS que opera en la capa 4 o superiores.

Se trata de un conjunto de protocolos y flujos de intercambio seguros. Formalmente existen dos protocolos de transmisión:

✔ AH (Authentication Header): Proporciona autenticación e integridad de los mensajes, pero no realiza cifrado. Este protocolo no opera si existen traducciones SNAT.

✔ ESP (Encapsulating Security Payload): Provee autenticación, confidencialidad e integridad de los mensajes. La función de autenticación se incorporó posteriormente. Puede actuar a través de SNAT usando la encapsulación NATT.


Página 20 de 77

Negociación IKE

IpSec/ESP

SA SA

IpSec/ESP

Paqutes IP seguros

TCP/UDP TCP/UDP


La operativa de IPSec requiere de dos bases de datos:

✔ SPD (Security Policy Database): Informan a el protocolo cuando debe actuar respecto a un paquete IP.

✔ SAD (Security Association Database): Muestra al protocolo como debe crear las asociaciones.

La política de seguridad (SP) esta construida sobre los siguientes aspectos:

✔ Rango de direcciones de origen. Si la dirección de origen del paquete está dentro de este rango, actuar como se indica.

✔ Rango de direcciones de destino. Si la dirección de destino del paquete está dentro de este rango, actúa como se indica.

✔ Protocolo de alto nivel. Si el protocolo del paquete es tcp, udp, icmp, cualquiera.

✔ Política que se aplicará. Que consta de la dirección del canal a crear (entrada o salida) y la acción a tomar (discard, none o ipsec).

4.2.2 Implementaciones sobre GNU/Linux

El núcleo Linux implementa directamente el protocolo IpSec/AH e IpSec/ESP.

A partir del proyecto KAME (http://www.kame.org), se han portado herramientas de gestión para los núcleos 2.6x dentro del proyecto llamado IPSecTools, el cuál contiene:


Página 21 de 77


✔ libipsec: Librería que implementa la gestión de sockets de llaves confiables PF_KEY.

✔ Setkey: Herramienta para manipular las bases de datos SPD y SAD.

✔ Racoon: Servidor de intercambio de claves (IKE).

4.2.3 Práctica StunnelEn el servidor debemos instalar el modulo necesario para que funcione la conexión ppp, que nuestro kernel de Red Hat deberia tener precompilado:

$ modprobe ppp

o en algunos casos:

$ modprobe ppp_generic

Se instala el túnel como “daemon”, esperando conexiones en el puerto 5555 (d 5555), verificando el certificado de su par (v 1), con nivel de depuración 7 (D 7), abriendo un pty local y ejecutando /usr/sbin/pppd (L /usr/sbin/pppd pppd local). La dirección local va a ser, por ejemplo, 192.168.1.1 y la remota 192.168.1.2.

$ stunnel d 5555 v 1 D 7 L /usr/sbin/pppd pppd local 192.168.1.1:192.168.1.2

En ciertas versiones de stunnel, no reconocerá los argumentos del comando stunnel y será necesario crear un archivo de configuración en /etc/stunnel.conf.

Bien creamos el archivo con el siguiente contenido:


Página 22 de 77


client = no

foreground = yes #For debug

CAfile = /usr/share/ssl/CA/cacert.pem

cert = /etc/stunnel/stunnel.pem

key = /etc/stunnel/stunnelkey.pem

[vpn]

accept = 5555

exec = /usr/sbin/pppd

execargs = pppd local 192.168.1.1:192.168.1.2

pty = yes

En resumen, es un servidor de PPP esperando conexiones por el pty en el puerto 5555. Stunnel genera un servicio de TCP wrappers llamado pppd, que hay que habilitar en /etc/hosts.allow, por ejemplo:

pppd: 163.178.18.43

En el servidor, al teclear

$ ifconfig

aparece algo como:

eth0 Link encap:Ethernet HWaddr 00:A0:C9:89:3F:B1

inet addr:10.20.5.38 Bcast:10.20.5.255 Mask:255.255.255.0

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:285069 errors:0 dropped:0 overruns:0 frame:0

TX packets:13650 errors:0 dropped:0 overruns:0 carrier:0


Página 23 de 77


collisions:12208 txqueuelen:100

Interrupt:14 Base address:0xf060

lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0

UP LOOPBACK RUNNING MTU:3924 Metric:1




Algo similar debe aparecer en el cliente. Además, en el cliente se debe ejecutar el siguiente comando:

$ stunnel c r 10.20.5.38:5555 D 7 L /usr/sbin/pppd pppd local noauth

Es decir, se conecta como cliente (c) al servidor 10.20.5.38, puerto 5555 (r 10.20.5.38:5555), nivel de depuración 7 (D 7) y por el pty, también, sin pedir a su par que se autorice (noauth).

Para hacer esto con un fichero de configuración creamos /etc/stunnel/stunnel.conf en el cliente de la siguiente forma:

client = yes

foreground = yes #For debug

[vpn]

conect = 10.20.5.38:5555

exec = /usr/sbin/pppd

execargs = pppd local noauth

pty = yes


Página 24 de 77


Como consecuencia, va a recibir la direccion 192.168.1.2 por medio de la interfaz ppp0 del cliente. Si ahora, en el cliente se da:

$ ifconfig

contesta algo como:

eth0 Link encap:Ethernet HWaddr 00:A0:C9:89:3F:B1

inet addr:10.20.5.38 Bcast:10.20.5.255 Mask:255.255.255.0

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1




Interrupt:14 Base address:0xf060

lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0

UP LOOPBACK RUNNING MTU:3924 Metric:1




ppp0 Link encap:PointtoPoint Protocol

inet addr:192.168.1.2 PtP:192.168.1.1 Mask:255.255.255.255

UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1




Página 25 de 77



En el servidor se va a mostrar algo similar, excepto que las direcciones IP en ppp0 van a estar invertidas.

En resumen, tenemos un túnel seguro asociado a una conexión PPP que a su vez esta asociada (en este caso) a Ethernet por medio de los “pty”. O sea, una especie de PPTP.

4.2.4 Prácticas RacoonPara empezar instalaremos los paquetes necesarios para controlar las funciones IPSec del kernel, para ello ejecutamos lo siguiente:

# aptget install ipsectools racoon

A continuación se describen los dos esquemas más comunes dentro de la implementación de túneles. En el primer esquema se utilizara IPSec para cifrar todos los paquetes que se intercambien entre sí dos equipos (cifrado punto a punto). Para lo anterior utilizaremos el protocolo ESP de IPSec en el modo transporte. Se detallará a continuación la configuración de los dos extremos.

4.2.4.1 Cifrado punto a punto

Con el fin de configurar el extremo (o ambos) de la comunicación cifrada que utilicen el sistema operativo GNU/Linux, es necesario editar el fichero /etc/racoon/racoontool.conf de la siguiente forma:

# Ejemplos:

# peer(%default):

# certificate_type: x509 host.crt host.key


Página 26 de 77


# my_identifier: fqdn bodhisatva.whitebearsolutions.com

# peers_identifier:: fqdn winxp.whitebearsolutions.com

# my_identifier: address 192.168.0.101

# peers_identifier:: address 192.168.0.102

peer(192.168.0.102):

exchange_mode: main

hash_algorithm[0]: sha1

encryption_algorithm[0]: 3des

authentication_method[0]: pre_shared_key

connection(linux):

src_ip: 192.168.0.101

dst_ip: 192.168.0.102

admin_status: enabled

authentication_algorithm: hmac_sha1

encryption_algorithm: 3des

pfs_group: modp1024

El modo de inicio de sesión main (exchange_mode: main) es recomendable frente a la alternativa aggressive debido a la forma insegura en la que se eligen las claves de sesión en este último. El algoritmo 3DES (encryption_algorithm: 3des) se utiliza para la encriptación y SHA1 (authentication_algorithm: hmac_sha1) para la autenticación. El método de autenticación será: clave compartida (authentication_method[0]: pre_shared_key).

A partir de lo anterior, configuramos la clave que utilizarán ambos extremos para reconocerse entre sí. Esto lo hacemos editando el fichero psk.txt, el cuál tiene el siguiente aspecto:


Página 27 de 77


192.168.31.130 La elección de esta clave debe ser especialmente cuidadosa. \\

Una mala elección puede causar que la seguridad no sea efectiva.

La primera cadena de texto corresponde al extremo de la conexión, en este caso se utiliza la dirección IP del extremo (192.168.0.102). El resto de la línea incluyendo los espacios, corresponde a la clave compartida entre ambos extremos.

Una vez realizada la configuración se debe realizar un reinicio de los servicios IPSec para asegurar que los parámetros se encuentren cargados correctamente. para lo anterior ejecutamos:

# /etc/init.d/racoon restart

5 Identidad y criptografía asíncrona

5.1 X.509 y OpenPGP

5.1.1 X.509X.509 es un estándar del UIT (Unión Internacional de Telecomunicaciones – organismo de naciones unidas para la regulación de las telecomunicaciones), definido específicamente para PKI.

X.509 fue publicado oficialmente en 1988 y comenzado conjuntamente con el estándar X.500 y asume un sistema jerárquico estricto de autoridades certificantes (ACs) para emisión de certificados. Esto contrasta con modelos de redes de confianza, como PGP, donde cualquier nodo de la red (no solo las ACs) puede firmar claves públicas, y por ende avalar la validez de certificados de claves de otros.


Página 28 de 77


La sintaxis se define empleando el lenguaje ASN.1 (Abstract Syntax Notation One) y los formatos de codificación más comunes son:

✔ DER (Distinguish Encoding Rules)

✔ PEM (Privacy Enhanced Mail)

La estructura de un certificado digital X.509 v3 es la siguiente:

✔ Certificado

○ Versión

○ Número de serie

○ ID del algoritmo

○ Emisor

○ Validez

■ No antes de

■ No después de

○ Sujeto: En notación DN (Distinguished Name) que a su vez se compone de diversos campos:

■ CN (Common Name)

■ OU (Organizational Unit)

■ O (Organization)

■ C (Country)

○ Información de clave pública del sujeto: Expresada en notación ASN.1

■ Algoritmo de clave pública

■ Clave pública del sujeto

○ Identificador único de emisor (opcional)

○ Identificador único de sujeto (opcional)


Página 29 de 77


○ Extensiones (opcional)

✔ Algoritmo usado para firmar el certificado

✔ Firma digital del certificado: Secuencia añadida por la CA, que contiene tres atributos:

○ Algoritmo de firma

○ Hash de la firma

○ La propia firma

5.1.2 OpenPGPPGP Inc. propone en julio de 1997 a el IETF un estándar llamado OpenPGP. El IETF aceptó la propuesta e inicio el grupo de trabajo OpenPGP.

OpenPGP está actualmente en el Internet Standards Track y se encuentra en desarrollo activo. La especificación actual está en el RFC 4880 de noviembre de 2007 que reemplaza al RFC 2440. Muchos clientes de correo proveen compatibilidad con OpenPGP y los mecanismos de seguridad descritos en el RFC3156.

La Free Software Foundation a desarrollado su propia implementación de OpenPGP llamada GNU Privacy Guard (GNUPG).

5.2 Estándares PKCSPKCS se refiere a un grupo de estándares de criptografía de clave pública concebidos y publicados por los laboratorios de RSA en California. A RSA Security se le asignaron los derechos de licenciamiento para la patente de algoritmo de clave asimétrica RSA y adquirió los derechos de licenciamiento para muchas otras patentes de claves.

✔ PKCS#1: Estándar criptográfico RSA definido en el RFC 3447. Define el formato del cifrado RSA.


Página 30 de 77


✔ PKCS#2: Actualmente obsoleto, definía el cifrado RSA de resúmenes de mensajes, pero fue absorbido por el PKCS#1.

✔ PKCS#3: Estándar de intercambio de claves DiffieHellman.

✔ PKCS#4: Actualmente obsoleto, definía la sintaxis de la clave RSA, pero fue absorbido también por el PKCS#1.

✔ PKCS#5: Estándar de cifrado basado en contraseñas definido en el RFC 2898 y PBKDF2.

✔ PKCS#6: Estándar de sintaxis de certificados extendidos que define extensiones a la antigua especificación de certificados X.509 versión 1. La versión 3 del mismo lo dejó obsoleto.

✔ PKCS#7: Estándar sobre la sintaxis del mensaje criptográfico definido en el RFC 2315. Usado para firmar y/o cifrar mensajes en PKI. También usado para la diseminación de certificados. Fue la base para el estándar S/MIME, ahora basado en la RFC 3852, una actualización del estándar [CMS Cryptographic Message Syntax, utilizado para firmar digitalmente, obtener el digest, autenticar, o cifrar arbitrariamente el contenido de un mensaje.

✔ PKCS#8: Estándar sobre la sintaxis de la información de clave privada.

✔ PKCS#9: Tipos de atributos seleccionados.

✔ PKCS#10: Estándar de solicitud de certificación especificado en el RFC 2986. Formato de los mensajes enviados a una Autoridad de certificación para solicitar la certificación de una clave pública.

✔ PKCS#11: Es una interfaz de dispositivo criptográfico (“Cryptographic Token


Página 31 de 77


Interface” o cryptoki) que define un API genérico de acceso a dispositivos criptográficos.

✔ PKCS#12: Estándar de sintaxis de intercambio de información personal que define un formato de fichero usado comúnmente para almacenar claves privadas con su certificado de clave pública protegido mediante clave simétrica.

✔ PKCS#13: Estándar de criptografía de curva elíptica. Se encuentra actualmente en desarrollo.

✔ PKCS#14: Generación de número pseudoaleatorios. Se encuentra actualmente en desarrollo.

✔ PKCS#15: Estándar de formato de información de dispositivo criptográfico que define un estándar que permite a los usuarios de dispositivo criptográficos identificarse con aplicaciones independientemente de la implementación del PKCS#11 (crytoki) u otro API.

5.3 Extensiones de ficherosLas extensiones de archivo de certificados X.509 son:

✔ .CER: Certificado codificado en CER, algunas veces es una secuencia de certificados

✔ .DER: Certificado codificado en DER

✔ .PEM: Certificado codificado en Base64, encerrado entre “BEGIN CERTIFICATE” y “END CERTIFICATE”

✔ .P7B: Ver .p7c

✔ .P7C: Estructura PKCS#7 SignedData sin datos, solo certificado o CRL

✔ .PFX: Ver .p12


Página 32 de 77


✔ .P12: PKCS#12, fichero protegido con clave que puede contener certificado (público) y claves privadas

6 Infraestructura de clave públicaUna infraestructura de clave pública es una combinación de hardware y software, políticas y procedimientos de seguridad que permiten la ejecución con garantías de operaciones criptográficas como el cifrado, la firma digital o el no repudio de transacciones electrónicas.

El término PKI se utiliza para referirse tanto a la autoridad de certificación y al resto de componentes, como para referirse, de manera más amplia y a veces confusa, al uso de algoritmos de clave pública en comunicaciones electrónicas.

Los componentes de una entidad certificadora son:

✔ Autoridad de certificación (CA Certificate Authority): Se encarga de emitir y revocar los certificados.

✔ Autoridad de registro (RA Registration Authority): Responsable de verificar el enlace entre los certificado y la identidad de los titulares.

✔ Repositorios: Repositorio de certificados y listas de revocación de certificados que han dejado de ser válidos antes de la fecha de caducidad (CRL Certificate Revocation List)

✔ Autoridad de validación (VA Validation Authority): Encargada de comprobar los certificados digitales.

✔ Autoridad de sellado de tiempo (TSA TimeStamp Authority): Firma los documentos digitales con el fin de probar su existencia antes de una determinada fecha.


Página 33 de 77


6.1 Autoridad de certificaciónUna autoridad de certificación o certificadora es una entidad de confianza, responsable de emitir y revocar los certificados digitales o certificados. La Autoridad de Certificación, por sí misma o mediante la intervención de una Autoridad de Registro, verifica la identidad del solicitante de un certificado antes de su expedición o, en caso de certificados expedidos con la condición de revocados, elimina la revocación de los certificados al comprobar dicha identidad. Los certificados son documentos que recogen ciertos datos de su titular y su clave pública y están firmados electrónicamente por la Autoridad de Certificación utilizando su clave privada.

Las CA disponen de sus propios certificados públicos, cuyas claves privadas asociadas son empleadas por las CA para firmar los certificados que emiten. Un certificado de CA puede estar autofirmado cuando no hay ninguna CA de rango superior que lo firme. Este es el caso de los certificados de CA raíz, el elemento inicial de cualquier jerarquía de certificación.

Una de las formas por las que se establece la confianza en una CA para un usuario consiste en la "instalación" en el ordenador del usuario (tercero que confía) del certificado autofirmado de la CA raíz de la jerarquía en la que se desea confiar.

Finalmente, las CA también se encargan de la gestión de los certificados firmados. Esto incluye las tareas de revocación de certificados que puede instar el titular del certificado o cualquier tercero con interés legítimo ante la CA por email, teléfono o intervención presencial. La lista denominada CRL (Certificate Revocation List) contiene los certificados que entran en esta categoría, por lo que es responsabilidad de la CA publicarla y actualizarla debidamente. Por otra parte, otra tarea que debe realizar una CA es la gestión asociada a la renovación de certificados por caducidad o revocación.

Si la CA emite muchos certificados, corre el riesgo de que sus CRL sean de gran tamaño, lo que hace poco práctica su descarga para los terceros que confían. Por ese motivo desarrollan mecanismos alternativos de consulta de validez de los certificados, como servidores basados en los protocolos OCSP y SCVP.


Página 34 de 77


6.1.1 NormativaLa Directiva 93/1999 ha establecido un marco común aplicable a todos los países de la Unión Europea por el que el nivel de exigencia que supone la normativa firma electrónica implica que los Prestadores de Servicios de Certificación que emiten certificados cualificados son merecedores de confianza por cualquier tercero que confía y sus certificados otorgan a la firma electrónica avanzada a la que acompañan el mismo valor que tiene la “firma manuscrita”.

La Ley 59/2003 de Firma Electrónica ha derogado el Real Decreto Ley 14/1999, de 17 de septiembre, sobre firma electrónica haciendo más efectiva la actividad de certificación en España.

6.2 Clases de certificadosUn Certificado Digital es un documento digital mediante el cual un tercero confiable (una autoridad de certificación) garantiza la vinculación entre la identidad de un sujeto o entidad y su clave pública.

Si bien existen variados formatos para certificados digitales, los más comúnmente empleados se rigen por el estándar UITT X.509.

Un certificado emitido por una entidad de certificación autorizada, además de estar firmado digitalmente por ésta, debe contener por lo menos lo siguiente:

✔ Nombre, dirección y domicilio del suscriptor.

✔ Identificación del suscriptor nombrado en el certificado.

✔ El nombre, la dirección y el lugar donde realiza actividades la entidad de certificación.

✔ La clave pública del usuario.

✔ La metodología para verificar la firma digital del suscriptor impuesta en el mensaje de datos.


Página 35 de 77


✔ El número de serie del certificado.

✔ Fecha de emisión y expiración del certificado.

6.3 Listas de revocaciónEn la operación de algunos sistemas criptográficos, usualmente los de infraestructura de clave pública (PKI), una CRL es una lista de certificados (más concretamente sus números de serie) que han sido revocados, ya no son válidos y en los que no debe confiar ningún usuario del sistema.

Cuando una autoridad de certificación emite un certificado digital, lo hace con un periodo máximo de validez que oscila entre uno y cinco años. El objetivo de este periodo de caducidad es obligar a la renovación del certificado para adaptarlo a los cambios tecnológicos. Así se disminuye el riesgo de que el certificado quede comprometido por un avance tecnológico. La fecha de caducidad viene indicada en el propio certificado digital.

A pesar de lo anterior, existen otras situaciones que pueden invalidar el certificado digital aún cuando no ha caducado, de manera inesperada:

✔ El usuario del certificado cree que su clave privada ha sido robada.

✔ Desaparece la condición por la que el certificado fue expedido. Por ejemplo, el cambio de apoderado de una entidad jurídica.

✔ El certificado contiene información errónea o información que ha cambiado. Por ejemplo, una errata en los apellidos.

✔ Una orden judicial.

✔ Otras razones

Por tanto, debe existir algún mecanismo para comprobar la validez de un certificado antes de su caducidad.

Cuando un tercero desea comprobar la validez de un certificado debe descargar una CRL actualizada desde los servidores de la misma autoridad de


Página 36 de 77


certificación que emitió el certificado en cuestión. A continuación comprueba la autenticidad de la lista gracias a la firma digital de la autoridad de certificación. Después debe comprobar que el número de serie del certificado cuestionado está en la lista. En caso afirmativo, no se debe aceptar el certificado como válido.

6.4 Prácticas OpenSSL

Por defecto podemos ubicar el almacén de certificados y el fichero de configuración en el directorio que consideremos oportuno, para el presente ejemplo la ubicación básica será /etc/ssl.

Una vez elegido el directorio ejecutamos lo siguiente:

$ cd $DIRECTORIO

$ echo '100001' > serial

$ touch index.txt

Donde serial será el primer número de serie para la generación de certificados, es decir, el primer certificado se generará con este número, el segundo se generará con el número siguiente a este serial y así sucesivamente.

index.txt es el archivo que utiliza OpenSSL como base de datos, en este archivo es donde veremos una referencia a los certificados creados.

Después deberemos editar el archivo openssl.cnf para ajustar el funcionamiento de OpenSSL a nuestras preferencias, para ello debemos mostrar especial atención a la seccion [ CA_default ] donde encontraremos la información de la estructura de directorios que usa OpenSSL. También podemos observar otras opciones como el tiempo de vida del certificado o la sección de policy donde podremos editar la información que llevaran los certificados (si lo dejamos en los valores por defecto, OpenSSL nos preguntará dichos valores a la hora de crear los certificados).


Página 37 de 77


6.4.1 Creación del certificado de CA

En primer lugar es necesario crear el certificado de CA, de la siguiente forma:

$ openssl req x509 newkey rsa:1024 keyout /etc/ssl/private/cakey.pem

keyform PEM out /etc/ssl/ca/cacert.pem outform PEM

Si se prefiere almacenar los certificados en binario DER en lugar de en formato PEM Base64, basta con especificarlo en el atributo outform o keyform del comando anterior.

6.4.2 Creación y firma de un certificado certificado

El certificado de solicitud de firma (Certificate Signing Request) es el paso previo en la creación de un certificado de servidor o usuario, este fichero contiene todos los atributos X.509 del certificado definitivo, con la diferencia que carece de la firma de la entidad certificadora. Para crear este tipo de certificado se ejecuta:

$ openssl req new newkey rsa:1024 keyout /etc/ssl/private/hostkey.pem

nodes out /etc/ssl/certs/hostreq.pem

A continuación la aplicación preguntará por una serie de atributos, los cuales constituyen la estructura de atributos X.509 del certificado. El campo CN (Common Name) debe corresponder al nombre DNS de la máquina o servidor para el cuál se emite el certificado. En caso de un usuario el campo CN debe corresponder al nombre completo.

Una vez se cuenta con el certificado de solicitud de firma, este puede ser firmado


Página 38 de 77


por la entidad certificadora creando así un fichero con el certificado definitivo. Este proceso puede realizarse mediante la siguiente orden:

$ openssl ca in /etc/ssl/certs/hostreq.pem out /etc/ssl/certs/hostcert.pem notext

6.4.3 Mostrando el contenido de un certificado

Un certificado digital puede ser almacenado en muchos formatos. Los dos formatos mas comunes son PEM (Privacy Enhanced Mail) y DER (Definite Encoding Rules). OpenSSL puede mostrar el contenido de ambos formatos usando comandos x509. El siguiente ejemplo mostrará el contenido del certificado cert.crt.pem (PEMencoded):

$ openssl x509 in cert.crt.pem inform PEM text noout

OpenSSL también permite mostrar atributos del certificado individualmente:

$ openssl x509 in cert.crt.der inform DER noout enddate

El comando anterior mostrará la fecha de caducidad del certificado cert.crt.der.

6.4.4 Exportar los certificados a otros formatos

Normalmente muchas aplicaciones necesitan usar la llave privada de los certificados creados. la forma más conveniente para cargar esa información es poner todo en un fichero de tipo PKCS#12, de la siguiente forma:

$ openssl pkcs12 export inkey /etc/ssl/private/hostkey.pem


Página 39 de 77


in /etc/ssl/certs/hostcert.pem name “Nombre”

certfile /etc/ssl/cacert.pem caname “Nombre_de_CA”

out /etc/ssl/certs/hostcert.p12

Los certificados se almacenan en modo texto en formato base64, si se desea crear un fichero en formato binario (DER) basta con ejecutar lo siguiente:

$ openssl x509 outform DER in /etc/ssl/certs/ out /etc/ssl/certs/hostcert.der

6.4.5 Revocación de certificados

Cuando se desea revocar un certificado, puede ejecutarse el siguiente comando para conseguirlo:

$ openssl ca revoke /etc/ssl/certs/hostcer.pem

Para hacer pública la lista de revocación de certificados, debe generarse un fichero CRL el cuál contiene la información necesaria relativa a la lista de revocación. Este fichero puede generarse con el siguiente comando:

$ openssl ca gencrl out /etc/ssl/ca/ca.crl

6.4.6 Cifrado asimétrico Los cifrados asimétricos mediante el algoritmo RSA se pueden realizar con el comando rsautl de openssl. Es muy sencillo de utilizar si disponemos de un certificado que incluya tanto la clave pública como la clave privada,es decir el típico archivo que se obtiene al exportar certificados desde el navegador. En los siguientes ejemplos supondremos que tenemos el certificado en formato PEM en el archivo cert.pem.


Página 40 de 77


PARA CIFRAR:

$ openssl rsautl in texto.txt out texto.rsa inkey cert.pem certin encrypt

PARA DESCIFRAR:

$ openssl rsautl in texto.rsa out texto_original.txt inkey cert.pem certin decrypt

En cada caso se utiliza la par te necesaria del certificado, es decir la clave pública para cifrar y la clave privada para descifrar. Alternativamente se pueden proporcionar archivos tipo PEM, que según el caso sólo contengan la par te pública o la parte privada, entonces se omite la opción certin.

A diferencia del cifrado simétrico, el comando rsautl no admite textos largos, tan sólo de unos 100 caracteres. Esto es debido a que normalmente no se cifran grandes documentos mediante algoritmos asimétricos.

Como ya se ha comentado los documentos se cifran con algoritmos simétricos sólo la clave secreta se cifra con algoritmos asimétricos. Una manera directa para cifrar un documento real es utilizar el comando smime que realiza el cifrado simétrico mediante des, 3DES, RC2 o AES y luego protege la clave secreta utilizando la clave pública del destinatario:

$ openssl smime encrypt aes128 in bigfile.doc out bigfile.msg user.pem

6.4.7 Integración con directorios LDAP

Es posible utilizar el directorio LDAP para almacenar y consultar los certificados de usuario, para esto es imprescindible que el servidor soporte objectclasses que


Página 41 de 77


permitan almacenar los certificados. En particular el objectclass certificationAuthority permite utilizar los atributos: authorityRevocationList, certificateRevocationList y cACertificate.

El objectclass inetOrgPerson soporta el atributo binario userCertificate. Los certificados de usuario deben publicarse a través de ficheros en formato binario DER (Distingushed Encoding Rules).

Para importar el certificado de CA al directorio LDAP basta con crear un fichero LDIF con los siguientes atributos:

dn: cn=WhitebearsolutionsCA,dc=whitebearsolutions,dc=comobjectClass: topobjectClass: applicationProcessobjectClass: certificationAuthoritycn: WhitebearsolutionsCAcACertificate;binary:< file:///etc/ssl/ca/ca.crtcertificateRevocationList;binary:< file:///etc/ssl/ca/ca.crlauthorityRevocationList;binary:

Para importar un certificado de usuario también es necesario crear un fichero LDIF con el atributo userCertificate, el cuál debe apuntar al fichero binario DER que contiene el certificado.

dn: cn=user,ou=people,dc=whitebearsolutions,dc=comchangetype: modifyadd: usercertificateuserCertificate;binary:< file:///ruta/a/certificado.der

Si se introducen caracteres con codificaciones diferentes a \emph{UTF8}, deben convertirse en \emph{Unicode} o de lo contrario el formato será rechazado por la aplicación de actualización y el directorio LDAP. Para recodificar un fichero LDIF puede utilizarse la siguiente aplicación:

#include <errno.h>#include <stdio.h>


Página 42 de 77


int main (int argc, char** argv){ register int c; while ((c = getchar()) != EOF) { if ((c & 0x80) == 0) { putchar (c); } else { putchar (0xC0 | (0x03 & (c >> 6))); putchar (0x80 | (0x3F & c)); } } if ( ! feof (stdin)) { errno = ferror (stdin); perror (argv[0]); } return 0;}

Para compilar el código anterior basta con ubicarlo en un fichero con extensión (*.c) y ejecutar el siguiente comando:

$ gcc o utf8 utf8.c

Obviamente después de esto se debe ejecutar el comando de actualización ldapmodify de la siguiente forma:

$ ldapmodify x W D "cn=Manager,ou=people, \\ dc=whitebearsolutions,dc=com" f certificado.ldif

Para extraer los certificados del servidor de directorio LDAP puede utilizarse una aplicación que posea esta caracterísitica o simplemente ejecutar un shell script como el siguiente:

#!/bin/sh# Author: Ricardo Lorenzo# WhiteBearSolutions#


Página 43 de 77


if [[ $1 != *@*.* || $# != 1 ]] ; then echo "Uso: script <[email protected]>" exit 0fiRESULT=$(ldapsearch x LLL mail=$1 userCertificate)if [ z "$RESULT" ]; then exit 0fiRESULT=${RESULT#*binary:: *}RESULT=${RESULT//\ }RESULT=$(echo "$RESULT" | tr d "\n")NUM=0echo "BEGIN CERTIFICATE"while [ $NUM le "${#RESULT}" ] ; do echo "${RESULT:NUM:64}" NUM=$(($NUM+64))doneecho "END CERTIFICATE"

Este script extrae el certificado de la entrada de directorio que posea la dirección de correo electrónico que se pasa como parámetro. También es posible utilizar un CGI para extraer y consultar los certificados, el código de dicho CGI puede ser como el siguiente:

#!/bin/sh# Author: Ricardo Lorenzo# WhiteBearSolutions 20032005#HOST=”192.168.0.10"PROTOCOL="ldap"BASE_DN="dc=whitebearsolutions,dc=com"RESULT=""TYPE="cert"MAIL=""

if [[ $1 == *\&* ]] ; then TYPE=${1#*\&*}


Página 44 de 77


MAIL=${1%\\\&*}else MAIL=$1fi

# To lowercase mailMAIL=$(echo $MAIL | tr AZ az)

### BEGIN FUNCTIONS ###parse_cert(){ RESULT=${RESULT#*binary:: *} RESULT=${RESULT//\ } RESULT=$(echo "$RESULT" | tr d "\n") NUM=0 echo "BEGIN CERTIFICATE" while [ $NUM le "${#RESULT}" ] ; do echo "${RESULT:NUM:64}" NUM=$(($NUM+64)) done echo "END CERTIFICATE"}get_result(){ if [[ $MAIL == "ca" ]] ; then RESULT=$(ldapsearch H "$PROTOCOL://$HOST" b $BASE_DN x LLL cACertificate=*) else RESULT=$(ldapsearch H "$PROTOCOL://$HOST" b $BASE_DN x LLL mail=$MAIL userCertificate) fi}print_not_found(){ echo "Contenttype: text/html" echo "" echo "<html><head><title>WhiteBearSolutions Directory Security Tool</title></head>" echo "<body>"


Página 45 de 77


echo "<br/><br/>" echo "<table align=\"center\" valign=\"top\" border=\"0\">" echo "<tr><td align=\"center\">" echo "<h2>WHITEBEARSOLUTIONS</h2>" echo "<b>Directory Security Tool</b>" echo "</td></tr>" echo "<tr><td> </td></tr>" echo "<tr><td align=\"center\">" echo "El certificado de la cuenta [<i>$MAIL</i>] <br/>no se encuentra en el servidor de directorio." echo "</td></tr></table>" echo “</body></html>”}print_syntax_error(){ echo “Contenttype: text/html” echo “” echo “<html><head><title>WhiteBearSolutions Directory Security Tool</title></head>” echo “<body>” echo “<br/><br/>" echo “<table align=\"center\" valign=\"top\" border=\"0\">" echo “<tr><td align=\"center\">" echo “<h2>WHITEBEARSOLUTIONS</h2>" echo “<b>Directory Security Tool</b>" echo “</td></tr>” echo “<tr><td> </td></tr>” echo “<tr><td align=\”center\”>” echo “Error: <i>Parámetros incorrectos.</i>” echo "</td></tr>" echo "<tr><td> </td></tr>" echo "<tr><td align=\"center\">" echo "Sintaxis: <i>/cgibin/[ca | [email protected]][& text | cert ]</i>" echo "</td></tr></table>" echo "</body></html>"}### END FUNCTIONS ###


Página 46 de 77


if [[ $MAIL != "ca" && $MAIL != *@*.* ]] ; then print_syntax_error exit 0fi

case $TYPE in "cert" ) get_result if [ z "$RESULT" ] ; then print_not_found exit 0 fi if [[ $MAIL == "ca" ]] ; then echo "Contenttype: application/xx509cacertificate; name=\"whitebearsolutionsca.crt\"" echo "ContentDescription: CA Digital Certificate" echo "ContentDisposition: attachment; filename=\"whitebearsolutionsca.crt\"" else echo "Contenttype: application/xx509emailcert; name=\"${MAIL%\@*}.crt\"" echo "ContentDescription: User Digital Certificate" echo "ContentDisposition: attachment; filename=\"${MAIL%\@*}.crt\"" fi echo "" parse_cert ;; "install" ) if [[ $MAIL == "ca" ]] ; then echo "Contenttype: text/html" echo "" echo "<html><head><title>WhiteBearSolutions Directory Security Tool</title></head>" echo "<body>" echo "<br/><br/>" echo "<table align=\"center\" valign=\"top\" border=\"0\">" echo "<tr><td align=\"center\">" echo "<h2>WHITEBEARSOLUTIONS</h2>" echo "<b>Directory Security Tool</b>"


Página 47 de 77


echo "</td></tr>" echo "<tr><td> </td></tr>" echo "<tr><td align=\"center\">" echo "El certificado de CA no se puede instalar automáticamente." echo "</td></tr></table>" echo "</body></html>" exit 0 else get_result if [ z "$RESULT" ] ; then print_not_found exit 0 fi echo "Contenttype: application/xx509emailcert" echo "" parse_cert fi ;; “text” ) get_result; if [ z "$RESULT" ] ; then print_not_found exit 0 fi echo "Contenttype: text/plain" echo "" parse_cert ;; * ) print_syntax_error ;;esac


Página 48 de 77


7 Tarjetas criptográficas (smart cards)

7.1 DefiniciónUna tarjeta inteligente (smart card), o tarjeta con circuito integrado (TCI), es cualquier tarjeta del tamaño de un bolsillo con circuitos integrados que permiten la ejecución de cierta lógica programada. Aunque existe un diverso rango de aplicaciones, hay dos categorías principales de TCI. Las Tarjetas de memoria contienen sólo componentes de memoria no volátil y posiblemente alguna lógica de seguridad.

Según las capacidades de su chip, las tarjetas más habituales son:

✔ Memoria: tarjetas que únicamente son un contenedor de ficheros pero que no albergan aplicaciones ejecutables. Por ejemplo, MIFARE. Éstas se usan generalmente en aplicaciones de identificación y control de acceso sin altos requisitos de seguridad.

✔ Microprocesadas: tarjetas con una estructura análoga a la de un ordenador (procesador, memoria volátil, memoria persistente). Éstas albergan ficheros y aplicaciones y suelen usarse para identificación y pago con monederos electrónicos.

✔ Criptográficas: tarjetas microprocesadas avanzadas en las que hay módulos hardware para la ejecución de algoritmos usados en cifrados y firmas digitales. En estas tarjetas se puede almacenar de forma segura un certificado digital (y su clave privada) y firmar documentos o autenticarse con la tarjeta sin que el certificado salga de la tarjeta (sin que se instale en el almacén de certificados de un navegador web, por ejemplo) ya que es el procesador de la propia tarjeta el que realiza la firma. Un ejemplo de estas tarjetas son las emitidas por la Fábrica Nacional de Moneda y Timbre (FNMT) española para la firma digital (véase CeresFNMT).

Según los tipos de tarjetas y la estructura de su sistema operativo:


Página 49 de 77


✔ Tarjetas de memoria: Tarjetas que únicamente son un contenedor de ficheros pero que no albergan aplicaciones ejecutables. Disponen de un sistema operativo limitado con una serie de comandos básicos de lectura y escritura de las distintas secciones de memoria y pueden tener capacidades de seguridad para proteger el acceso a determinadas zonas de memoria.

✔ Basadas en sistemas de ficheros, aplicaciones y comandos: Estas tarjetas disponen del equivalente a un sistema de ficheros compatible con el estándar ISO/IEC 7816 parte 4 y un sistema operativo en el que se incrustan una o más aplicaciones (durante el proceso de fabricación) que exponen una serie de comandos que se pueden invocar a través de APIs de programación.

✔ Java Cards: Una Java Card es una tarjeta capaz de ejecutar miniaplicaciones Java. En este tipo de tarjetas el sistema operativo es una pequeña máquina virtual Java (JVM) y en ellas se pueden cargar dinámicamente aplicaciones desarrolladas específicamente para este entorno.

7.2 PCSD, OpenSC y generación de tarjetas smart card

7.2.1 PC/SCPC/SC (Personal Computer/Smart Card) es un conjunto de especificaciones para la integración de tarjetas inteligentes en ordenadores personales. En particular se define un API de programación que permite a los desarrolladores trabajar de forma uniforme con lectores de tarjetas de distintos fabricantes (que cumplan con la especificación).

El API de PC/SC está incorporada en sistemas Microsoft Windows 200x/XP y disponible también Microsoft Windows NT/9x. También hay una implementación libre (de código abierto) llamada PC/SC Lite (proyecto MUSCLE) para sistemas


Página 50 de 77


operativos GNU Linux.

7.2.2 OpenSCEl proyecto OpenSC ofrece un componente software para el uso de SmartCard, ofreciendo el código necesario para interactuar con una tarjeta. Este proyecto ofrece un módulo que implementa el estándar PKCS#11 que puede ser utilizado por otras aplicaciones. OpenSC también implementa el estándar PKCS#15 para el formato de las tarjetas. Este proyecto también incluye código de emulación que es compatible con un gran número de tarjetas nacionales de identificación.

7.3 Autenticación con tarjetas y PAMEl proyecto OpenSC ofrece un módulo PAM que permite la autenticación de usuarios en base a certificados X.509. El certificado y su clave privada deben ser accedidos por el módulo PKCS#11 apropiado. Para la verificación de usuarios los certificados de CA y CRL's deben ser localmente accesibles.

7.4 Práctica PCSDd y OpenSC

Antes de empezar es necesario instalar las librerias PCSCLite y USB de desarrollo si lo que se desea es compilar el driver CCID (genérico para dispositivos USB) para poder acceder a las smart cards. Esta librería de desarrollo se instala con el siguiente comando:

# aptget install libpcsclitedev libusbdev

Para compilar el driver CCID basta con descargarlo de http://pcsclite.alioth.debian.org/ccid.html y ejecutar lo siguiente:

$ tar xvfz ccid0.9.3.tar.gz

$ cd ccid0.9.3/

$ ./configure


Página 51 de 77


$ make

$ su

# make install

En cualquier caso también puede instalarse en Debian utilizando lo siguiente:

# aptget install libccid

7.4.1 Dispositivo C3PO LTC31Este dispositivo lector de PC/SC de la empresa C3PO S.L (http://www.c3po.es) permite leer tarjetas Siemens HiPathSicurity CardOS y tarjetas criptograficas CERES de la Fábrica Nacional de Moneda y Timbre a través del proyecto OpenSCCERES (http://openscceres.softwarelibre.org/).

Este dispositivo no está soportado por el driver genérico CCID, como reza en su página web http://pcsclite.alioth.debian.org/ccid.html ya que funciona bien bajo Linux 2.4.x pero da un fallo sobre Linux 2.6.x. El fabricante está trabajando en una solución, y existe un parche para el núcleo 2.6.x el cuál está disponible en http://pcsclite.alioth.debian.org/ltc3xusb\_on\_kernel\_2\_6\_11.patch.txt.

Básicamente este parche lo que hace es comentar dos líneas a partir de la línea 1090 del fichero drivers/usb/host/uhcihcd.c de los fuentes del núcleo, como se muestra a continuación:

{

int ret;

/* Can't have lowspeed bulk transfers */

/* if (urb>dev>speed == USB_SPEED_LOW)

return EINVAL;


Página 52 de 77


*/

ret = uhci_submit_common(uhci, urb, eurb, uhci>skel_bulk_qh);

if (ret == EINPROGRESS)

uhci_inc_fsbr(uhci, urb);

7.4.2 Software de verificación y gestión del dispositivoPara un sencillo acceso a las tarjetas puede instalarse un sistema middleware y algunas herramientas para acceder al dispositivo lector, el sistema middleware necesita del proyecto PCSCLite para la gestión de las smartcard y los dispositivos, para instalar PCSCLite utilizamos lo siguiente:

# aptget install libpcsclite1

El sistema middleware PCSCD se instala como demonio y carga automáticamente los drivers de los dispositivos, las herramientas permiten verificar y realizar operaciones contra el dispositivo y las tarjetas smart card. Estos dos paquetes se instalan con el comando:

# aptget install pcscd pcsctools

El demonio PCSCD se arranca automáticamente al instalar el paquete para verificar que reconoce el dispositivo basta con conectarlo a través de USB y verificar la salida de mensajes (dmesg o tail f /var/log/messages). Si todo va bien detectará el dispositivo y mostrará una salida como esta:

kernel: usb 11: new low speed USB device using uhci_hcd and address 5

pcscd: hotplug_libusb.c:371:HPAddHotPluggable() \\

Adding USB device: 001:005

pcscd: readerfactory.c:1066:RFInitializeReader() \\


Página 53 de 77


Attempting startup of LTC31 00 00.

pcscd: readerfactory.c:940:RFBindFunctions() \\

Loading IFD Handler 3.0

pcscd: ifdhandler.c:998:init_driver LogLevel: 0x0003

pcscd: ifdhandler.c:1009:init_driver DriverOptions: 0x0000

pcscd: ifdhandler.c:67:IFDHCreateChannelByName \\

lun: 0, device: usb:0783/0003:libusb:001:005

pcscd: ccid_usb.c:225:OpenUSBByName Manufacturer: \\

Ludovic Rousseau ([email protected])

pcscd: ccid_usb.c:235:OpenUSBByName ProductString: \\

Generic CCID reader v0.9.3

pcscd: ccid_usb.c:241:OpenUSBByName Copyright: This \\

driver is protected by terms of the GNU General \\

Public License version 2, or (at your option) \\

any later version.

pcscd: ccid_usb.c:376:OpenUSBByName Found \\

Vendor/Product: 0783/0003 (LTC31)

pcscd: ccid_usb.c:378:OpenUSBByName Using USB \\

bus/device: 001/005

Para verificar la operativa del dispositivo podemos utilizar la herramienta pcsc_scan la cuál analiza todos los lectores conectados y muestra las operaciones que se realizan con el lector, como inserciones o extracciones de tarjeta. Para ejecutar esta herramienta basta con escribir:

$ pcsc_scan


Página 54 de 77


7.4.3 Software de gestión de las tarjetasPara la gestión de las tarjetas una vez instalado correctamente el dispositivo, puede utilizarse una aplicación como OpenSC, la cuál puede ser instalada de forma muy sencilla en un sistema Debian:

# aptget install opensc

También es posible instalar el módulo PAM para realizar las autenticaciones automáticas en consola, este módulo también es un paquete de Debian el cuál puede instalarse mediante el comando:

# aptget install libpamopensc

Una vez instalado y antes de describir las operaciones básicas, podemos verificar y comprobar el acceso y lectura de las tarjetas a través de comandos simples. Para conocer cuantos y cuales son los lectores conectados al sistema, ejecutamos:

$ opensctool listreaders

De la misma forma para conocer los drivers de tarjetas que se encuentran disponibles, podemos escribir:

$ opensctool listdrivers

La operación con tarjetas es relativamente sencilla utilizando las herramientas de OpenSC. De esta forma si queremos borrar la información de una tarjeta ejecutamos:

$ pkcs15init r $NUMERO_DEL_READER erasecard


Página 55 de 77


o bien,

$ pkcs15init E

En el comando anterior la variable $NUMERO_DEL_READER se refiere al número indicativo del lector de tarjetas, el cuál se muestra usando opensctool listreaders. Para crear una estructura básica en la tarjeta, ejecutamos lo siguiente:

$ pkcs15init nosopin createpkcs15 profile pkcs15

$ pkcs15init authid 1 storepin pin "1234" puk "123456" label "PIN"

$ pkcs15init authid 1 pin "1234" keyusage sign,decrypt storeprivatekey newkey.pem

$ pkcs15init authid 1 pin "1234" storecertificate newcert.pem

8 Autoridades de Certificación y Listas de RevocaciónRCM como prestador de Servicios de Certificación. CERES.

8.1 7.1 La Fábrica Nacional de Moneda y Timbre como autoridad de certificación.La Fábrica Nacional de Moneda y Timbre Real Casa de la Moneda (FNMTRCM) es una entidad pública empresarial de las previstas en la Ley 6/1997, de 14 de abril, de Organización y Funcionamiento de la Administración General del Estado, que, como organismo público, tiene personalidad jurídica pública diferenciada, patrimonio y tesorería propios y autonomía de gestión en los términos previstos en dicha Ley.

Está adscrita al Ministerio de Economía y Hacienda, el cual, a través de la Subsecretaría de Economía y Hacienda, ejercerá respecto de ella la dirección estratégica y el control de eficacia en los términos previstos en la citada Ley.


Página 56 de 77


Sus funciones son:

✔ La acuñación de monedas de todas clases, de acuerdo con la legislación aplicable.

✔ La elaboración de cospeles y la acuñación de medallas y trabajos análogos para el Estado o particulares.

✔ La impresión de billetes de banco, de conformidad con su legislación reguladora y en los términos que se acuerde con el Banco de España o banco emisor correspondiente.

✔ La elaboración de los documentos por los que se hacen efectivos cualesquiera tributos o precios públicos, billetes, impresos y listas de Lotería Nacional, así como cualquier documento relativo a otros juegos que le sean encomendados por las Administraciones públicas o sus organismos públicos, vinculados o dependientes.

✔ La elaboración de documentos de valor o de seguridad que le sean encargados por cualquier Administración pública o sus organismos públicos, vinculados o dependientes.

✔ La estampación de toda clase de documentos, sellos, signos o efectos postales y de franqueo, de acuerdo con lo establecido por la legislación aplicable, para el Estado o, en su caso, para organismos o entidades públicas o privadas.

✔ La prestación, en el ámbito de las Administraciones públicas y sus organismos públicos, vinculados o dependientes, de servicios de seguridad, técnicos y administrativos, en las comunicaciones a través de técnicas y medios electrónicos, informáticos y telemáticos (EIT), así como la expedición, fabricación y suministro de los títulos o certificados de usuario o soportes en tarjeta necesarios a tal fin, de acuerdo con lo establecido en la


Página 57 de 77


Ley 66/1997, de 30 de diciembre, y en su normativa de desarrollo o, en su caso, en los términos que establezcan las disposiciones legales correspondientes. En el ejercicio de las facultades derivadas de este apartado, la Fábrica Nacional de Moneda y TimbreReal Casa de la Moneda quedará sometida a lo dispuesto en el artículo 2.2, y demás de aplicación, de la Ley de Régimen Jurídico de las Administraciones Públicas y del Procedimiento Administrativo Común, así como a la normativa que se cita en este apartado, sin perjuicio del resto de supuestos en que resulte de aplicación, de acuerdo con el artículo 53.2 de la Ley 6/1997, de 14 de abril.

✔ La realización de actividades o prestación de servicios relacionados con los ramos propios de la entidad a que se refieren los apartados anteriores, para personas o entidades públicas o privadas, tanto nacionales como extranjeras. En la prestación de servicios electrónicos, informáticos o telemáticos, así como en la expedición, fabricación y suministro de títulos o certificados de usuario y soportes o tarjetas destinados al ámbito privado, la entidad actuará a todos los efectos en régimen de derecho privado.

✔ Cualquier otro que se le atribuya por disposición legal o reglamentaria.

8.2 7.2 Proyecto CERESEl denominado proyecto CERES (CERficación ESpañola) que lidera la Fábrica Nacional de Moneda y Timbre, consiste en líneas generales en establecer una Entidad Pública de Certificación, que permita autentificar y garantizar la confidencialidad de las comunicaciones entre ciudadanos, empresas u otras instituciones y administraciones públicas a través de las redes abiertas de comunicación.

Las posibilidades de CERES cubren todas aquellas relaciones entre las distintas Administraciones (Central, Autonómica y Local) y los ciudadanos que necesiten ser securizadas en términos de garantía de identidad, confidencialidad e integridad, con el objetivo de que CERES facilite al máximo sus relaciones a través de las nuevas redes de comunicaciones.

El objetivo principal de CERES es la securización de las comunicaciones


Página 58 de 77


electrónicas con la Administración, siendo un intermediario transparente al usuario que garantizará a ciudadanos y Administraciones la identidad de ambos partícipes en una comunicación, así como la confidencialidad e integridad del mensaje enviado.

Para ello, CERES utiliza técnicas y sistemas criptográficos basados en lo que se conoce como sistema de clave pública, con dos características básicas:

✔ La identidad del usuario, al igual que su capacidad de firma, se encuentra, en el caso de máxima seguridad, almacenada en una tarjeta inteligente, que no puede ser accesible salvo por su propietario cuando introduzca el número de identificación personal, similar a la clave de una tarjeta de crédito. En caso de no utilizar tarjeta, el perfil criptográfico queda almacenado en un fichero, siendo necesario también un PIN de acceso.

✔ El sistema es completamente transparente al usuario, es decir, no es necesario conocer ninguna técnica criptográfica para realizar o verificar una firma electrónica o cifrar o descifrar un mensaje.

8.3 7.3 Buenas prácticas en el uso de certificadosLa Declaración de Prácticas de Certificación es un documento elaborado por una Autoridad de Certificación que recoge o regula la prestación de los servicios de certificación por parte de dicha Autoridad de Certificación en su condición de Prestador de Servicios de Certificación, en este caso la FNMTRCM. Se regula, entre otras cosas, la gestión de los Datos de creación y verificación de Firma y de los Certificados, las condiciones aplicables a la solicitud, expedición, uso, suspensión y extinción de la vigencia de los Certificados.

8.3.1 Aspectos generales✔ La Fábrica Nacional de Moneda y TimbreReal Casa de la Moneda (FNMT

RCM), procederá a la expedición de los Certificados a todos los interesados que hubieran formulado su solicitud y suscriban el presente documento.


Página 59 de 77


✔ Los Solicitantes de Certificados deberán ser personas físicas, mayores de edad (o menores emancipados) y en posesión del correspondiente DNI o NIE (número de identificación de extranjeros).

✔ La expedición de Certificados y la anotación en el registro correspondiente por la FNMTRCM otorgará a los interesados la condición de Entidad usuaria de la Comunidad Electrónica de la FNMTRCM.

8.3.2 Características de los certificados✔ La FNMTRCM no facilitará información sobre los procesos técnicos de

producción y expedición de Certificados, los cuales tendrán la condición de confidenciales, sin perjuicio de lo que se ordenare por Ley, resolución judicial o administrativa.

✔ El Certificado a expedir por la FNMT–RCM se basa, en cuanto a su formato, en la versión 3 de la recomendación internacional X.509 de la UIT y será expedido con la cualidad de Certificado Reconocido con base en los criterios para ello establecido en la Ley núm. 59/2003 de Firma Electrónica.

✔ La emisión y firma electrónica del Certificado se realizará por la FNMTRCM.

8.3.3 Condiciones de utilización✔ Uso de los Certificados: Para poder usar los Certificados o confiar en

documentos firmados electrónicamente con base en los mismos, se deberá previamente formar parte de la Comunidad Electrónica, y adquirir la condición de Entidad usuaria. Fuera de la Comunidad Electrónica no se debe confiar en un Certificado o en una firma electrónica que se base en un Certificado . En cualquier caso, de producirse esta confianza por parte de un tercero, no se obtendrá cobertura de la presente Declaración de Prácticas de Certificación, y se carecerá de legitimidad alguna para reclamar o emprender acciones judiciales contra la FNMTRCM por daños,


Página 60 de 77


perjuicios, o conflictos provenientes del uso o confianza en un Certificado.

✔ Límites de uso de los Certificados: Incluso dentro del ámbito de la Comunidad Electrónica, no se podrá emplear este tipo de Certificado para: (i) Firmar electrónicamente otro certificado; (ii) Firmar electrónicamente software o componentes; (iii) Generar sellos de tiempo para procedimientos de Fechado electrónico; (iv) Prestar servicios a título gratuito u oneroso, como por ejemplo serían a título enunciativo: prestar servicios de OCSP, generar Listas de Revocación, prestar servicios de notificación; (v) Realizar transacciones económicas superiores a 100 €, salvo que:

○ Uno de los intervinientes sea una Entidad usuaria de Derecho Público o medie autorización expresa y escrita de la FNMTRCM para hacerlo y, en ese caso, en las condiciones que se establezcan en dicha autorización.

✔ Obligaciones del Suscriptor: (i) Aportar información verdadera en la solicitud de los Certificados, y mantenerla actualizada; (ii) Actuar con diligencia respecto de la custodia y conservación de los Datos de creación de Firma o cualquier otra información sensible como Claves, códigos de activación del Certificado , palabras de acceso, números de identificación personal, etc., así como de los soportes de los Certificados, lo que comprende en todo caso, la no revelación de ninguno de los datos mencionados ; (iii) Conocer y cumplir las condiciones de utilización de los Certificados previstos en la Declaración de Prácticas de Certificación y, en particular, las limitaciones de uso de los Certificados ; (iv) Conocer y cumplir tanto la Declaración de Prácticas de Certificación como las modificaciones que en ella se produzcan; (v) Notificar diligentemente a la FNMTRCM o a cualquier otra Oficina de Registro, las circunstancias o sospecha de pérdida de la Confidencialidad, la divulgación, modificación o uso no autorizado de los Datos de creación de Firma, solicitando además la revocación del correspondiente Certificado; (vi) Revisar la información contenida en el Certificado , y notificar a la Oficina de Registro cualquier error o inexactitud ; (vii) Verificar con carácter previo a confiar en los Certificados, la Firma electrónica reconocida del Prestador de Servicios de Certificación emisor del Certificado; (viii) Notificar diligentemente a la FNMTRCM o a cualquier otra Oficina de Registro cualquier modificación de los datos


Página 61 de 77


aportados en la solicitud del Certificado, solicitando cuando consecuentemente fuere pertinente la revocación del mismo ; (ix) Devolver o destruir el Certificado cuando así lo exija la FNMTRCM o la Oficina de Registro , cuando el Certificado caduque, o cuando sea revocado; (x) No usar el Certificado fuera de la Comunidad Electrónica.

✔ Obligaciones de la FNMTRCM como Prestador de Servicios de Certificación:

○ La FNMTRCM con carácter previo a la emisión del Certificado deberá: (i) Comprobar la identidad y circunstancias personales de los Solicitantes de Certificado con arreglo al artículo 13 de la Ley núm. 59/2003 de Firma Electrónica; (ii) Verificar que la información contenida en el Certificado es exacta y que incluye toda la información requerida para un Certificado Reconocido; (iii) Comprobar que el interesado en solicitar la emisión del Certificado está en posesión de la Clave Privada correspondiente a la Clave Pública que posteriormente constará en el Certificado, constituyendo desde entonces los Datos de verificación de Firma del Suscriptor; (iv) Proporcionar al Solicitante de forma electrónica y gratuita la informa ción exigible en el articulo 18, apartado b) de la Ley núm. 59/2003 de Firma Electrónica antes de la expedición del Certificado . Esta información se proporciona a través de la Declaración de Prácticas de Certificación.

○ La FNMTRCM con carácter general deberá: (i) No almacenar ni copiar los Datos de creación de Firma de la persona a la que presta sus servicios; (ii) Demostrar la fiabilidad necesaria para prestar servicios de certificación; (iii) Garantizar que puede determinarse con precisión la fecha y la hora en las que se expidió un Certificado o se extinguió o suspendió su vigencia; (iv) Emplear personal con la cualificación, conocimiento y experiencia necesarios para la prestación de los servicios de certificación ofrecidos y los procedimientos de seguridad y de gestión adecuados en el ámbito de la firma electrónica; (v) Utilizar sistemas y productos fiables que doten de la seguridad técnica, y en su caso criptográfica, a los procesos de certificación a los que sirve de soporte; (vi) Tomar medidas contra la falsificación de Certificados ; (vii) Conservar registrada por cualquier medio seguro toda la información y


Página 62 de 77


documentación relativa a un Certificado Reconocido y la Declaración de Prácticas de Certificación vigente en cada momento, al menos durante 15 años contados desde el momento de su expedición, de manera que puedan verificarse las firmas efectuadas con el mismo ; (viii) Utilizar sistemas fiables para almacenar Certificados Reconocidos que permitan comprobar su autenticidad e impedir que personas no autorizadas alteren los datos.

✔ Vigencia de los Certificados : Los Certificados quedarán sin efecto en los siguientes casos: (i) Expiración del período de validez del Certificado ; (ii) Revocación solicitada por el Suscriptor, la persona física o Persona jurídica representada por éste, un tercero autorizado o la persona física solicitante de un Certificado de Persona j urídica; (iii) Violación o puesta en peligro del secreto de los Datos de creación de Firma del firmante o del Prestador de Servicios de Certificación o utilización indebida de dichos datos por un tercero; (iv) Resolución judicial o administrativa que lo ordene; (v) Fallecimiento o extinción de la personalidad jurídica del firmante o del Representado, incapacidad total sobrevenida total o parcial, de cualquiera de ellos, cese en el cargo, terminación de la representación o extinción de la Persona jurídica representada; (vi) Cese en su actividad como Prestador de Servicios de Certificación de la FNMTRCM, salvo que, previo consentimiento expreso del Suscriptor , los Certificados expedidos por aquél sean transferidos a otro Prestador de Servicios de Certificación; (vii) Alteración de los datos aportados para la obtención del Certificado o modificación de las circunstancias verificadas para la expedición del Certificado , como las relativas al cargo o a las facultades de representación, de manera que éste ya no fuera conforme a la realidad; (viii) Cualquier otra causa lícita prevista en la Declaración de Prácticas de Certificación.

La pérdida de eficacia de los Certificados, en los supuestos de expiración de su período de validez y de cese de actividad del Prestador de Servicios de Certificación tendrá lugar desde que estas circunstancias se produzcan. En los demás casos, la extinción de la eficacia de un Certificado surtirá efectos desde la fecha en que la FNMT–RCM tenga conocimiento cierto de cualquiera de los hechos determinantes de ella y así lo haga constar en la Lista de Revocación .


Página 63 de 77


http://www.cert.fnmt.es/convenio/dpc.pdf

8.4 7.4 Uso de certificados orientados a la Administración PúblicaAlgunos ejemplos de los servicios al ciudadano que las distintas AA.PP. están ofreciendo son:

✔ Presentación de recursos y reclamaciones

✔ Cumplimentación de los datos del censo de población y viviendas

✔ Presentación y liquidación de impuestos

✔ Consulta e inscripción en el padrón municipal

✔ Consulta de multas de circulación

✔ Domiciliación bancaria de tributos municipales (IBI, IVTM, IAE...)

✔ Consulta y trámites para solicitud de subvenciones

✔ Consulta de asignación de colegios electorales

✔ Actuaciones comunicadas

✔ Firma electrónica de documentos oficiales y expedición de copias compulsadas.

9 GNUPG

9.1 DefiniciónGNU Privacy Guard es una herramienta para cifrado y firmas digitales, que viene a ser un reemplazo del PGP. Esta aplicación cifra los mensajes usando pares de claves individuales asimétricas generadas por los usuarios. Las claves públicas pueden ser compartidas con otros usuarios de muchas maneras, un ejemplo de ello es depositándolas en los servidores de claves. Siempre deben ser compartidas cuidadosamente para prevenir falsas identidades por la corrupción de las claves públicas. También es posible añadir una firma digital criptográfica a un mensaje,


Página 64 de 77


de esta manera la totalidad del mensaje y el remitente pueden ser verificados en caso de que se desconfíe de una correspondencia en particular.

GPG no usa algoritmos de software que están restringidos por patentes, entre estos se encuentra el algoritmo de cifrado IDEA que está presente en PGP casi desde sus inicios. En su lugar usa una serie de algoritmos no patentados como ElGamal, CAST5, Triple DES (3DES), AES y Blowfish. También es posible usar IDEA en GPG descargando un plugin extra, sin embargo este puede requerir una licencia para usuarios de algunos países en donde esté patentada IDEA.

9.2 FuncionamientoGPG es un software de cifrado híbrido que usa una combinación convencional de criptografía de claves simétricas para la rapidez y criptografía de claves públicas para el fácil compartimiento de claves seguras, típicamente usando recipientes de claves públicas para cifrar una sesión de clave que es usada una vez. Este modo de operación es parte del estándar OpenPGP y ha sido parte del PGP desde su primera versión.

9.3 GPG versión SMIMEEsta versión ofrece una implementación SMIME de uso similar a la implementación OpenPGP.

9.4 Practica GPGEn primer lugar, para empezar el trabajo y las operaciones con la herramienta, generamos una nueva clave.

$ gpg genkey

Con este comando se genera un nuevo par de claves (el par se compone de clave privada y clave pública). La primera pregunta es qué algoritmo se va a usar.


Página 65 de 77


La siguiente pregunta es la longitud de la clave. Esta parte depende de los requerimientos del usuario. Es necesario elegir entre la seguridad y el tiempo de los procesos. Cuanto mayor sea una clave, menor será el riesgo de que el mensaje sea descodificado si es interceptado, pero también aumentará el tiempo que empleará para el cálculo de los procesos. El tamaño mínimo que requiere GnuPG es de 768 bits, aunque mucha gente opina que debería ser de 2048 (que es el máximo con GnuPG en este momento). Para DSA 1024 es un tamaño fijo. Cuando la seguridad es una prioridad más alta que el tiempo, la opción es elegir el tamaño de clave más grande que se permita.

Una vez generada la clave, podremos realizar otra de las operaciones importantes como la de exportarla. La orden para exportar la clave es:

$ gpg export <uid>

Si no designamos un identificador de usuario “uid” todas las claves presentes en el anillo de claves serán exportadas. El resultado es enviado por defecto a stdout, pero con la opción o podemos especificar que sea enviado a un fichero. Se recomienda usar la opción a para que el resultado sea un fichero de 7bit ASCII en lugar de un fichero binario.

Al exportar, podemos mover las claves públicas en ficheros que podemos importar al anillo local de certificados mediante el comando “importar” que podemos ejecutar de la siguiente forma:

$ gpg import <fichero>

Existen diversos motivos por los que se puede desear revocar una clave. Por ejemplo, si la clave secreta ha sido robada, o si se ha olvidado la contraseña de ésta. En cualquier caso la orden de revocación es:

$ gpg genrevoke


Página 66 de 77


Esto creará un “certificado de revocación”. Para ello es necesaria la clave secreta, de lo contrario cualquiera podría hacer un certificado y revocar una clave que no le perteneciera.

La operativa con GNUPG genera una base de datos local en un fichero que constituye el anillo local de claves. Para consultar o gestionar esta base de datos de claves la herramienta cuenta con múltiples opciones como las siguientes:

$ gpg listkeys

Con el anterior comando se muestran todas las claves presentes. Para poder ver también las firmas en cada clave, usar:

$ gpg listsigs

Para ver las huellas digitales (fingerprints):

$ gpg fingerprint

Las “huellas digitales” sirven para confirmar la identidad de la persona. Esta orden nos muestra una lista alfanumérica que podemos comprobar, por ejemplo, por teléfono.

Para ver el listado de las claves secretas:

$ gpg listsecretkeys

Para eliminar una clave pública:

$ gpg deletekey <uid>


Página 67 de 77


Para eliminar una clave secreta:

$ gpg deletesecretkey

Existe otra orden que es relevante para trabajar con las claves:

$ gpg editkey <uid>

Para esta orden necesitaremos la contraseña, y podemos, entre otras cosas, editar la fecha de caducidad, añadir una huella digital y firmar la clave.

Como se ha mencionado anteriormente en la introducción, existe un talón de Aquiles en el sistema: la autenticación de las claves públicas. Si se obtiene una clave pública errónea, ya se puede despedir uno del valor del cifrado. Para evitar estos riesgos está la posibilidad de firmar las claves. Cuando tenemos la certeza de que una clave es válida y pertenece a quien dice, podemos firmarla digitalmente, de modo que otros que confíen en nuestra firma la puedan dar por válida. Para hacer esto podemos ejecutar:

$ gpg editkey <uid>

Una vez aquí, se nos llevará al subcomando:

Command> sign

Basándose en las firmas existentes en una clave y en el “grado de confianza”, GnuPG determina la validez de las claves. El grado de confianza (ownertrust) es un valor que el propietario de una clave usa para determinar el nivel de confianza para una cierta clave. Estos valores pueden ser:


Página 68 de 77


✔ 1: No sé, no conozco

✔ 2: Confianza nula

✔ 3: Confianza marginal

✔ 4: Confianza plena

Si el usuario no se fía de una firma puede indicarlo así, y rechazar la confianza en ésta. La información sobre la confianza no se guarda en el mismo fichero que el de las claves, sino en otro diferente.

Es posible que cuando estemos cifrando o descifrando un documento, tengamos más de una clave privada en nuestro anillo de claves privadas. Si esto es así, es necesario seleccionar una de ellas como activa. Para ello se puede usar la opción

u <uid>

o bien la opción

localuser <uid>

También podemos agregar la siguiente línea en el fichero de configuración $HOME/.gnupg/options:

defaultkey <uid>

Si se desea indicar el “uid” de un destinatario para cifrar un fichero con su clave, se puede hacerse con la opción:

r


Página 69 de 77


o bien la opción:

recipient

Una vez ajustado todo lo anterior, podemos cifrar y descifrar ficheros para lo cuál podemos empezar con la siguiente orden:

$ gpg e <fichero>

o bien la siguiente:

$ gpg encrypt <fichero>

Estas órdenes cifrarían un fichero con la clave que hayamos definido por defecto en el fichero de configuración options. Para cifrar un fichero con la clave de otro usuario:

$ gpg er destinatario <fichero>

Pero como ya hemos comentado anteriormente esto produciría un criptograma con el nombre de fichero.gpg; se puede añadir la opción

armor

para que el criptograma sea del tipo 7bit ASCII:

$ gpg a er destinatario <fichero>

Esta comando producirá un criptograma con la extensión fichero.asc. Ya que los


Página 70 de 77


mensajes, ficheros, y otro tipo de datos que enviamos codificados van cifrados con la clave del destinatario, existe el riesgo de que alguien lo haga suplantando nuestra identidad. Para evitar esto basta con firmar digitalmente todo lo que se cifre.

Para descifrar un fichero cifrado, podemos empezar con el siguiente comando:

$ gpg [d] <fichero>

o bien:

$ gpg [decrypt] <fichero>

En este caso no es necesaria la opción, es opcional, ya que la orden gpg usa por defecto la opción:

decrypt

En todos los casos que hemos nombrado aquí el resultado está direccionado a stdout, pero puede ser redireccionado con la opción:

o <fichero>

Con esto se crea un fichero con cualquier otro nombre.

Firmar y verificar firmas es una parte importante de los sistemas de criptografía de clave pública. El usuario puede firmar una serie de datos o un documento en varios modos, para lo que usa su propia clave privada. Para verificar las firmas de otros usuarios, es necesario poseer previamente las claves públicas de éstos.


Página 71 de 77


Para firmar un fichero con la clave propia se usa la orden

$ gpg s <fichero>

Esta orden, además de producir una firma digital, también comprime el fichero, por lo que el resultado es un fichero de tipo binario (y por tanto ilegible). Para producir un fichero firmado legible (ascii), se usa la orden:

$ gpg clearsign <fichero>

De este modo, tanto la firma como los datos firmados, son legibles con un editor.

Cuando queramos que la firma aparezca en un fichero separado, sobre todo cuando se trata de firmar un fichero binario, como por ejemplo un archivo comprimido, o un ejecutable, usaremos la orden

$ gpg b <fichero>

o bien:

$ gpg detachsign <fichero>

Este es el modo que MIME/PGP usa para firmar los mensajes del correo electrónico. Este modo es muy útil cuando tengamos que firmar un binario, por ejemplo, para distribuirlo, ya que la firma se basa en el binario pero va en un fichero aparte. La opción armor también puede ser de utilidad en estos casos.

A menudo debemos cifrar y firmar un fichero a un tiempo. La orden que usaríamos en este caso sería


Página 72 de 77


$ gpg [u remitente] [r destinatario] [armor] sign encrypt <fichero>

La funcionalidad de las opciones u (localuser) y r (recipient) es la que se ha descrito ya anteriormente.

Al descifrar un criptograma que también haya sido firmado digitalmente, la firma es verificada automáticamente. En todo caso es posible verificar la firma simplemente con la orden:

$ gpg [verify] <fichero>

10 Otras aplicaciones

10.1 Práctica Apache/SSL

HTTPS es la versión segura del protocolo HTTP, inventada en 1996 por Netscape Communications Corporation. No es un protocolo separado de HTTP. Se trata de una combinación de este último con un mecanismo de transporte SSL o TLS, garantizando una protección razonable durante la comunicación clienteservidor. Es ampliamente utilizado en la red mundial (WWW o World Wide Web) para comunicaciones como transacciones bancarias y pago de bienes y servicios.

El servicio utiliza el puerto 443 por TCP para realizar las comunicaciones (la comunicación normal para HTTP utiliza el 80 por TCP). El esquema URI (Uniform Resource Identifier o Identificador Uniforme de Recursos) es, comparando sintaxis, idéntico al de HTTP (http:), utilizándose como https: seguido del subconjunto denominado URL (Uniform Resource Locator o Localizador Uniforme de Recursos). Ejemplo: https://www.dominio.org/.

10.1.1 Acerca de mod_ssl


Página 73 de 77


mod\_ssl es un módulo para el servidor HTTP Apache, el cual provee soporte para SSL versiones 2 y 3 y TLS versión 1. Es una contribución de Ralf S. Engeschall, derivado del trabajo de Ben Laurie.

10.1.2 Requisitos

Es necesario disponer de una dirección IP pública para cada sitio de red virtual que se quiera configurar con soporte SSL/TLS. Debido a la naturaleza de los protocolos SSL y TLS, no es posible utilizar múltiples sitios de red virtuales con soporte SSL/TLS utilizando una misma dirección IP. Cada certificado utilizado requerirá una dirección IP independiente en el sitio de red virtual.

El paquete mod_ssl instala el fichero /etc/httpd/conf.d/ssl.conf, mismo que no es necesario modificar, puesto que se utilizarán ficheros de inclusión, con extensión *.conf, dentro del directorio /etc/httpd/conf.d/, a fin de respetar la configuración predeterminada y podre contar con la misma, que es funcional, brindando un punto de retorno en el caso de que algo saliera mal.

10.1.3 Procedimientos

Acceda al sistema como el usuario root.

Se debe crear el directorio donde se almacenarán los certificados para todos los sitios SSL. El directorio, por motivos de seguridad, debe ser solamente accesible para el usuario root.

$ mkdir m 0700 /etc/ssl

A fin de mantener cierta organización, y un directorio dedicado para cada sitio virtual SSL, es conveniente crear un directorio específico para almacenar los certificados de cada sitio virtual SSL. Igualmente, por motivos de seguridad, debe ser solamente accesible para el usuario root.

$ mkdir m 0700 /etc/ssl/midominio.org

Acceder al directorio que se acaba de crear.


Página 74 de 77


$ cd /etc/ssl/midominio.org

10.1.4 Generando clave y certificado

Se debe crear una clave con algoritmo RSA de 1024 octetos y estructura x509, la cual se cifra utilizado Triple DES (Data Encryption Standard), almacenado en formato PEM de modo que sea interpretable como texto ASCII.

$ openssl genrsa des3 out server.key 1024

Si se utiliza este fichero (server.key) para la configuración del sitio virtual, se requerirá de interacción del administrador cada vez que se tenga que iniciar, o reiniciar, el servicio httpd, ingresando la clave de acceso de la clave RSA. Este es el procedimiento más seguro, sin embargo, debido a que resultaría poco práctico tener que ingresar una clave de acceso cada vez que se inicie el servicio httpd, resulta conveniente generar una clave sin Triple DES, la cual permita iniciar normalmente, sin interacción alguna, al servicio httpd. A fin de que no se sacrifique demasiada seguridad, es un requisito indispensable que esta clave (fichero server.pem) solo sea accesible para root. Ésta es la razón por la cual se crea el directorio /etc/ssl/midominio.org con permiso de acceso solo para root.

$ openssl rsa in server.key out server.pem

Opcionalmente se genera un fichero de petición CSR (Certificate Signing Request) que se hace llegar a una RA (Registration Authority o Autoridad de Registro), como Verisign, quienes, tras el correspondiente pago, envían de vuelta un certificado (server.crt) firmado por dicha autoridad.

$ openssl req new key server.key out server.csr

Si no se desea un certificado firmado por un RA, puede generarse uno certificado propio utilizando el fichero de petición CSR (server.csr). En el ejemplo a continuación, se crea un certificado con estructura X.509 en el que se establece una validez por 730 días (dos años).


Página 75 de 77


$openssl x509 req days 730 in server.csr signkey server.key out server.crt

Con la finalidad de que solo el usuario root pueda acceder a los ficheros creados, se deben cambiar los permisos de éstos a solo lectura para root.

$ chmod 400 /etc/ssl/midominio.org/server.*

10.1.5 Configuración de Apache

Crear la estructura de directorios para el sitio de red virtual.

$ mkdir p /var/www/midominio.org/{cgibin,html,logs,etc,var}

De todos directorios creados, solo /var/www/midominio.org/html, /var/www/midominio.org/etc, /var/www/midominio.org/cgibin y /var/www/midominio.org/var pueden pertenecer al usuario, sin privilegios, que administrará éste sitio de red virtual. Por motivos de seguridad, y a fin de evitar que el servicio HTTPD no sea trastornado en caso de un borrado accidental de algún directorio, tanto /var/www/midominio.org/ como /var/www/midominio.org/logs, deben pertenecer al usuario root.

Crear el fichero /etc/httpd/conf.d/midominio.conf con el siguiente contenido, donde a.b.c.d corresponde a una dirección IP, y midominio.org corresponde al nombre de dominio a configurar para el sitio de red virtual:

### midominio.org ###NameVirtualHost a.b.c.d:80

<VirtualHost a.b.c.d:80>ServerAdmin [email protected] /var/www/midominio.org/htmlServerName www.midominio.orgServerAlias midominio.orgRedirect 301 / https://www.midominio.org/CustomLog /var/www/midominio.org/logs/access_log

combined


Página 76 de 77


Errorlog /var/www/midominio.org/logs/error_log</VirtualHost>

NameVirtualHost a.b.c.d:443<VirtualHost a.b.c.d:443>

ServerAdmin [email protected] /var/www/midominio.org/htmlServerName www.midominio.orgScriptAlias /cgibin/ /var/www/midominio.org/cgibin/SSLEngine onSSLCertificateFile /etc/ssl/midominio.org/server.crtSSLCertificateKeyFile /etc/ssl/midominio.org/server.pemSetEnvIf UserAgent ".*MSIE.*" nokeepalive ssluncleanshutdownCustomLog /var/www/midominio.org/logs/ssl_request_log \

"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"CustomLog /var/www/midominio.org/logs/ssl_access_log

combinedErrorlog /var/www/midominio.org/logs/ssl_error_log

</VirtualHost>

A fin de que surtan efecto los cambios, es necesario reiniciar el servicio httpd.

$ /etc/init.d/apache restart

10.1.6 Comprobaciones

Solo basta dirigir cualquier navegador HTTP hacia https://www.midominio.org/ a fin de verificar que todo esté trabajando correctamente. Tras aceptar el certificado, en el caso de que éste no haya sido firmado por un RA, deberá poderse observar un signo en la barra de estado del navegador, el cual indica que se trata de una conexión segura.


Página 77 de 77

curso firma digital2

Documents