Infraestructura de Clave Pública - Bolivia bolivia y... · Para ello se utiliza Software Libre....

Remberto Gonzales Cruze-mail: [email protected], [email protected]

1

RESUMEN

El empleo de una Infraestructura de Clave Pública - PKI - , es una pieza clave en lo que son las transaccionesadministrativas, comerciales y otras aplicaciones, que requieren de seguridad y autenticación, esto en Intranets,Extranets e Internet

La utilización de una PKI, requiere la utilización de un criptosistema de clave pública, que se encargue degestionar y manejar los accesorios (claves, firmas, etc.)

El presente trabajo, propone un modelo de Infraestructura de Clave Pública, y sus mejores practicas, paracaracterizar, definir e implementar una Plataforma de Seguridad, orientado a las entidades Estatales y basado enla utilización de Firmas y Certificados Digitales, todo ello utilizando Software Libre.


2

INTRODUCCION

El rápido crecimiento de las redes, en el mundo, y por lo tanto el crecimiento exponencial de las interconexionesy los servicios añadidos de lo que es Internet, ya forman parte de nuestra vida cotidiana, al punto que ya se estaacostumbrado, y sin la cual, ya no viviríamos normalmente.

El problema de la seguridad en las redes, y por lo tanto en las comunicaciones, viene a ser uno de los problemasmás importantes, en lo que son las transacciones administrativas y/o comerciales, cuyos servicios, tienen másdesventajas que ventajas, por lo cual el usuario común no confía aun en dichos servicios.

Un ejemplo actual que se dio a inicios del año 2001, es el robo de los datos de tarjetas de crédito, de miles deusuarios, de una conocida empresa punto com, también se conoce un alto porcentaje de intrusiones a diferentesempresas que trabajan en transacciones en el ámbito administrativo y comercial, sin ir muy lejos, en nuestroPaís, nuestras entidades financieras, utilizan muy poco lo que se denomina seguridad en transacciones, amen desoportar algunos algoritmos criptográficos y Certificados Digitales de empresas fuera del País, en el entornoadministrativo, las Entidades Estatales no hacen uso de este tipo de seguridad, si bien por que no lo necesitan ono se dan cuenta de su necesidad, o porque no tienen conocimiento de ello.

El presente trabajo, viene a cubrir esos aspectos de la seguridad en dichas transacciones, cuyo objetivo escaracterizar, normar, definir e implementar, lo que se denomina: Terceras Partes de Confianza en base a unaplataforma de seguridad.

El objeto de estudio, los mecanismos y herramientas criptográficas, para obtener transacciones seguras en la red.

El campo de acción, esta definido, en lo que viene a ser las Entidades Estatales en General.

Para ello se ha planteado la siguiente hipótesis: Mediante la aplicación de mecanismos y herramientasCriptográficas, se puede garantizar la Confidencialidad, Autenticidad, Integridad y no repudio de lastransacciones administrativas y/o económicas realizadas a través de una red. (Internet, Intranet y/o Extranet)

Los métodos de trabajo a emplear: en primer lugar una revisión bibliográfica, de temas relacionados al tema deestudio, en segundo lugar, una evaluación de algunas plataformas libres y los servicios que ofrecen.

En suma, el empleo de la Investigación Científica.

El trabajo se dividirá en cuatro partes y se puede resumir de la siguiente manera:

Parte I, Antecedentes, algunos conceptos fundamentales y evaluación de plataformas ya existentes.

Parte II, Modelo propuesto de Infraestructura de Clave Pública, en este parte se realiza un análisis y diseñogeneral, de los lineamientos de lo que la Infraestructura de Clave Pública debiera como mínimo ofrecer,considerando las mejores practicas existentes, se plantea mejoras, objetivos, la arquitectura, los procesos yprocedimientos propios.

Parte III, Instalación e Implementación de la Infraestructura de Clave Pública, en base a los estudios realizadosen la parte II, se realiza la descripción de los módulos, la instalación e implementación en base a requerimientosencontrados. Para ello se utiliza Software Libre.

Parte IV, Conclusiones y Recomendaciones, se dan las conclusiones pertinentes al planteamiento de la PKI, y lasrecomendaciones respectivas, tanto teóricas como practicas para su implementación e implantación en lasdiferentes Entidades Estatales.


3

INDICE

Pagina

ResumenIntroducciónIndice

1. PARTE I, ANTECEDENTES

1.1. Introducción1.2. Ataques y Amenazas1.3. Mecanismos y Herramientas de Seguridad1.4. Estado del Arte en Bolivia1.5. Modelos de PKI

1.5.1.EuPKI – PKI de la Comunidad Europea1.5.2.Pretty Goog Privay - PGP1.5.3.Privacy Enhacement for Internet Electronic Mail - PEM

2. PARTE II, MODELO PROPUESTO DE PKI

2.1. Especificación de la Arquitectura de la PKI2.2. Componentes Básicos de una PKI2.3. Funciones de la PKI2.4. Escenarios de Aplicación

3. PARTE III, INSTALACION E IMPLEMENTACION

3.1. Software a Utilizar3.1.1.Sistema Operativo3.1.2.Open SSL3.1.3.MM – Shared Memory Allocation3.1.4.Mod SSL3.1.5.Apache www Server3.1.6.MySQL3.1.7.Open CA

4. PARTE IV, CONCLUSIONES Y RECOMENDACIONES4.1. Conclusiones4.2. Recomendaciones

5. BIBLIOGRAFIA


4

1. PARTE I, ANTECEDENTES

1.1. INTRODUCCIÓN

El concepto de seguridad es ya un clásico en muchos ámbitos de la informática. En nuestro país, el mismoconcepto es desconocido, o por lo menos, poco conocido en entornos NO informáticos, y peor aun elconcepto de lo que es Sistema de Seguridad, porque no se le da la importancia debida a este problema, puesmuchos administradores de sistemas o redes, orientan más sus funciones hacia el usuario, en cuanto alservicio ofrecido de: presentación y disponibilidad de la información, y no tanto así, a lo que es la seguridadde estos.

El concepto de seguridad en la información es mucho más amplio que la simple protección de los datos anivel lógico [Lucena, 2003], pues este engloba muchas características y otros factores (ambientes, hardware,recursos humanos), que caracterizan el tratamiento y la protección de la información.

La fundamentación presentada en esta parte, prioriza, los mecanismos y herramientas sobre los aspectos dela seguridad en las diferentes transacciones administrativas y/o comerciales realizadas, y en la seguridad dela información propiamente dicha, se analiza y evalúa algunos modelos existentes, considerando sus ventajasy desventajas en la aplicación de la transmisión de datos e información.

1.2. ATAQUES Y AMENAZAS

Uno de los factores de seguridad que son muy susceptibles para cualquier usuario, es el que alguna personano autorizada, tenga acceso a sus datos, o monitoree sus transacciones, esto tiende a definir lo que es una“amenaza”1.

Las categorías generales de ataques o amenazas son las siguientes: Interrupción, Intercepción, Modificación,Suplantación. Los cuales pueden ser pasivos o activos, dependiendo del nivel de intromisión realizada poralgún intruso.

En los ataques pasivos el atacante no altera la comunicación, sino que únicamente la escucha o monitoriza,para obtener la información que está siendo transmitida. Sus objetivos son la intercepción de datos y elanálisis de tráfico.

Los ataques pasivos son muy difíciles de detectar, ya que no provocan ninguna alteración de los datos. Sinembargo, es posible evitar su éxito mediante el cifrado de la información.

Fig. 1.2.a. Ataque Pasivo

Por otra parte los ataques activos, implican algún tipo de modificación del flujo de datos transmitido o lacreación de un falso flujo de datos.

1 Amenaza: Posible peligro del sistema. Cracker, virus, caballo de Troya, Representan los posibles atacantes o factores que aprovechanlas debilidades del sistema. www.wikipedia.org

http://www.wikipedia.org


5

Estas amenazas y ataques, pueden ser realizados en sistemas aislados, que actualmente vendrían a ser unacantidad mínima, y en sistemas interconectados -redes-, que es donde los sistemas presentan másvulnerabilidades.

Fig. 1.2.b Ataques Activos

Así mismo dependiendo del entorno, se podrían dar ataques externos o físicos relacionados con la protecciónde los soportes físicos de la información, más que a la información propiamente.

1.3. MECANISMOS Y HERRAMIENTAS DE SEGURIDAD

Los mecanismos para garantizar la seguridad no pueden ser ajenos a los sistemas informáticos, pues ellospueden frenar y minimizar de alguna manera, las amenazas y ataques a la información, por ello se tienen unaserie de medidas, entre las cuales se puede mencionar.

- Definición de niveles de seguridad.- Claves de acceso (passwords).- Criptografía y firma digital en las comunicaciones y transacciones.- Utilización de Certificados para la autenticación.- Plan de contingencias.

El nivel de desarrollo de estas medidas depende de la naturaleza de la organización, de la información, de lasaplicaciones, de quienes las usan y acceden a estas.

La puesta en marcha de un plan de seguridad no es algo estático que se hace una vez. Una de las principalesgarantías de que un sistema es seguro, es que se realiza un seguimiento de las medidas puestas en marcha, delos registros de auditoria, y otros, el seguimiento de las medidas de seguridad es la vía para asegurar que elplan se adapta a la organización y para detectar posibles intentos de fraude o acceso incorrecto.

Los planes de seguridad deben considerar el tipo de información, de los usuarios, de los equipos y sistemas.También el plan debe de especificar las tareas a realizar, sus responsables, cómo se definen los niveles deacceso, cómo se realizará el seguimiento, dónde deben ponerse en marcha medidas específicas (cortafuegos -firewalls-, filtros, control de acceso y otros), e inclusive tomar en cuenta la estructura organizativa.

No hay que olvidar que el sentido común juega un papel de relevancia, ya que si no es así, se pueden llegar aproponer medidas muy seguras pero realmente impracticables, lo cual significa que hay que asumir ciertosriesgos.


6

1.3.1.CRIPTOGRAFIA

Uno de las medidas que no debe faltar en un plan de seguridad, es el referente al área de la Criptografía,la cual es una de las bases más importantes en este aspecto (seguridad).

Criptografía: La criptografía es el estudio de técnicas matemáticas relacionadas a aspectos de laseguridad, tales como la confidencialidad, integridad de datos, autenticación, y no repudio.Una definición más común para la criptografía es: Criptografía es la técnica de convertir un texto enclaro (plaintext), en otro llamado criptograma (ciphertext), cuyo contenido de información es igual alanterior pero sólo lo pueden entender las personas autorizadas.

Texto en Claro

(plain text)

Criptograma

(cipher text)CRIPTOGRAFIA

Texto en Claro

(plain text)

Criptograma

(cipher text)CRIPTOGRAFIA

Fig. 1.3.1. Criptografía

Para cifrar se debe transformar un texto mediante un método cuya función inversa únicamente conocenlas personas autorizadas. Así se puede utilizar un algoritmo secreto o un algoritmo público que utilizauna palabra, llamada clave, sólo conocida por las personas autorizadas, esta clave debe serimprescindible para el cifrado y descifrado.

Existen dos tipos de criptosistemas, Simétrico o de Llave Privada y Asimétrico o de Llave Pública.

1.3.1.1. CRIPTOGRAFIA SIMETRICA

La criptografía simétrica se refiere al conjunto de métodos que permiten tener comunicación seguraentre las partes siempre y cuando anteriormente se hayan intercambiado la clave correspondiente quellamaremos clave o llave simétrica. La simetría se refiere a que las partes tienen la misma llave tantopara cifrar como para descifrar.

Texto en Claro

(plain text)

Criptograma

(cipher text)CIFRAR DESCIFRAR

Texto en Claro

(plain text)

Fig. 1.3.1.1 Criptografía Simétrica

AES

Una mención especial, merece el nuevo estándar de cifrado AES -Advanced Encryption Stándard-[Rinjdael, 2000], que a finales del 2000, se posesiono como nuevo estándar simétrico.

Este nuevo estándar, especifica el algoritmo Rijndael, un cifrador de bloque que tiene las siguientescaracterísticas:


7

- Proceso de bloques de datos de 128 bits, utilizando llaves con longitudes de 128, 192 y 256 bits.- Las entradas y salidas para el algoritmo AES, consisten de una secuencia de 128 bits.- Internamente en AES, las operaciones sobre los bloques son realizados en una matriz

bidimensional de bytes denominado Estado. [Rinjdael, 2000].- Todos los bytes en AES, son interpretados como elementos de Campos Finitos GF(28), grado 8.

El algoritmo en vez de utilizar las famosas redes de Feistel2, utiliza otro tipo de mecanismos,denominados transformaciones:

SubBytes: es una transformación no lineal, de substitución de bytes, que opera independientementesobre cada byte de el Estado, utilizando una tabla de sustitución denominada S-Box.

ShiftRows: es una transformación, que hace que los bytes de las ultimas tres filas del Estado seancíclicamente desplazadas sobre diferentes números de bytes (desplazamientos).

MixColumns: la transformación opera sobre el Estado, columna por columna, procesando cadacolumna como un termino polinomial, sobre GF(28).

Una aplicación de la criptografía simétrica, es el cifrado del flujo de información transmitido(pudiéndose ser esto en tiempo real), en entornos seguros.

1.3.1.2. CRIPTOGRAFIA ASIMETRICA

La criptografía asimétrica, ha demostrado su interés para ser empleados en redes de comunicacióninseguras (Internet). Introducidos por Whitfield Diffie y Martin Hellman [WDMH, 1976], amediados de los años 70, su novedad fundamental con respecto a la criptografía simétrica es que lasclaves no son únicas, sino que forman pares, denominadas clave privada y clave pública. Una deellas se emplea para codificar, mientras que la otra se usa para decodificar. Dependiendo de laaplicación que se le de al algoritmo, la clave pública será la de cifrado o viceversa. Para que estoscriptosistemas sean seguros también ha de cumplirse que a partir de una de las claves resulteextremadamente difícil calcular la otra.

Texto en Claro

(plain text)

Criptograma

(cipher text)CIFRAR DESCIFRAR

Texto en Claro

(plain text)

LlavePública

LlavePrivada

Fig. 1.3.1.2 Criptografía Asimétrica

Los algoritmos asimétricos emplean generalmente longitudes de clave mucho mayores que lossimétricos. Por ejemplo, mientras que para algoritmos simétricos se considera segura una clave de128 bits, para algoritmos asimétricos se recomiendan claves de al menos 1024 bits. Además, lacomplejidad de cálculo que comportan estos últimos los hace considerablemente más lentos que losalgoritmos de cifrado por bloques. En la práctica los métodos asimétricos se emplean únicamentepara codificar la clave de sesión (simétrica) de cada mensaje.

2 Redes de Feistel: Divide un bloque de longitud N en dos mitades y la salida de cada ronda se usa como entrada para la siguiente.


8

Una aplicación de los algoritmos asimétricos es la autenticación de mensajes, con ayuda defunciones hash3, que nos permiten obtener una firma a partir de un mensaje. Dicha firma es muchomás pequeña que el mensaje original, y es muy difícil encontrar otro mensaje que tenga la mismafirma.

1.3.1.3. FIRMA DIGITAL

Otra Aplicación de la criptografía asimétrica, es lo que se denomina firma digital4, las cuales sonmétodos de cifrado que tienen dos propósitos:

Validar el contenido de un mensaje electrónico, que se puede utilizar posteriormente para comprobarque un emisor envió dicho mensaje.

Probar que no se ha falsificado un mensaje durante su envío. Las firmas digitales respaldan laautenticidad del correo electrónico, transacciones de diferente índole (contabilidad, órdenes de pago,documentos para grupos de trabajo y archivos que se trasladan entre sistemas, usuarios uorganizaciones).

La Firma Digital se basa en el hecho de que dos grupos pueden autentificarse el uno al otro para elintercambio seguro de documentos, pero la relación entre ellos no se basa en una confianza total. Porejemplo, una persona podría enviar un mensaje para una apuesta en cualquier competición y alperder negarse haber enviado dicho mensaje. Aunque se sabe a través del proceso de autenticaciónque esta persona realmente envió ese mensaje, sin una firma digital no se podría probar técnicamenteque el mensaje no se modificó. El emisor podría decir, "sí, yo le envié el mensaje, pero se lomodifico"

Las firmas digitales autentifican los mensajes y se usan para validar compras, transacciones denegocios, transacciones administrativas y/o académicas.

Texto en Claro

(plain text)

Resumen

Del texto

Texto en Claro

(plain text)

+

FIRMA

Función

HASH

LlavePrivada

para Firmar

Resumen Firmado

con la Llave Privada

Fig. 1.3.1.3 Firma Digital

Si bien existen diferentes mecanismos de seguridad, una aplicación híbrida de estos es lo aconsejable,para poder cubrir una extensa gama de vulnerabilidades, en cualquier sistema.

3 Función Hash: Las funciones Hash sirven para comprimir un texto en un bloque de longitud fija. Este resumen suele tener una longitudde 128 bits (en algoritmos como MD5, RIPEM128), o de 160 bits (SHA-1, RIPEM160).4 Firma Digital: La firma digital de un documento es el resultado de aplicar cierto algoritmo matemático, denominado función hash, a sucontenido.


9

1.4. ESTADO DEL ARTE EN BOLIVIA

Bolivia es uno de esos países, en los cuales, no existe un marco legal y regulatorio, que respalde lastransacciones electrónicas, aunque en fecha, 13/07/2005, se presento el primer borrador del “AnteProyecto de Ley de Comunicación Electrónica de Datos y Comercio Electrónico”, aprobado por variasinstituciones, en la cual y según el artículo 1 del capítulo 1 tiene por objeto “…regular la comunicaciónelectrónica de datos, otorgando y reconociendo eficacia y valor jurídico a los mensajes de datos,documentos electrónicos, la firma electrónica, la contratación electrónica ; así como a los diversos actosatribuibles a personas naturales y jurídicas, públicas o privadas realizadas por medios electrónicos”.

Si bien el Gobierno de la República de Bolivia ha implementado acciones importantes para fomentar eldesarrollo de las nuevas tecnologías de la información y comunicación en el marco de insertar al país ala sociedad de la información, esto esta mas orientado a lo que es el sistema financiero, específicamentecon el Comercio Electrónico.

Las transacciones de comercio electrónico indirecto en Bolivia están sujetas a los mismos tributos quelas transacciones comerciales tradicionales, es decir que las importaciones deben pagar los mismosimpuestos y gravámenes que cualquier otra importación.

El gobierno ha realizado apoyos importantes en cuanto a las facilidades de exportación y pago deimpuestos, pero no así a las transacciones administrativas, que viene a ser un punto débil en el contextoBoliviano.

Todas las entidades publicas específicamente, requieren y tiene la necesidad de compartir información, ylógicamente lo hacen, pero no de una manera segura, el uso del correo electrónico, es desde ya, lo masextendido que se tiene para el envió de información, aunque no de nivel critico, pues esto se hace deforma manual, es decir utilizando los medios comunes, Empresa de Correos, Courries, o envíos físicos através de diferentes empresas que ofrecen estos servicios.

No hay que desmerecer el esfuerzo que hacen algunas instituciones públicas, Impuestos Nacionales,Aduana, al tener una conexión dedicada y segura en la transferencia de información desde y hacia susdiferentes puntos en el país, pero esto no se da en ambientes abiertos, lógicamente por la mismaseguridad que esto implica.

1.4.1.Marco Jurídico para el Comercio Electrónico y Transmisión de Datos

- Ley SIRESE.- Ley de Telecomunicaciones.- Ley de Derechos de Autor.- Código Penal.- Modificaciones de la Ley Penal.- Los D.S. 25704 y el D.S. 25870 sobre gravamen arancelario a las importaciones.- La Ley SIRESE tiene como objetivo regular, controlar y supervisar el sector de las

telecomunicaciones, entre otros.- La Ley 1632 de Telecomunicaciones norma este sector.- En la Ley de Derechos de Autor se aprobó el Reglamento del Soporte Lógico o Software, con el

fin de proteger el mismo.- El Código Penal establece y sanciona los delitos cometidos contra los derechos de autor.- La modificación al Código Penal establece como delitos las alteraciones, modificaciones y uso

indebido de los medios informáticos.- D.S. 26553 que establece el marco legal e institucional para la implementación de las nuevas

tecnologías de información y comunicación.


10

1.5. MODELOS DE PKI

1.5.1.EuPKI – PKI de la Comunidad Europea

Creado por la Comunidad Europea, con el objetivo de producir un Software Libre orientado a laInfraestructura de Clave Publica. Para proveer acceso libre, alta calidad modular y un softwaretotalmente abierto, para asegurar el intercambio de información, en las aplicaciones de e-administracióny los e-negocios.

EuPKI, fue supuesto para la construcción de una Infraestructura de Clave Publica con las siguientescaracterísticas:

- Un Diseño completo y modular- Facilidad de Mantenimiento- Adaptabilidad en cualquier tipo de implementación- Basado en estándares actuales para asegurar la interoperabilidad

EuropePKI es liberado bajo dos licencias que dan un alto nivel de modularidad y que son permisivos:GPL y MPL.

Un de las características principales de esta plataforma es que puede ser ser aplicado en cualquier tipo dedominio. (Financiero, académico, comercio, gobierno, etc.).

1.5.1.1. Arquitectura

CentralKGS CA´s

RA1 RA2 RAN

Usuario NUsuario 2Usuario 1

KA

UKGS

CSP1

CSP2

Figura 1.5.1.1. Arquitectura de EuPKI

EuPKI, puede Operar un número diferente de Autoridades de Certificación, cada CA tiene asociado unCSP (Crypto Service Provider), la cual tiene una llave privada que es utilizada como marca en lasoperaciones de los procesos de la CA. La plataforma también puede manejar varias RA’s, cada unodefiniendo un dominio diferente (namespace), como tambien políticas de certificación diferentes. ElKGS (Key Generation Systems) esta conectado al resto del sistema para facilitar la operación delSoftware en la entidad final para la Generación de Llaves, Por otro lado el UKGS, interactúadirectamente con la CA (si un entorno en línea es utilizado) o indirectamente via RA’ss, El KA (KeyArchive), puede ser conectado al Central KGS para soportar la recuperación de llaves cifradas.


11

1.5.1.2. Certificación

El sistema CA, controla la funcionalidad común de las Autoridades de Certificación, que trabajan junto alos sistemas CSP, El sistema CA, puede “adquirir” las llaves publicas desde la entidad final o desde unaCentral de generación de llaves y distribuye la información en base a Directorios, también mantiene unalmacén denominado CA DB, para almacenar los Certificados, su Estado y la información relacionada ala entidad (con una referencia a una entrada en la RA).

La CA para certificar, trabaja además con subsistemas que le “ayudan” ya sea en el establecimiento deautenticaciones iniciales, o el compartimiento de llaves secretas entre la CA y cualquier entidad.

CA, también soporta requerimientos de registro y certificación en modo Batch o en linea, controlandopara esto el KGS, en la obtención de pares de llaves

1.5.1.3. Evaluación

El modelo planteado por euPKI, aunque parece robusto al principio, por el mismo hecho de soportarcualquier tipo de dominio es bastante ambiguo en sus definiciones ya específicas a la hora deimplementarlo.

El hecho de soportar diferentes espacios, hace que uno se “pierda” a la hora de su instalación, es tambiénnecesario contar con conocimientos regularmente buenos para ello.

El uso de módulos criptográficos “plug and play”, hace que no se ate a un solo algoritmo criptográfico,sino mas bien de ofrecer y poder seleccionar cualquiera, lógicamente esto adiciona una “marca”, delalgoritmo utilizado, en el propio certificado

Otra ventaja de este modelo es el de tener bien definido un KGS, para la generación del par de Llaves,así como el soporte también para la entidad final, con la disposición de un KGS de usuario.

Otra ventaja es que el modelo es de fuente abierta, por lo cual, la comunidad podria retroalimentar,mejorando el modelo.

1.5.2. Pretty Good Privacy – PGP

Es una aplicación informática de libre distribución, desarrollado por Phil Zimmerman [Zimm, 1994], ainicios de 1990.

PGP permite intercambiar ficheros y mensajes con confidencialidad, autenticación, integridad ycomodidad.

Para realizar esto, PGP utiliza criptografía de clave pública RSA, Diffie-Hellman o DSS para generarfirmas y cifrar claves, criptografía de clave secreta IDEA, CAST, TRIPLEDES y AES para el cifradodel documento propiamente dicho y la función hash MD5, SHA-1 para crear las huellas digitales que seemplean en la firma digital.


12


CA-Usuario

CA-Usuario

CA-Usuario

Figura 1.5.2.1. Arquitectura de PGP

PGP es un sistema descentralizado, en el que cada usuario se hace responsable de su archivo de clavespúblicas, denominado anillo, y es el propio usuario el que establece la confianza en la validez de dichasclaves.

Cuando un usuario necesita comunicarse con nuevos usuarios, podrá obtener sus claves a través depersonas en las que ya confía, las cuales podrán firmar y enviarle claves públicas de otros usuarios en losque ellos confiaban previamente, estableciendo así una cadena de confianza que se basa en las relacionespersonales.


PGP utiliza un formato propio de certificado que consta únicamente de un identificador del usuario (quecontiene su nombre y algún dato significativo y personal como la dirección de correo electrónico, sunúmero de teléfono o cualquier información que ayude a garantizar la unicidad del identificador), de unafecha de emisión y de la propia clave pública. Como en PGP no existen CAs el certificado es emitidopor el propio usuario propietario de la clave pública, y firmado inicialmente por él mismo. A estecertificado se le pueden añadir firmas de otros usuarios que se utilizarán como aval de validez. Lasencillez del certificado hace que en PGP se hable directamente de claves públicas y no se utilice lapalabra certificado.


El modelo de confianza utilizado en PGP, basado en las relaciones personales ha sido un punto a favorpara su rápida expansión. Este modelo, conceptualmente sencillo, no requiere que los usuarios esténregistrados en dominios de seguridad en los que se manejan complejas infraestructuras. Cualquierusuario que instale en su ordenador un software PGP puede “comunicarse” de forma segura con otrosusuarios.

Uno de los problemas que presenta el modelo de certificación de PGP, es que la confianza personal noproporciona garantías suficientes ante posibles litigios por uso fraudulento de claves y/o firmas digitales.

El proceso de revocación, puede actualizar claves revocadas, a partir de una dirección URL). Cuando laclave secreta o la contraseña utilizada para su protección se ven comprometidas, o cuando se sospechadel uso fraudulento de la propia clave pública por parte de otros usuarios.


13

1.5.3. Privacy Enhancement for Internet Electronic Mail – PEM

Se creó en 1991, a partir de las necesidades de transferir información criptográfica a través del correoelectrónico principalmente, el impulso fue, a través del grupo de trabajo IETF-PEM de la InternetSociety.

PEM, proporciona los servicios de integridad, autenticación y no repudio en origen y opcionalmenteconfidencialidad.

Lo habitual en PEM es utilizar algoritmos de clave secreta para el cifrado de los datos y algoritmos declave pública para la administración de claves y la gestión de firmas digitales.

Aunque no es obligatorio el uso de algoritmos de clave pública en PEM, es recomendable hacerlo paraaprovechar las ventajas que ofrecen este tipo de algoritmos en cuanto a la administración de claves serefiere, ya que, al contrario de lo que sucede con los algoritmos de clave privada, no es necesario uncanal de comunicación seguro para efectuar el intercambio de claves secretas.


PEM define una infraestructura de certificación basada en una organización jerárquica arborescente deAutoridades de Certificación.

IPR A

PC A PC A

C AAnonim o

C AO rg.

C AO rg.

C AR esid.

U s u a rioA n ó n im o

U s u a rioO rg a n iz a c io n a l

U s u a rioO rg a n iz a c io n a l

U s u a rioR e s id e n c ia l

Figura 1.5.3.1. Arquitectura PEM

En PEM, las CAs y los usuarios están organizados en un único árbol, en el cual los usuarios representanlas hojas. La raíz de árbol la ocupa la IPRA (Internet Policy Registration Authority). El principalcometido de IPRA es el de establecer la política global, la cual se aplicara a todos los procesos decertificación bajo esta jerarquía. IPRA certifica a las Autoridades de Certificación de Políticas, PCAs(Policy Certification Authorities), que definen políticas particulares dentro de la política global definidapor IPRA. Las PCAs certifican a otras CAs que se encargaran de certificar a usuarios finales o a otrasCAs que se encuentren por debajo en la jerarquía.


14

Autoridad de Registro de Políticas de Internet (IPRA)

- Registro de PCAs- Garantía de unicidad de nombres distintivos.- Corrección de nombres distintivos.- Convenios sobre nombres distintivos.- Gestión de CRLs.- Expedición de licencias de algoritmos de clave pública.

Autoridades de Certificación de Políticas (PCAs)

- Identidad de la PCA- Alcance de la PCA- Privacidad y seguridad de la PCA- Política de Certificación- Gestión de CRLs- Convenios de Nombramiento- Emisión de Negocios

Autoridades de Certificación (CAs)

Las CAs tienen como misión crear y asignar certificados. Aunque la recomendación X.509, imponepocas restricciones sobre las CAs, la implementación practica del sistema de certificación hallevado a la necesidad de establecer algún convenio. Por ejemplo, las CAS, deben mantener unabase de datos con los DNs de las entidades a las que certifican con el fin de garantizar la unicidadnominal. Las CAs deben establecer medidas de seguridad para proteger su clave secreta, estasmedidas pueden estar impuestas por su PCA. Las CAs deberán emitir y enviar CRLs a su PCA enlos periodos establecidos por esta. Las CAs podrán definir su propia política de registro de usuariossiempre que éste dentro de lo definido por su PCA.

Dependiendo del tipo de entidades que las CAs certifiquen, en PEM podemos distinguir tres tiposde CAs: CAs organizacionales, CAs Residenciales, CAs Personas

Usuarios y agentes de usuario

Como PEM es una especificación para correo electrónico, cuando hablamos de usuario PEM, enalgunos casos nos referimos a un agente de usuario UA (User Agent), término definido por larecomendación X.400, para referenciar al medio por el cual el usuario interactúa con el sistema demanejo de mensajes.


PEM utiliza la versión 1 del certificado X.509, y una versión modificada de la CRL versión 1.

Debido a la organización jerárquica de las Autoridades de Certificación definida en PEM en forma de unúnico árbol, en esta arquitectura existe siempre un punto de confianza común entre dos usuarios, que esla raíz de árbol IPRA. En PEM todos los usuarios están en posesión de la clave pública de IPRA, la cualles es facilitada como parte del procedimiento de registro o en el proceso de instalación del softwarePEM.

PEM no prevé el uso del Directorio X.500 para el almacenamiento de certificados y CRLs pero dejalibertad a las diversas entidades de su arquitectura para utilizarlo.


15

Cada usuario y AC de PEM conoce el conjunto de certificados que forman su camino de certificaciónhasta IPRA, ya que cuando una AC emite un certificado lo envía a su propietario incluyendo loscertificados que forman el camino de certificación desde el nuevo certificado hasta IPRA yopcionalmente algún certificado cruzado que la AC considere de interés.

El procedimiento habitual en PEM, es que los usuarios en el proceso de envió de mensajes incluyan encampos opcionales el certificado de la clave, pareja de la clave de firma, y en otros todos los certificadosque conforman su camino de Certificación hasta IPRA o hasta un nodo común en el árbol. De esta formael usuario receptor podrá validar la firma comenzando por el certificado de la PCA emitido por IPRA.

Un usuario PEM debería consultar regularmente las CRLs correspondientes, para tener la seguridad deque los certificados que intervienen en el proceso de validación no han sido revocados. PEM tambiéndescribe procedimientos para la consulta, obtención y almacenamiento de CRLs en las bases de datos dela PCAs.


La definición y creación de la infraestructura PEM ha representado, sin duda alguna uno de los hitos másimportantes en el desarrollo de entornos de seguridad en redes. A PEM se le deben muchas cosas, porejemplo su definición de mensaje cifrado utilizando criptografía de simétrica y asimétrica, se haconvertido en un estándar que utilizan la mayoría de las aplicaciones, el cual se conoce con el nombre demensaje envuelto. A PEM también se le debe la definición de un modelo de confianza basado enjerarquía de CAs que ha sido considerado el patrón de los modelos que aparecieron con posteridad.

A pesar del gran avance que supuso PEM, su arquitectura presenta una serie de deficiencias. Algunas deestas deficiencias derivan de la utilización de la versión 1 del certificado. Las experimentaciones conPEM han servido para identificar estas deficiencias y buscar soluciones, algunas de las cuales ya se hanimplementado en la versión 3.

En PEM no se puede determinar directamente a que tipo de entidad pertenece un certificado, ya que estainformación, que puede resultar de especial relevancia, solo se puede obtener de forma indirectaobservando el DN del propietario del certificado.

La centralización de las CRLs en las bases de datos de las PCAs puede provocar problemas de gestión,en el caso de que estas listas crezcan considerablemente.


16

2. PARTE II, MODELO PROPUESTO DE PKI

Luego del análisis y evaluación realizada en el anterior acápite, se propone un modelo de Infraestructura deClave Pública, basado en el uso del certificado X.509 versión 3, y CLR’s versión 2, en el que se definenalgunas características comunes y algunas nuevas, con el objetivo de cubrir las deficiencias detectadas enotros modelos y de garantizar la interacción con el usuario, en un ámbito nacional, y porque no decirlo,también internacional.

La adopción generalizada del certificado X.509 por parte de los distintos organismos, empresas einstituciones a nivel internacional que han desarrollado distintos modelos, ha convertido a este certificado enel estándar de facto en el campo de la certificación.

El modelo propuesto, toma como base la utilización del certificado X.509 en su versión 3, y unaorganización jerárquica de AC’s, que permitirá, un mejor control y seguimiento de la certificación que sevayan realizando.

Los modelos jerárquicos son los que mejor se adaptan a la naturaleza organizacional de los usuarios de estasinfraestructuras, proporcionando a su vez, un sistema de confianza sólido y robusto.

PGP PEM EuPKI MODELOPROPUESTO

Criptosistema Utilizado RSACAST-IDEA-TripleDESMD5, SHA-1

RSADES

Definido por elDominio

RSAAES

SHA-256, SHA-512Soporte Certificados X.509 NO SI SI SISoporte Directorio X.500 NO NO NO OPCIONALTipo Organización

Jerárquica NO SI SI/NO SITipos de Autoridades Usuarios IPRA

PCACA

CARA(CKGS, UKGS,CSP, KA)

PCACARA

Aplicaciones Soportadas Correo ElectrónicoTransaccionesElectrónicase-administración

CorreoElectrónico

ComercioElectrónico,e-administración

Correo ElectrónicoTransaccionesElectrónicase-administración

Tabla 2. Características principales del modelo Propuesto


17

2.1. Especificación de la Arquitectura PKI

PCA

CA

RA RA RA RA

CACACA

Usuario Usuario Usuario Usuario

Figura 2.1. Arquitectura del Modelo Propuesto

El Modelo está formado por un solo árbol, de la cual el PCA es el nodo raíz, y es el nodo que define laspolíticas de certificación, para todo el modelo, sin embargo esto no significa que no existan subpoliticaspropias de una AC en particular (e.j. otros documentos de respaldo para registro)

En este caso si existieran varias AC’s, una podría tener alcance internacional y las demás nacionales, de lascuales podrían subdividirse por tipo de organización (ejemplo Universidad, sector público, sector privado,Banca, y otros). A este nivel, solo existirá una sola política de certificación (la cual podría ser una simple ocompuestas por varias subpoliticas, que estarán aplicados en un ámbito nacional), siguiendo con loslineamientos de sencillez y confiabilidad por parte del usuario.

Para el modelo propuesto, se utiliza los campos de extensión de los certificados X.509, los cuales podránincluir información sobre el camino de certificación que existe, desde el certificado hasta la raíz de su árbol(para el caso en que se tenga varias AC’s), lo que facilita de sobremanera, pues se conocería de antemano elcamino o los certificados necesarios en cualquier proceso de verificación.

Otro objetivo del Modelo es respecto al almacenamiento y localización de certificados y CRLs, incluyendola utilización del Directorio X.500 de forma opcional.

2.2. Componentes Básicos de la PKI

2.2.1. PCA - Policy CAs

Para que un entorno de certificación funcione correctamente es necesario definir una serie de reglas queindiquen la forma de aplicar los certificados. Este conjunto de reglas que constituyen la política decertificación, tiene que estar definido por las autoridades reconocidas en el entorno. Por lo tanto, las CAsactuarán bajo una determinada política de certificación. Estas CA’s específicas suelen denominarsePCA’s (Policy CAs).


18

Una PCA puede estar representada por una empresa única, o una institución, pero en nuestro modelo loaconsejable y recomendable, es que estas estén definidas por un grupo de instituciones del mismo medio.(ej. Adsib, Ministerio de Educación y Cultura, Cámara de Comercio, Universidad, etc). Todo con el finde definir el entorno, alcance y medios de las políticas de seguridad en la plataforma.

Una política de seguridad establece y define la dirección de máximo nivel de una organización sobreseguridad de información, así como los procesos y principios para el uso de la criptografía. Por logeneral, incluye declaraciones sobre cómo gestionará la empresa las claves y la información critica, yestablecerá el nivel de control requerido para afrontar los niveles de riesgo.

PCA

Politicas de Seguridad, Normas y Procedimientos

Privacidad yseguridad de la

PCA

RepositorioDocumentos

Identidad PCA

Políticas deCertificación Gestión de CRLs Otras Políticas

RepositorioLlaves

Figura 2.2.1. Especificación de la PCA

- Identidad de la PCA. Se deben dar a conocer el DN (Distinguided Name) de la PCA, informaciónque permita establecer contacto personal (dirección postal, número de teléfono, opcionalmentenúmero de fax y dirección de correo electrónico), fecha de publicación de su informe de política yduración prevista.

- Privacidad y seguridad de la PCA. La PCA deberá especificar las medidas técnicas y losprocedimientos de seguridad que seguirá en la generación y protección de sus claves. También podráimponer requisitos de seguridad sobre las CAs certificadas y deberá dictar medidas de seguridadpara proteger la información recogida en los procesos de certificación de las CAs subordinadas.

- Mecanismos de protección. Se deben definir los requerimientos hardware y software necesariospara proteger la infraestructura de una CA.

- Políticas de Certificación. Cada PCA deberá indicar la política y procedimientos que gobiernan lacertificación de las CAs subordinadas, y transitivamente también a los usuarios o CAs que seancertificados por las anteriores. Por ejemplo, se deberá especificar el procedimiento de registro, elperíodo de validez de los certificados, tamaño de las claves, etc.

- Gestión de CRLs. Se especificará la frecuencia de emisión de CRLs para el subárbol bajo la PCA,la dirección en la que las CAs subordinadas deberán depositar las CRLs emitidas, la dirección deconsulta de CRLs, los procedimientos adicionales como almacenamiento de CRLs antiguas y lasposibles ayudas que pueda tener de CAs para mantener y gestionar las CRLs.


19

- Otras Políticas. Se puede añadir cualquier otra información que deban conocer los usuarios,teniendo en cuenta que los documentos de política se consideran casi inmutables y de largaduración.

2.2.2. CA - Certificate Authority

Es una entidad o servicio que emite certificados. El sistema de CA es la base de confianza de una PKI,es uno de los pilares fundamentales de la plataforma.

Como tal es un conjunto de herramientas y archivos asociados, que permiten comprobar la identidad deuna persona, servidor o programa. Actuaría como una especie de notario electrónico.

Su función principal es el de avalar los datos de cualquier certificado emitido por la PKI, el problema sila CA avala, quien le aval a ella?, para el caso de nuestro modelo, si bien se puede partir de una entidad“fiable” y la creación de certificados raíz autoafirmadas, esto no es recomendable, lo correcto y buencamino es ser avalada por una Entidad que tuviera reconocido prestigio y confianza internacionalmente.(Ej. Verisign, la cual se autoafirma su certificado)

Cada certificado emitido por una AC debe estar firmado por una AC de mayor grado en el esquemajerárquico de autoridades certificadoras, formándose así una cadena de certificados, en los que unas ACse avalan a otras hasta llegar a la AC superior, que se avala a sí misma.

Esta jerarquía de firmas y la cadena con ella formada están contempladas en el estándar X.509 v3, queindica la forma correcta de realizar estas cadenas de certificaciones.

El Certificado Digital vincula pues indisolublemente a una persona o entidad con una llave pública, ymediante el sistema de firma digital se asegura que el certificado que recibimos es realmente de lapersona que consta en el mismo. El sistema de firma digital liga un documento digital con una clave decifrado.

Características recomendables de una CA:

- Independencia (ausencia de interés financiero o de otro tipo en las transacciones subyacentes).- Recursos y capacidad financiera para asumir la responsabilidad por el riesgo de pérdida- Experiencia en tecnologías de clave pública y familiaridad con procedimientos de seguridad

apropiados.- Longevidad (tiempo de conservación de certificados).- Aprobación del equipo y los programas utilizados por terceros.- Mantenimiento de un registro de auditoria y realización de auditorias por una entidad

independiente.- Existencia de un Plan de Contingencia para casos de emergencia- Selección y administración del personal.- Disposiciones para proteger su propia clave privada- Seguridad interna.- Disposiciones para suspender las operaciones, incluida la notificación a los usuarios.- Garantías y representaciones.- Limitación de la responsabilidad.- Seguros.- Capacidad para intercambiar datos con otras autoridades certificadoras.- Procedimientos de revocación.


20

CA

Sistema deGeneración de

Claves

Aplicación de Politicas de Seguridad, Normas y Procedimientos

Generación deCertificados

Certificación

Publicacion deCRL´s

Procedimientode

Revocación

Repositorio deLlaves

Repositorio deCertificados

Sistema deDistribución

deCertificados

CRL´s

Figura 2.2.2. Especificación de la CA

2.2.3. RA - Registration Authorities

Una RA, proporciona el interfaz entre el usuario y el CA. Captura y autentifica la identidad de losusuarios y entrega la solicitud de certificado al CA. La calidad de este proceso de autentificaciónestablece el nivel de confianza que puede otorgarse a los certificados.

Las RA’s no realizan ninguna labor de certificación, su funcionalidad es la de registrar a las entidades ousuarios finales. Es decir, estas Autoridades se encargaran de garantizar que el binomio formado por unaentidad y el par de claves que la identifica, sólo este registrado una sola vez.

Las Autoridades de Registro estarán asociadas a las distintas Autoridades de Certificación que definen lajerarquía de un árbol, tanto a las Autoridades del nodo PCA, como a las CA’s normales.

Aunque en el Modelo las RA’s son entidades lógicas separadas de las CAs, en la práctica pueden ser unamisma entidad física, con un mismo DN (Distinguished Name). Es decir, una CA puede tener asociada yubicada físicamente en el mismo sitio, a una RA que se encargue del registro de las entidades a las quecertifica. Para garantizar la validez del procedimiento de registro, cada RA deberá tener un par de clavesasimétricas, con la clave pública certificada por una CA que sea un punto de confianza de todas las CA’spara las que realiza funciones de registro. Cuando una RA y una CA coincidan físicamente, la RA podráconsiderar el par de claves de la CA y su certificado como propios.

Las RA’s pueden abrir varias oficinas regionales dispersas por todo el país, llegando hasta los usuariosen los sitios más remotos, mientras que la AC se limitaría así a certificar a todos los usuarios aceptadospor las RA’s dependientes de ella. Gracias a esta descentralización se agiliza el proceso de certificacióny se aumenta la eficacia en la gestión de solicitudes.


21

Una PKI incluirá una o varias Autoridades de Registro para certificar la identidad de los usuarios; una ovarias Autoridades de Certificación que emitan los certificados de clave pública; un repositorio decertificados, accesible vía web u otro medio, donde se almacenen los certificados; las listas derevocación de certificados (CRL), donde se listan los certificados suspendidos o revocados; y, porsupuesto, los propios certificados.

RA

Aplicación de Politicas de Seguridad, Normas y Procedimientos de Registro

Sistema de Registroen Linea

Repositorio deSolicitudes

Registro en Linea (Web) Registro Físico

Sistema de RegistroFísico

Sistema de VerificaciónAutomática de Datos

Repositorio deSolicitudes

Verificación manual de Datos - Presentación de Documentos

Figura 2.2.3. Especificación de la CA

2.3. Funciones de la PKI

Las funciones que la plataforma deberá ofrecer son las siguientes:

Usuario

Base de Datos

Directorio deServicios

Autoridad deCertificación

Autoridad deRegistro

Generaciónde Llaves

2. Datos del Usuario

5. Publicación

6. Certificado de Clave Pública

1. -Verificacióny Validación

3. Clave Pública

4. Certificado

Figura 2.3. Funciones de la PKI


22

2.3.1. Atención de Solicitud de Certificados

La emisión de Certificados de Identidad Personal exigen el reconocimiento previo de todos aquelloselementos característicos y únicos que son propios del solicitante; a estos caracteres se les denomina“identificadores intrínsecos” (fotografía, firma manuscrita, huellas dactilares, timbre de voz, fondo deojo, marcas de nacimiento, etc.). Según el número e importancia de los identificadores intrínsecos quelas Autoridades de Registro verifican, registran y archivan para la emisión de sus certificados deidentidad, diferente será la confianza que éstos puedan ofrecer.

Una Autoridad de Registro puede requerir sólo el Carnet de Identidad y comprobar que la fotografía y laapariencia del solicitante coinciden, en el caso de personas, en el caso de equipos electrónicos,servidores, computadores, podría ser además algunas características del equipo (ej. Nro de Serie).

2.3.1.1. Generación y Registro de Claves.

La generación y registro de claves, es también un pilar fundamental, y cualquiera que desee firmardigitalmente mensajes o recibir envíos cifrados y/o firmarlos, debe poseer un par de claves dentro dealgún criptosistema de clave pública. Es más, otras entidades de la red como son las estaciones detrabajo, los servidores, las impresoras, etc., también pueden (y deben) tener sus pares de claves; de lamisma forma que lo harán las personas.

Dado que la identidad de cada entidad se basa en el secreto de una de las claves, la privada, cadausuario deberá generar por sus propios medios su par de claves, para el modelo se propone unSubsistema para la generación de Claves por parte del usuario, es decir una aplicación donde elusuario o entidad final pueda llenar los datos de la Solicitud del Registro y además pueda genera susclaves, lógicamente la aplicación será también de fuente abierta.

También el modelo considera la disponibilidad de que las entidades puedan generar sus claves através de un portal o pagina web (lógicamente con elementos o componentes que se ejecuten en elequipo del Cliente)

En cualquier caso, las claves privadas nunca deben viajar por la red y habrán de ser distribuidas através de canales no telemáticos de seguridad y confidencialidad probadas.

Una vez, completado la solicitud y generación las claves, la entidad final debe “registrar” su clavepública ante la Autoridad de Certificación a través de una Autoridad de Registro aceptada dentro delescenario. Para la inscripción sólo tiene que enviar su clave pública y, el documento digital desolicitud firmado con dicha clave.

Para completar el proceso de inscripción, el solicitante deberá:

- o bien enviar otro Certificado Digital de Identidad expedido por alguna otra Autoridad deCertificación aceptada, o bien

- deberá enviar un documento físico válido dentro de los procedimientos administrativoshabituales en el que asume la responsabilidad del compromiso indicado en la solicitud digitalque ha enviado.

2.3.2. Emisión de Certificado

Satisfechas las condiciones marcadas por la Autoridad de Registro en su documento público de Políticade Emisión de Certificados incluida en su Política de Seguridad, esta autoridad envía todos losdocumentos a la Autoridad de Certificación, la cual podrá generar el certificado correspondiente y


23

devolver al solicitante un certificado digital que atestigua la validez de su clave pública para actuardentro del sistema.

El certificado que se utiliza en el Modelo, es el certificado X.509 en su versión 3. Esto es conveniente deutilizar por la definición de extensiones que tiene y poder incluir información relativa a la política decertificación, al uso del certificado y a la identificación del camino de certificación.

Estados de los Certificados:

- Activo: Cuando la fecha en curso cae dentro del intervalo de vigencia de un certificado.

- Suspendido: Certificado anulado temporalmente, para ello, la Autoridad de Certificación pasa alestado de Suspendido. Con ello no se invalida de forma irreversible el certificado, sino que se leretira de circulación hasta que se le vuelva a dar el estado de Activo.

- Revocado: Cuando las condiciones que llevaron a la emisión de un certificado cambian antes de queéste expire, y son de importancia suficiente, la Autoridad de Certificación deberá anularlo; para ello,emite un segundo certificado especial, denominado “de revocación”, por el cual, desde ese instantedesautoriza al certificado previo y lo hace de un modo irreversible.

- Caducado: Este es el estado final de cualquier certificado y se produce cuando la fecha en curso esposterior a la fecha de caducidad indicada en el propio certificado. El estado de “certificadocaducado” no le resta valor histórico ya que, mientras estuvo activo, las operaciones en las queparticipó eran perfectamente válidas.

La Autoridad de Certificación debe tener en todo momento registrado cuales son los estados en los quese encuentran sus certificados. En la literatura informática se habla de las “Listas de CertificadosRevocados” o CRL’s, como unas listas “negras” en las que la entidad, pública a los cuatro vientos cualesson los certificados que ha anulado para, con ello, desentenderse de las responsabilidades que pudieranacarrear la utilización y/o aceptación por parte de alguna entidad de los mencionados certificados.

Según la importancia de las transacciones que realicen las entidades basándose en los certificadosdigitales que utilizan, algunas veces no será necesario que consulten si las credenciales presentadas estántodavía vigentes en el momento de la transacción, pero habrá otros casos en los que este requisito seaabsolutamente necesario, por lo que la entidad se pondrá en contacto con la Autoridad de Certificación yle consultara por el estado de vigencia (actividad) de ese certificado en concreto (número de referencia).

2.3.3. Almacenamiento en la CA de llaves

La Autoridad de Certificación, se encargan de verificar las condiciones que a parecen en sus políticaspúblicas de seguridad y, posteriormente, de emitir y seguir el ciclo de vida de los certificados que emite.En cuanto a esta última actividad, la Entidad de Certificación es “firmador” digital, para lo cual debendisponer de una clave privada que sólo conocen ellos y que custodian con niveles de seguridad iguales osuperiores a los declarados públicamente.

Para conseguir este nivel de seguridad para las claves privadas de la CA, éstas se generan y almacenanpermanentemente en unidades hardware de alta seguridad (recomendable), sometidas a sofisticadasmedidas de seguridad física y dentro de entornos a prueba de intrusión electrónica, que es lorecomendado y aconsejable. A dichas unidades se las denomina “Unidades de Firmado de Certificados”,CSU. Estas unidades son, por su naturaleza, irrepetibles, y están diseñadas para que, ante la sospecha decualquier intento de intromisión, las claves y demás informaciones relacionadas con ellas se destruyanantes de que puedan ser alcanzadas desde el exterior.


24

Las CSUs están físicamente apantalladas para evitar ataques electromagnéticos, y tienen un amplioconjunto de sensores tolerantes a fallos permanentemente a la escucha de cualquier síntoma que puedaindicar la existencia de un ataque.

Los administradores de la Autoridad de Certificación no tienen acceso a la clave privada, sino a unequipo hardware que firma los documentos que éstos le entreguen.

Lamentablemente, por el alto costo de estos equipos, y la inexistencia de espacios físicos para ello, eneste modelo propuesto no se considera este punto, sino más bien de la existencia de una Base de datosreferente a ella, con la protección y seguridad, que nos brinda los algoritmos criptográficos. También lautilización de Software Libre para la implementación del modelo, hace que se utilice una aplicaciónespecial para el firmado de un Certificado.

2.3.4. Servicios de Directorio

El Modelo está pensado para operar, tanto en entornos en los que se utiliza el Directorio X.500, como enaquellos en los que no se utiliza. En aquellos entornos en los que se utiliza el Directorio X.500, elmecanismo de almacenamiento y obtención de certificados y CRLs se simplifica.

Cada entidad de una infraestructura queda unívocamente identificada por su DN X.500 que indica cuáles su entrada en el Directorio. La recomendación X.500 define los atributos necesarios para almacenar lainformación relativa a certificación en el Directorio, de forma que cada entidad puede almacenar suscertificados en la correspondiente entrada. Si la entidad es una CA, además de sus certificados, en suentrada puede almacenar las CRLs asociadas. Cuando una entidad necesita obtener un certificado de otraentidad o una CRL, una vez identificado el nombre de la otra entidad, puede localizar la informaciónbuscada en la entrada del Directorio de la otra entidad y la puede extraer, ya que estos atributos seconfiguran con permiso de lectura para todo el mundo. En el caso de utilización del Directorio comolugar de almacenamiento de certificados y CRLs es recomendable que el acceso al Directorio sea seguro.

La utilización del Directorio X.500, para este modelo es opcional, pro la razón de que se tienenaplicaciones un poco mas seguras (ej. Base de Datos en MySQL).

En el Modelo se propone, que cada Autoridad de Certificación tenga asociado un servidor decertificados y CRLs que permita la obtención por parte de cualquier usuario, del certificado de la propiaCA, de las CRLs que tenga asociadas y de cualquier certificado que haya sido emitido por ella. Esteservidor obtendrá los certificados de una base de datos local asociada a la CA, o bien del DirectorioX.500.

Lo usual en las distintas aplicaciones que incorporan servicios de seguridad, es que se produzca unintercambio inicial de los certificados de las entidades comunicantes. Otro aspecto relacionado con elalmacenamiento de certificados y CRLs, es que los usuarios finales generalmente realizancomunicaciones con un grupo limitado y más o menos estable de participantes.

2.3.5. Políticas de Certificación

Ya se abordo el tema de las Políticas de Seguridad que tiene que ser definidas por la PCA, sin embargotambién y de acuerdo al dominio de aplicación se podría tener algunas Políticas de Seguridad Propias decada CA.

- Procedimientos para el registro de usuarios. Se deben definir los mecanismos para laidentificación y aceptación de usuarios finales.


25

- Procedimientos para la gestión de claves. Se deben definir aspectos relacionados con lageneración, distribución y validez de las claves. También se deben especificar los mecanismos dedistribución permitidos, el tamaño de las claves y su período de validez.

- Registro y auditoria. Se deben definir los mecanismos necesarios para registrar y auditar loseventos y la información que resulte necesaria para garantizar la protección de una CA y losusuarios que dependen de ella.

2.3.6. Servicios de Certificación

Uno de los mecanismos más utilizados en entornos de seguridad, y que más ligado se encuentra a losmodelos de certificación basados en la utilización de claves asimétricas, es la firma digital. El proceso deverificación de una firma digital implica la utilización de la correspondiente clave pública.

Para confiar en la validez de esta clave es necesario comprobar la validez de su certificado. El uso declaves públicas para proporcionar el servicio de confidencialidad, bien directamente, o bien utilizandouna cubierta digital, implica también la validación del correspondiente certificado. En general se puededecir, que cualquier proceso de verificación o validación de mecanismos de seguridad basados entécnicas criptográficas asimétricas, implica la validación del certificado de la correspondiente clavepública, proceso a que a su vez lleva implícita la validación de una cadena de certificados que garanticeel establecimiento de la confianza entre dos entidades.

El proceso de validación o certificación se puede realizar de la siguiente manera

- Obtención del certificado a validar o certificar- Determinación de la posibilidad de establecer la confianza entre las entidades implicadas.- En caso de poder establecer la confianza, identificación de los certificados necesarios en el

proceso.- Obtención de los certificados identificados.

Como todos los usuarios operaran bajo la misma política siempre se puede establecer la confianza entreellos. El nodo común en el árbol será siempre la CA que los certifica a todos, y el certificado en el quefinaliza el proceso de validación es el certificado autofirmado por la propia CA.

2.3.7. Servicios de Revocación de Certificados

Los certificados que no han vencido su período de validez pueden ser revocados por la Autoridad quelos emitió. La principal causa de la revocación es que se haya detectado un compromiso de la clavesecreta asociada, aunque pueden existir otros motivos, como pueden ser el cese de la actividad para queel certificado haya sido emitido, que el propietario del certificado cambie de papel dentro del grupo ocambie de afiliación, o simplemente, que la CA emisora decida revocarlo. En cualquier caso la decisiónde revocar un certificado debe ser tomada por la CA emisora, pero se permite a cada usuario que puedasolicitar la revocación de su propio certificado. En el caso de que la solicitud de revocación de uncertificado provenga de una entidad que no es la propietaria, es responsabilidad de la CA comprobar losmotivos por los que se solicita la revocación.

Al igual que la renovación de un certificado de una CA implica la revocación de todos certificados quedependen del mismo, la revocación del certificado de una CA produce el mismo efecto, con la diferenciade que si el certificado revocado no es sustituido por uno nuevo.


26

2.4. Escenarios de Aplicación

Los escenarios de aplicación del modelo puede ser varias: (Comunicaciones entre servidores, Correoelectrónico, Intercambio Electrónico de Datos (EDI), Redes Privadas Virtuales (VPN)).

Pero el modelo propuesto esta mas orientado a lo que es el Intercambio Electrónico de Datos, o Seguridad enlas transacciones electrónicas específicamente en las Entidades Estatales.


27

3. PARTE III, INSTALACION E IMPLEMENTACION

3.1. Software a Utilizar

Software Propósito Sitio - urlGNU/Linux Plataforma de la implementación

del Modelowww.linux.org

Apache WWW Servermodssl SSL/TLS Apache moduleShared Memory Allocation-mm

Como servidor de paginas Web,solicitud, registro, listado de CLR’s

www.apache.orgwww.modssl.orgwww.ossp.org/pkg/lib/mm/

OpenSSL SSL/TLS software Asegurar las transacciones, publicarpaginas web seguras (https://)

www.openssl.org

OpenLDAP LDAP software Para soporte de Directorio X.500(opcional)

www.openldap.org

MySQL Servidor de Base de Datos www.mysql.comOpenCA Para soporte de Servidor CA y

Servidor RAwww.openca.org

Perl interpreter Para compilar todas lasherramientas

www.perl.org

Modulos perl (CPAN) Algunas librerías y módulos queson necesarias durante lainstalación de los diferentesmódulos.

www.cpan.org

Linux, es un Sistema Operativo libre, el cual podemos utilizarlo, para la instalación utilizaremos laversión de Red Hat 9.

SSL es un protocolo seguro de Internet inventado por la Empresa NetScape, No es exclusivo delComercio Electrónico, por el contrario sirve para cualquier comunicación vía protocolos TCP/IP y, porlo tanto, también para transacciones administrativas. Este protocolo esta implementado por defecto entodos los navegadores. Se instalara la versión 0.9.8 de OPENSSL:

Apache, es uno de los más extendidos servidores de Internet, se instalara la versión Apache_1.3.33

Mod_ssl, es un modulo complemento a lo que es el servidor Apache adicionando a este característicasde seguridad, Mod_ssl-2.8.23-1.3.33

MySQL, es un servidor de Base de Datos, flexible y potente, se utilizar la versión mysql-standard-4.0.20-pc-linux-i686.

OpenCA, es un servidor para Autoridades de Certificación, se utilizara la versión openca-0.9.2.2

MM, son módulos para compartir memoria, que son necesarios en ambientes seguros, Mm_1.3.1

La instalación deberá realizarse según el orden establecido líneas mas abajo:

1. Openssl-0.9.82. Mm_1.3.13. Mod_ssl-2.8.23-1.3.334. Apache_1.3.335. MySQL-standard-4.0.20-pc-linux-i686.6. OpenCA-0.9.2.2

http://www.linux.org

http://www.apache.org

http://www.ossp.org/pkg/lib/mm/

http://www.openssl.org

http://www.openldap.org

http://www.mysql.com

http://www.openca.org

http://www.perl.org

http://www.cpan.org


28

3.1.1.Sistema Operativo

Para la instalación e implementación de la PKI, se utilizara Linux Red Hat, en su versión 9, lainstalación al ser sencillo no necesita de mas comentarios, eso si la Instalación se lo realiza con soloalgunos componentes mínimos, No se instala mod_ssl, no se instala openssl, entre otros.

3.1.2. OPEN SSL

La instalación es sencilla y no requiere mayores explicaciones,

# cd openssl-0.9.8# ./config# make# make install# ln –s /usr/local/ssl/bin/openssl/ /usr/bin/openssl

3.1.3. MM - Shared Memory Allocation

# cd mm_1.3.1# ./configure --disable-shared# make# cd ..

3.1.4. MOD_SSL

# cd mod_ssl-2.8.23-1.3.33# ./configure \--with-apache=../apache_1.3.33 \--with-ssl=../openssl-0.9.8 \--with-mm=../mm_1.3.1 \--withprefix=/usr/local/apache# cd ..

3.1.5. APACHE www SERVER

# cd apache_1.3.33# make# make certificate# make install

Comprobamos la instalación del servidor apache

# /usr/local/apache/bin/apachectl start

http://localhost

# /usr/local/apache/bin/apachectl stop

Comprobamos la instalación con SSL

# /usr/local/apache/bin/apachectl startssl

https://localhost

http://localhost


29

3.1.6. MySQL

# groupadd mysql# useradd -g mysql mysql# cd /usr/local# mv mysql-standard-4.0.20-pc-linux-i686 mysql# cd mysql# scripts/mysql_install_db --user=mysql# chown -R root .# chown -R mysql data# chgrp -R mysql .# bin/mysqld_safe --user=mysql &

3.1.7. OpenCA

Para instalar el servidor CA, nos creamos un archivo con las siguientes características y lo ejecutamos,como Autoridad de Certificación:

Archivo ./configure.redhat.ca

#!/bin/shPREFIX=$1VER=0.9.1

if [ -z "${PREFIX}" ] ; thenPREFIX=/usr/local/openca.${VER}

fi

./configure \--prefix=${PREFIX} \--with-httpd-user=userpki \--with-httpd-group=userpki \--with-org="PKIBOL Srl." \--with-openca-prefix=${PREFIX}/openca \--with-etc-prefix=${PREFIX}/openca/etc \--with-httpd-fs-prefix=${PREFIX}/httpd \--with-module-prefix=${PREFIX}/modules \--with-openssl-prefix=/usr/local/ssl \--with-engine=no \--with-web-host=www.pkibolivia.ca.org \--with-ca-organization="PKIBOL" \--with-ca-country=BO \--with-ca-locality=Chuquisaca \--with-ca=${PREFIX}/ca \--with-ca-htdocs-fs-prefix=${PREFIX}/ca-htdocs \--with-ca-cgi-fs-prefix=${PREFIX}/ca-cgi \--with-pub-htdocs-fs-prefix=${PREFIX}/pub-htdocs \--with-pub-cgi-fs-prefix=${PREFIX}/pub-cgi \--with-ldap-port=389 \--with-ldap-root="cn=userpki,o=pkibolivia,c=BO" \--with-ldap-root-pwd="password" \--enable-ocspd \

http://www.pkibolivia.ca.org


30

--enable-db \--with-db-type=mysql \--with-db-name=openca \--with-db-host=localhost \--with-db-port=3306 \--with-db-usr=openca \--with-db-passwd=pki_ca_password \--with-hierarchy-level=ca \--with-service-mail-account="[email protected]"

# ./configure.redhat.ca# make install-ca

http://www.pki_bolivia.org:1010

Instalamos OpenCA, pero como una Autoridad de Registro:

Archivo ./configure.redhat.ra

#!/bin/sh

PREFIX=$1VER=0.9.1

if [ -z "${PREFIX}" ] ; thenPREFIX=/usr/local/openca.${VER}

fi

./configure \--prefix=${PREFIX} \--with-httpd-user=userpki \--with-httpd-group=userpki \--with-org="PKIBOL Srl." \--with-openca-prefix=${PREFIX}/openca \--with-etc-prefix=${PREFIX}/openca/etc \--with-httpd-fs-prefix=${PREFIX}/httpd \--with-module-prefix=${PREFIX}/modules \--with-openssl-prefix=/usr/local/ssl \--with-engine=no \--with-web-host=www.pkibolivia.ra.org \--with-ca-organization="PKIBOL Srl." \--with-ca-locality=Chuquisaca \--with-ca-country=BO \--with-ra=${PREFIX}/ra \--with-ra-htdocs-fs-prefix=${PREFIX}/ra-htdocs \--with-ra-cgi-fs-prefix=${PREFIX}/ra-cgi \--with-pub-htdocs-fs-prefix=${PREFIX}/pub-htdocs \--with-pub-cgi-fs-prefix=${PREFIX}/pub-cgi \--with-ldap-port=389 \--with-ldap-root="cn=userpki,o=pkibolivia,c=BO" \--with-ldap-root-pwd="password" \--with-ldap-host=www.pkibolivia.ra.org \

http://www.pki_bolivia.org:1010

http://www.pkibolivia.ra.org



31

--enable-ocspd \--enable-dbi \--disable-rbac \--with-db-type=mysql \--with-db-name=openca \--with-db-host=localhost \--with-db-port=3306 \--with-db-usr=openca \--with-db-passwd=pki_ra_password \--with-hierarchy-level=ca \[email protected]

# ./configure.redhat.ra# make ra

Luego de todo el proceso de instalación se deberá configurar algunos archivos que nos permitiránmejorar la seguridad de nuestra plataforma

Editar el archivo /usr/local/apache/conf/httpd.conf adicionando dos paginas virtuales.

<IfDefine SSL>Listen 80Listen 443

Listen 1010Listen 1011</IfDefine>

ServerAdmin webmaster@pki_bolivia.org

<VirtualHost _default_:1010>DocumentRoot "/usr/local/openca.0.9.1/ca-htdocs"ScriptAlias /cgi-bin/ "/usr/local/openca.0.9.1/ca-cgi/"ServerName www.pkibolivia.ca.orgServerAdmin [email protected] /usr/local/openca.0.9.1/logs/ca_ca-error_logCustomLog /usr/local/openca.0.9.1/logs/ca_ca-access_log common</VirtualHost>

<VirtualHost _default_:1011>DocumentRoot "/usr/local/openca.0.9.1/ra-htdocs"ScriptAlias /cgi-bin/ "/usr/local/openca.0.9.1/ra-cgi/"ServerName www.pkibolivia.ra.orgServerAdmin [email protected] /usr/local/openca.0.9.1/logs/ra_ra-error_logCustomLog /usr/local/openca.0.9.1/logs/ra_ra-access_log common</VirtualHost>

http://www.pkibolivia.ca.org



32


33


34

4. PARTE IV, CONCLUSIONES Y RECOMENDACIONES

4.1. Conclusiones

La consideración de una buena Infraestructura de Clave Pública es de gran relevancia, pues esto podrádelimitar el marco de acción de las transacciones realizadas.

Es necesario introducir y reglamentar adecuadamente a las denominadas Autoridades de Certificacióncomo emisoras de Certificados Digitales que den fe de que los usuarios poseen ciertos atributos y lascalificaciones necesarias para realizar ciertas transacciones ya sean estas administrativas y/oelectrónicas.

A falta de leyes y reglamentaciones en nuestro país, es necesario iniciar el estudio de las posiblesnormativas que deban aplicarse a los certificados digitales, firmas, criptografía así como también, laregulación de las Autoridades de Certificación, y sus características que conllevan. Aunque ya se tengaun borrador del Ante proyecto de Ley.

Es muy importante la base de los certificados X.509, y algunas de sus extensiones, para el planteamientodel modelo, y los procedimientos a seguir para la implantación del modelo.

La utilización de mecanismos de seguridad basados en criptografía de clave pública conlleva lanecesidad de establecer un sistema de certificación que garantice la propiedad de las claves. Los sistemasde certificación que ofrecen un esquema de confianza más robusto, son aquellos que basan la confianzaen terceras partes, las cuales reciben el nombre de Autoridades de Certificación.

Así mismo la utilización de las Firmas Digitales, son de vital importancia, para asegurar lastransacciones realizadas, a través de las redes, interconectadas, puestas aseguran y minimizan losriesgos, de modificación y autenticación de las entidades involucradas en dicha transacción.

Cuando los entornos de certificación engloban a un número de entidades significativo, es necesarioplantearse la necesidad de distribuir las tareas de certificación entre varias Autoridades. En el caso deexistir varias Autoridades, éstas tienen que organizarse entre sí.

No es posible, definir una PKI de forma global y orientada a todos los ámbitos de transacciones, sinomás definir estos procedimientos a sectores específicos o particularizados.

El planteamiento del modelo, es una novedad en nuestro país, debido a la inexistencia de estos, ylógicamente a la falta de leyes que normen y reglamenten este tipo de tecnología.

4.2. Recomendaciones

Que el gobierno, se encargue de promover la creación y difusión de contenidos tecnologicos, para elmismo bienestar de las Entidades Estatales.

Formar un Grupo investigativo sobres estas tecnologías y aprovechar el máximo del software libre parael beneficio de nuestras entidades estatales.

Encontrar o crear un ente coordinador, para la implementación de una Infraestructura de Clave Publica,o posiblemente asignar esto a algunos proyectos ya existentes (ej. Adsib)

Insertar en el borrador del AnteProyecto de Ley, las sugerencias realizadas en el foro, creado para estepropósito.


35

5. BIBLIOGRAFIA

- [Lucena, 2003], Lucena, López Manuel José, Criptografía y Seguridad en Computadores, terceraedición, Junio 2001.

- [VeriSIgn, 1999], http://www.verisign.com- [Rinjdael, 2000], http://www.nist.com/aes/- [Shannon, 1948], C.E. A Mathematical Theory of Communication, Bell Syst. J. Vol 28, (July),

(Oct), 1948- [SCHNEIER, 1996], Schneier, Bruce, Applied Cryptography, Second Edition, 1996.- [DIMA, 1976], Diffie, W., Hellman M. New Directions in Cryptography, IEEE Trans. On Info.

Theory, Vol. IT-22(6), Nov. 1976- [ZIMM, 1994], Zimmerman, Phil, Pretty Good Privacy (PGP) Public Key Encryption for the

Masses. PGP User’s Guide, Ago. 1994.- [RSA, 2001], http://www.rsa.com- [AGUIRRE, 1999], Ramió Aguirre Jorge, Aplicaciones Criptográficas, segunda edición,

Universidad Politécnica de Madrid, Junio 1999.- Menezes A., Van Oorschot P., Vanstone S., Handbook of applied Cryptography, CRC press 1996.- Nist, National Institute of Standards and Technology, Public Key Infraestructure Study, abril 1994.

http://www.nist.com- Lopez, Santidrían Lourdes, Organización y jerarquización de Autoridades de Certificación para la

provisión de servicios de Seguridad en redes telemáticas, Facultad de Informática, UniversidadPolitécnica de Madrid, 1998

- Comercio Electrónico en Bolivia, www.marketing-rentable.com/marketing-4/comercio-electronico-en-bolivia.html

- Estadisticas sobre Bolivia, www.boliviabiz.com- Centro de Promoción Bolivia (Ceprobol), www.b2bolivia.com.bo- Bolivia y el Comercio Electrónico, http://www.caf.com/attach/4/default/ITBolivia.pdf- Ten Risks of PKI: What You're Not Being Told About Public Key Infrastructure- OpenCA, www.openca.org- OpenSSL, www.openssl.org- Apache Corporation, www.apache.org- Linux Org, www.linux.orgwww.modssl.orgwww.openldap.orgwww.mysql.com- www.perl.orgwww.ossp.org/pkg/lib/mm/- www.cpan.org

http://www.verisign.com

http://www.nist.com/aes/

http://www.rsa.com

http://www.nist.com

http://www.marketing-rentable.com/marketing-4/comercio-electronico-

http://www.boliviabiz.com

http://www.b2bolivia.com.bo

http://www.caf.com/attach/4/default/ITBolivia.pdf

http://www.openca.org

http://www.openssl.org

http://www.apache.org

http://www.linux.org

http://www.modssl.org

http://www.openldap.org

http://www.mysql.com

http://www.perl.org

http://www.ossp.org/pkg/lib/mm/

http://www.cpan.org

Infraestructura de Clave Pública - Bolivia bolivia y... · Para ello se utiliza Software Libre....

Documents

Transcript of Infraestructura de Clave Pública - Bolivia bolivia y... · Para ello se utiliza Software Libre....