PKI y Software Libre

RESUMEN
El empleo de una Infraestructura de Clave Pblica - PKI - , es una pieza clave en lo que son las transacciones administrativas, comerciales y otras aplicaciones, que requieren de seguridad y autenticacin, esto en Intranets, Extranets e Internet
La utilizacin de una PKI, requiere la utilizacin de un criptosistema de clave pblica, que se encargue de gestionar y manejar los accesorios (claves, firmas, etc.)
El presente trabajo, propone un modelo de Infraestructura de Clave Pblica, y sus mejores practicas, para caracterizar, definir e implementar una Plataforma de Seguridad, orientado a las entidades Estatales y basado en la utilizacin de Firmas y Certificados Digitales, todo ello utilizando Software Libre.
Remberto Gonzales Cruz e-mail: rembert@usfx.edu.bo, rembertus@gmail.com
INTRODUCCION El rpido crecimiento de las redes, en el mundo, y por lo tanto el crecimiento exponencial de las interconexiones y los servicios aadidos de lo que es Internet, ya forman parte de nuestra vida cotidiana, al punto que ya se esta acostumbrado, y sin la cual, ya no viviramos normalmente. El problema de la seguridad en las redes, y por lo tanto en las comunicaciones, viene a ser uno de los problemas ms importantes, en lo que son las transacciones administrativas y/o comerciales, cuyos servicios, tienen ms desventajas que ventajas, por lo cual el usuario comn no confa aun en dichos servicios. Un ejemplo actual que se dio a inicios del ao 2001, es el robo de los datos de tarjetas de crdito, de miles de usuarios, de una conocida empresa punto com, tambin se conoce un alto porcentaje de intrusiones a diferentes empresas que trabajan en transacciones en el mbito administrativo y comercial, sin ir muy lejos, en nuestro Pas, nuestras entidades financieras, utilizan muy poco lo que se denomina seguridad en transacciones, amen de soportar algunos algoritmos criptogrficos y Certificados Digitales de empresas fuera del Pas, en el entorno administrativo, las Entidades Estatales no hacen uso de este tipo de seguridad, si bien por que no lo necesitan o no 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 es caracterizar, normar, definir e implementar, lo que se denomina: Terceras Partes de Confianza en base a una plataforma de seguridad. El objeto de estudio, los mecanismos y herramientas criptogrficas, para obtener transacciones seguras en la red. El campo de accin, esta definido, en lo que viene a ser las Entidades Estatales en General. Para ello se ha planteado la siguiente hiptesis: Mediante la aplicacin de mecanismos y herramientas Criptogrficas, se puede garantizar la Confidencialidad, Autenticidad, Integridad y no repudio de las transacciones administrativas y/o econmicas realizadas a travs de una red. (Internet, Intranet y/o Extranet) Los mtodos de trabajo a emplear: en primer lugar una revisin bibliogrfica, de temas relacionados al tema de estudio, en segundo lugar, una evaluacin de algunas plataformas libres y los servicios que ofrecen. En suma, el empleo de la Investigacin Cientfica. El trabajo se dividir en cuatro partes y se puede resumir de la siguiente manera: Parte I, Antecedentes, algunos conceptos fundamentales y evaluacin de plataformas ya existentes. Parte II, Modelo propuesto de Infraestructura de Clave Pblica, en este parte se realiza un anlisis y diseo general, de los lineamientos de lo que la Infraestructura de Clave Pblica debiera como mnimo ofrecer, considerando las mejores practicas existentes, se plantea mejoras, objetivos, la arquitectura, los procesos y procedimientos propios. Parte III, Instalacin e Implementacin de la Infraestructura de Clave Pblica, en base a los estudios realizados en la parte II, se realiza la descripcin de los mdulos, la instalacin e implementacin en base a requerimientos encontrados. Para ello se utiliza Software Libre. Parte IV, Conclusiones y Recomendaciones, se dan las conclusiones pertinentes al planteamiento de la PKI, y las recomendaciones respectivas, tanto tericas como practicas para su implementacin e implantacin en las diferentes Entidades Estatales.
INDICE Pagina Resumen Introduccin Indice 1. PARTE I, ANTECEDENTES 1.1. 1.2. 1.3. 1.4. 1.5. Introduccin Ataques y Amenazas Mecanismos y Herramientas de Seguridad Estado del Arte en Bolivia Modelos de PKI 1.5.1.EuPKI PKI de la Comunidad Europea 1.5.2.Pretty Goog Privay - PGP 1.5.3.Privacy Enhacement for Internet Electronic Mail - PEM
2. PARTE II, MODELO PROPUESTO DE PKI 2.1. 2.2. 2.3. 2.4. Especificacin de la Arquitectura de la PKI Componentes Bsicos de una PKI Funciones de la PKI Escenarios de Aplicacin
3. PARTE III, INSTALACION E IMPLEMENTACION 3.1. Software a Utilizar 3.1.1.Sistema Operativo 3.1.2.Open SSL 3.1.3.MM Shared Memory Allocation 3.1.4.Mod SSL 3.1.5.Apache www Server 3.1.6.MySQL 3.1.7.Open CA 4. PARTE IV, CONCLUSIONES Y RECOMENDACIONES 4.1. Conclusiones 4.2. Recomendaciones 5. BIBLIOGRAFIA
1. PARTE I, ANTECEDENTES 1.1. INTRODUCCIN El concepto de seguridad es ya un clsico en muchos mbitos de la informtica. En nuestro pas, el mismo concepto es desconocido, o por lo menos, poco conocido en entornos NO informticos, y peor aun el concepto de lo que es Sistema de Seguridad, porque no se le da la importancia debida a este problema, pues muchos administradores de sistemas o redes, orientan ms sus funciones hacia el usuario, en cuanto al servicio ofrecido de: presentacin y disponibilidad de la informacin, y no tanto as, a lo que es la seguridad de estos. El concepto de seguridad en la informacin es mucho ms amplio que la simple proteccin de los datos a nivel lgico [Lucena, 2003], pues este engloba muchas caractersticas y otros factores (ambientes, hardware, recursos humanos), que caracterizan el tratamiento y la proteccin de la informacin. La fundamentacin presentada en esta parte, prioriza, los mecanismos y herramientas sobre los aspectos de la seguridad en las diferentes transacciones administrativas y/o comerciales realizadas, y en la seguridad de la informacin propiamente dicha, se analiza y evala algunos modelos existentes, considerando sus ventajas y desventajas en la aplicacin de la transmisin de datos e informacin. 1.2. ATAQUES Y AMENAZAS Uno de los factores de seguridad que son muy susceptibles para cualquier usuario, es el que alguna persona no autorizada, tenga acceso a sus datos, o monitoree sus transacciones, esto tiende a definir lo que es una amenaza1. Las categoras generales de ataques o amenazas son las siguientes: Interrupcin, Intercepcin, Modificacin, Suplantacin. Los cuales pueden ser pasivos o activos, dependiendo del nivel de intromisin realizada por algn intruso. En los ataques pasivos el atacante no altera la comunicacin, sino que nicamente la escucha o monitoriza, para obtener la informacin que est siendo transmitida. Sus objetivos son la intercepcin de datos y el anlisis de trfico. Los ataques pasivos son muy difciles de detectar, ya que no provocan ninguna alteracin de los datos. Sin embargo, es posible evitar su xito mediante el cifrado de la informacin.
Fig. 1.2.a. Ataque Pasivo Por otra parte los ataques activos, implican algn tipo de modificacin del flujo de datos transmitido o la creacin de un falso flujo de datos.
1 Amenaza: Posible peligro del sistema. Cracker, virus, caballo de Troya, Representan los posibles atacantes o factores que aprovechan las debilidades del sistema. www.wikipedia.org
Estas amenazas y ataques, pueden ser realizados en sistemas aislados, que actualmente vendran a ser una cantidad mnima, y en sistemas interconectados -redes-, que es donde los sistemas presentan ms vulnerabilidades.
Fig. 1.2.b Ataques Activos As mismo dependiendo del entorno, se podran dar ataques externos o fsicos relacionados con la proteccin de los soportes fsicos de la informacin, ms que a la informacin propiamente. 1.3. MECANISMOS Y HERRAMIENTAS DE SEGURIDAD Los mecanismos para garantizar la seguridad no pueden ser ajenos a los sistemas informticos, pues ellos pueden frenar y minimizar de alguna manera, las amenazas y ataques a la informacin, por ello se tienen una serie de medidas, entre las cuales se puede mencionar. Definicin de niveles de seguridad. Claves de acceso (passwords). Criptografa y firma digital en las comunicaciones y transacciones. Utilizacin de Certificados para la autenticacin. Plan de contingencias.
El nivel de desarrollo de estas medidas depende de la naturaleza de la organizacin, de la informacin, de las aplicaciones, de quienes las usan y acceden a estas. La puesta en marcha de un plan de seguridad no es algo esttico que se hace una vez. Una de las principales garantas de que un sistema es seguro, es que se realiza un seguimiento de las medidas puestas en marcha, de los registros de auditoria, y otros, el seguimiento de las medidas de seguridad es la va para asegurar que el plan se adapta a la organizacin y para detectar posibles intentos de fraude o acceso incorrecto. Los planes de seguridad deben considerar el tipo de informacin, de los usuarios, de los equipos y sistemas. Tambin el plan debe de especificar las tareas a realizar, sus responsables, cmo se definen los niveles de acceso, cmo se realizar el seguimiento, dnde deben ponerse en marcha medidas especficas (cortafuegos firewalls-, filtros, control de acceso y otros), e inclusive tomar en cuenta la estructura organizativa. No hay que olvidar que el sentido comn juega un papel de relevancia, ya que si no es as, se pueden llegar a proponer medidas muy seguras pero realmente impracticables, lo cual significa que hay que asumir ciertos riesgos.
1.3.1.CRIPTOGRAFIA Uno de las medidas que no debe faltar en un plan de seguridad, es el referente al rea de la Criptografa, la cual es una de las bases ms importantes en este aspecto (seguridad). Criptografa: La criptografa es el estudio de tcnicas matemticas relacionadas a aspectos de la seguridad, tales como la confidencialidad, integridad de datos, autenticacin, y no repudio. Una definicin ms comn para la criptografa es: Criptografa es la tcnica de convertir un texto en claro (plaintext), en otro llamado criptograma (ciphertext), cuyo contenido de informacin es igual al anterior pero slo lo pueden entender las personas autorizadas.
Texto en Claro (plain text)
CRIPTOGRAFIA
Fig. 1.3.1. Criptografa
Criptograma (cipher text)
Para cifrar se debe transformar un texto mediante un mtodo cuya funcin inversa nicamente conocen las personas autorizadas. As se puede utilizar un algoritmo secreto o un algoritmo pblico que utiliza una palabra, llamada clave, slo conocida por las personas autorizadas, esta clave debe ser imprescindible para el cifrado y descifrado. Existen dos tipos de criptosistemas, Simtrico o de Llave Privada y Asimtrico o de Llave Pblica. 1.3.1.1. CRIPTOGRAFIA SIMETRICA
La criptografa simtrica se refiere al conjunto de mtodos que permiten tener comunicacin segura entre las partes siempre y cuando anteriormente se hayan intercambiado la clave correspondiente que llamaremos clave o llave simtrica. La simetra se refiere a que las partes tienen la misma llave tanto para cifrar como para descifrar.
CIFRAR
DESCIFRAR
Fig. 1.3.1.1 Criptografa Simtrica AES Una mencin especial, merece el nuevo estndar de cifrado AES -Advanced Encryption Stndard[Rinjdael, 2000], que a finales del 2000, se posesiono como nuevo estndar simtrico. Este nuevo estndar, especifica el algoritmo Rijndael, un cifrador de bloque que tiene las siguientes caractersticas:
Remberto Gonzales Cruz e-mail: rembert@usfx.edu.bo, rembertus@gmail.com 6
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(2 8), grado 8.
El algoritmo en vez de utilizar las famosas redes de Feistel2, utiliza otro tipo de mecanismos, denominados transformaciones: SubBytes: es una transformacin no lineal, de substitucin de bytes, que opera independientemente sobre cada byte de el Estado, utilizando una tabla de sustitucin denominada S-Box. ShiftRows: es una transformacin, que hace que los bytes de las ultimas tres filas del Estado sean cclicamente desplazadas sobre diferentes nmeros de bytes (desplazamientos). MixColumns: la transformacin opera sobre el Estado, columna por columna, procesando cada columna como un termino polinomial, sobre GF(2 8). Una aplicacin de la criptografa simtrica, es el cifrado del flujo de informacin transmitido (pudindose ser esto en tiempo real), en entornos seguros. 1.3.1.2. CRIPTOGRAFIA ASIMETRICA
La criptografa asimtrica, ha demostrado su inters para ser empleados en redes de comunicacin inseguras (Internet). Introducidos por Whitfield Diffie y Martin Hellman [WDMH, 1976], a mediados de los aos 70, su novedad fundamental con respecto a la criptografa simtrica es que las claves no son nicas, sino que forman pares, denominadas clave privada y clave pblica. Una de ellas se emplea para codificar, mientras que la otra se usa para decodificar. Dependiendo de la aplicacin que se le de al algoritmo, la clave pblica ser la de cifrado o viceversa. Para que estos criptosistemas sean seguros tambin ha de cumplirse que a partir de una de las claves resulte extremadamente difcil calcular la otra.
Llave Pblica Llave Privada
CIFRAR
DESCIFRAR
Fig. 1.3.1.2 Criptografa Asimtrica Los algoritmos asimtricos emplean generalmente longitudes de clave mucho mayores que los simtricos. Por ejemplo, mientras que para algoritmos simtricos se considera segura una clave de 128 bits, para algoritmos asimtricos se recomiendan claves de al menos 1024 bits. Adems, la complejidad de clculo que comportan estos ltimos los hace considerablemente ms lentos que los algoritmos de cifrado por bloques. En la prctica los mtodos asimtricos se emplean nicamente para codificar la clave de sesin (simtrica) 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.
Una aplicacin de los algoritmos asimtricos es la autenticacin de mensajes, con ayuda de funciones hash3, que nos permiten obtener una firma a partir de un mensaje. Dicha firma es mucho ms pequea que el mensaje original, y es muy difcil encontrar otro mensaje que tenga la misma firma. 1.3.1.3. FIRMA DIGITAL
Otra Aplicacin de la criptografa asimtrica, es lo que se denomina firma digital4, las cuales son mtodos de cifrado que tienen dos propsitos: Validar el contenido de un mensaje electrnico, que se puede utilizar posteriormente para comprobar que un emisor envi dicho mensaje. Probar que no se ha falsificado un mensaje durante su envo. Las firmas digitales respaldan la autenticidad del correo electrnico, transacciones de diferente ndole (contabilidad, rdenes de pago, documentos para grupos de trabajo y archivos que se trasladan entre sistemas, usuarios u organizaciones). La Firma Digital se basa en el hecho de que dos grupos pueden autentificarse el uno al otro para el intercambio seguro de documentos, pero la relacin entre ellos no se basa en una confianza total. Por ejemplo, una persona podra enviar un mensaje para una apuesta en cualquier competicin y al perder negarse haber enviado dicho mensaje. Aunque se sabe a travs del proceso de autenticacin que esta persona realmente envi ese mensaje, sin una firma digital no se podra probar tcnicamente que el mensaje no se modific. El emisor podra decir, "s, yo le envi el mensaje, pero se lo modifico" Las firmas digitales autentifican los mensajes y se usan para validar compras, transacciones de negocios, transacciones administrativas y/o acadmicas.
Funcin HASH
Texto en Claro
Resumen Del texto
Resumen Firmado con la Llave Privada
(plain text) + FIRMA
Llave Privada para Firmar
Fig. 1.3.1.3 Firma Digital Si bien existen diferentes mecanismos de seguridad, una aplicacin hbrida de estos es lo aconsejable, para poder cubrir una extensa gama de vulnerabilidades, en cualquier sistema.
Funcin Hash: Las funciones Hash sirven para comprimir un texto en un bloque de longitud fija. Este resumen suele tener una longitud de 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 matemtico, denominado funcin hash, a su contenido.
1.4. ESTADO DEL ARTE EN BOLIVIA Bolivia es uno de esos pases, en los cuales, no existe un marco legal y regulatorio, que respalde las transacciones electrnicas, aunque en fecha, 13/07/2005, se presento el primer borrador del Ante Proyecto de Ley de Comunicacin Electrnica de Datos y Comercio Electrnico, aprobado por varias instituciones, en la cual y segn el artculo 1 del captulo 1 tiene por objeto regular la comunicacin electrnica de datos, otorgando y reconociendo eficacia y valor jurdico a los mensajes de datos, documentos electrnicos, la firma electrnica, la contratacin electrnica ; as como a los diversos actos atribuibles a personas naturales y jurdicas, pblicas o privadas realizadas por medios electrnicos. Si bien el Gobierno de la Repblica de Bolivia ha implementado acciones importantes para fomentar el desarrollo de las nuevas tecnologas de la informacin y comunicacin en el marco de insertar al pas a la sociedad de la informacin, esto esta mas orientado a lo que es el sistema financiero, especficamente con el Comercio Electrnico. Las transacciones de comercio electrnico indirecto en Bolivia estn sujetas a los mismos tributos que las transacciones comerciales tradicionales, es decir que las importaciones deben pagar los mismos impuestos y gravmenes que cualquier otra importacin. El gobierno ha realizado apoyos importantes en cuanto a las facilidades de exportacin y pago de impuestos, pero no as a las transacciones administrativas, que viene a ser un punto dbil en el contexto Boliviano. Todas las entidades publicas especficamente, requieren y tiene la necesidad de compartir informacin, y lgicamente lo hacen, pero no de una manera segura, el uso del correo electrnico, es desde ya, lo mas extendido que se tiene para el envi de informacin, aunque no de nivel critico, pues esto se hace de forma manual, es decir utilizando los medios comunes, Empresa de Correos, Courries, o envos fsicos a travs de diferentes empresas que ofrecen estos servicios. No hay que desmerecer el esfuerzo que hacen algunas instituciones pblicas, Impuestos Nacionales, Aduana, al tener una conexin dedicada y segura en la transferencia de informacin desde y hacia sus diferentes puntos en el pas, pero esto no se da en ambientes abiertos, lgicamente por la misma seguridad que esto implica. 1.4.1.Marco Jurdico para el Comercio Electrnico y Transmisin de Datos Ley SIRESE. Ley de Telecomunicaciones. Ley de Derechos de Autor. Cdigo 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 Lgico o Software, con el fin de proteger el mismo. El Cdigo Penal establece y sanciona los delitos cometidos contra los derechos de autor. La modificacin al Cdigo Penal establece como delitos las alteraciones, modificaciones y uso indebido de los medios informticos. D.S. 26553 que establece el marco legal e institucional para la implementacin de las nuevas tecnologas de informacin y comunicacin.
9
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 la Infraestructura de Clave Publica. Para proveer acceso libre, alta calidad modular y un software totalmente abierto, para asegurar el intercambio de informacin, en las aplicaciones de e-administracin y los e-negocios. EuPKI, fue supuesto para la construccin de una Infraestructura de Clave Publica con las siguientes caractersticas: Un Diseo completo y modular Facilidad de Mantenimiento Adaptabilidad en cualquier tipo de implementacin Basado en estndares 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 caractersticas principales de esta plataforma es que puede ser ser aplicado en cualquier tipo de dominio. (Financiero, acadmico, comercio, gobierno, etc.). 1.5.1.1. Arquitectura
CSP1 KA Central KGS CAs
CSP2
RA1
RA2
RAN
Usuario 1
Usuario 2
Usuario N
UKGS
Figura 1.5.1.1. Arquitectura de EuPKI
EuPKI, puede Operar un nmero diferente de Autoridades de Certificacin, cada CA tiene asociado un CSP (Crypto Service Provider), la cual tiene una llave privada que es utilizada como marca en las operaciones de los procesos de la CA. La plataforma tambin puede manejar varias RAs, cada uno definiendo un dominio diferente (namespace), como tambien polticas de certificacin diferentes. El KGS (Key Generation Systems) esta conectado al resto del sistema para facilitar la operacin del Software en la entidad final para la Generacin de Llaves, Por otro lado el UKGS, interacta directamente con la CA (si un entorno en lnea es utilizado) o indirectamente via RAss, El KA (Key Archive), puede ser conectado al Central KGS para soportar la recuperacin de llaves cifradas.
1.5.1.2.
Certificacin
El sistema CA, controla la funcionalidad comn de las Autoridades de Certificacin, que trabajan junto a los sistemas CSP, El sistema CA, puede adquirir las llaves publicas desde la entidad final o desde una Central de generacin de llaves y distribuye la informacin en base a Directorios, tambin mantiene un almacn denominado CA DB, para almacenar los Certificados, su Estado y la informacin relacionada a la entidad (con una referencia a una entrada en la RA). La CA para certificar, trabaja adems con subsistemas que le ayudan ya sea en el establecimiento de autenticaciones iniciales, o el compartimiento de llaves secretas entre la CA y cualquier entidad. CA, tambin soporta requerimientos de registro y certificacin en modo Batch o en linea, controlando para esto el KGS, en la obtencin de pares de llaves 1.5.1.3. Evaluacin
El modelo planteado por euPKI, aunque parece robusto al principio, por el mismo hecho de soportar cualquier tipo de dominio es bastante ambiguo en sus definiciones ya especficas a la hora de implementarlo. El hecho de soportar diferentes espacios, hace que uno se pierda a la hora de su instalacin, es tambin necesario contar con conocimientos regularmente buenos para ello. El uso de mdulos criptogrficos plug and play, hace que no se ate a un solo algoritmo criptogrfico, sino mas bien de ofrecer y poder seleccionar cualquiera, lgicamente esto adiciona una marca, del algoritmo utilizado, en el propio certificado Otra ventaja de este modelo es el de tener bien definido un KGS, para la generacin del par de Llaves, as como el soporte tambin para la entidad final, con la disposicin 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 aplicacin informtica de libre distribucin, desarrollado por Phil Zimmerman [Zimm, 1994], a inicios de 1990. PGP permite intercambiar ficheros y mensajes con confidencialidad, autenticacin, integridad y comodidad. Para realizar esto, PGP utiliza criptografa de clave pblica RSA, Diffie-Hellman o DSS para generar firmas y cifrar claves, criptografa de clave secreta IDEA, CAST, TRIPLEDES y AES para el cifrado del documento propiamente dicho y la funcin hash MD5, SHA-1 para crear las huellas digitales que se emplean en la firma digital.
11
1.5.2.1.
Arquitectura
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 claves pblicas, denominado anillo, y es el propio usuario el que establece la confianza en la validez de dichas claves. Cuando un usuario necesita comunicarse con nuevos usuarios, podr obtener sus claves a travs de personas en las que ya confa, las cuales podrn firmar y enviarle claves pblicas de otros usuarios en los que ellos confiaban previamente, estableciendo as una cadena de confianza que se basa en las relaciones personales. 1.5.2.2. Certificacin
PGP utiliza un formato propio de certificado que consta nicamente de un identificador del usuario (que contiene su nombre y algn dato significativo y personal como la direccin de correo electrnico, su nmero de telfono o cualquier informacin que ayude a garantizar la unicidad del identificador), de una fecha de emisin y de la propia clave pblica. Como en PGP no existen CAs el certificado es emitido por el propio usuario propietario de la clave pblica, y firmado inicialmente por l mismo. A este certificado se le pueden aadir firmas de otros usuarios que se utilizarn como aval de validez. La sencillez del certificado hace que en PGP se hable directamente de claves pblicas y no se utilice la palabra certificado. 1.5.2.3. Evaluacin
El modelo de confianza utilizado en PGP, basado en las relaciones personales ha sido un punto a favor para su rpida expansin. Este modelo, conceptualmente sencillo, no requiere que los usuarios estn registrados en dominios de seguridad en los que se manejan complejas infraestructuras. Cualquier usuario que instale en su ordenador un software PGP puede comunicarse de forma segura con otros usuarios. Uno de los problemas que presenta el modelo de certificacin de PGP, es que la confianza personal no proporciona garantas suficientes ante posibles litigios por uso fraudulento de claves y/o firmas digitales. El proceso de revocacin, puede actualizar claves revocadas, a partir de una direccin URL). Cuando la clave secreta o la contrasea utilizada para su proteccin se ven comprometidas, o cuando se sospecha del uso fraudulento de la propia clave pblica por parte de otros usuarios.
12
1.5.3. Privacy Enhancement for Internet Electronic Mail PEM Se cre en 1991, a partir de las necesidades de transferir informacin criptogrfica a travs del correo electrnico principalmente, el impulso fue, a travs del grupo de trabajo IETF-PEM de la Internet Society. PEM, proporciona los servicios de integridad, autenticacin y no repudio en origen y opcionalmente confidencialidad. Lo habitual en PEM es utilizar algoritmos de clave secreta para el cifrado de los datos y algoritmos de clave pblica para la administracin de claves y la gestin de firmas digitales. Aunque no es obligatorio el uso de algoritmos de clave pblica en PEM, es recomendable hacerlo para aprovechar las ventajas que ofrecen este tipo de algoritmos en cuanto a la administracin de claves se refiere, ya que, al contrario de lo que sucede con los algoritmos de clave privada, no es necesario un canal de comunicacin seguro para efectuar el intercambio de claves secretas. 1.5.3.1. Arquitectura
PEM define una infraestructura de certificacin basada en una organizacin jerrquica arborescente de Autoridades de Certificacin.
IP R A
PCA
PCA
CA A n o n im o
CA O rg .
CA O rg .
CA R e s id .
U s u a rio A n n im o
U s u a rio O rg a n iz a c io n a l
U s u a rio O rg a n iz a c io n a l
U s u a rio R e s id e n c ia l
Figura 1.5.3.1. Arquitectura PEM
En PEM, las CAs y los usuarios estn organizados en un nico rbol, en el cual los usuarios representan las hojas. La raz de rbol la ocupa la IPRA (Internet Policy Registration Authority). El principal cometido de IPRA es el de establecer la poltica global, la cual se aplicara a todos los procesos de certificacin bajo esta jerarqua. IPRA certifica a las Autoridades de Certificacin de Polticas, PCAs (Policy Certification Authorities), que definen polticas particulares dentro de la poltica global definida por IPRA. Las PCAs certifican a otras CAs que se encargaran de certificar a usuarios finales o a otras CAs que se encuentren por debajo en la jerarqua.
13
Autoridad de Registro de Polticas de Internet (IPRA) Registro de PCAs Garanta de unicidad de nombres distintivos. Correccin de nombres distintivos. Convenios sobre nombres distintivos. Gestin de CRLs. Expedicin de licencias de algoritmos de clave pblica.
Autoridades de Certificacin de Polticas (PCAs) Identidad de la PCA Alcance de la PCA Privacidad y seguridad de la PCA Poltica de Certificacin Gestin de CRLs Convenios de Nombramiento Emisin de Negocios
Autoridades de Certificacin (CAs) Las CAs tienen como misin crear y asignar certificados. Aunque la recomendacin X.509, impone pocas restricciones sobre las CAs, la implementacin practica del sistema de certificacin ha llevado a la necesidad de establecer algn convenio. Por ejemplo, las CAS, deben mantener una base de datos con los DNs de las entidades a las que certifican con el fin de garantizar la unicidad nominal. Las CAs deben establecer medidas de seguridad para proteger su clave secreta, estas medidas pueden estar impuestas por su PCA. Las CAs debern emitir y enviar CRLs a su PCA en los periodos establecidos por esta. Las CAs podrn definir su propia poltica de registro de usuarios siempre que ste dentro de lo definido por su PCA. Dependiendo del tipo de entidades que las CAs certifiquen, en PEM podemos distinguir tres tipos de CAs: CAs organizacionales, CAs Residenciales, CAs Personas Usuarios y agentes de usuario Como PEM es una especificacin para correo electrnico, cuando hablamos de usuario PEM, en algunos casos nos referimos a un agente de usuario UA (User Agent), trmino definido por la recomendacin X.400, para referenciar al medio por el cual el usuario interacta con el sistema de manejo de mensajes. 1.5.3.2. Certificacin
PEM utiliza la versin 1 del certificado X.509, y una versin modificada de la CRL versin 1. Debido a la organizacin jerrquica de las Autoridades de Certificacin definida en PEM en forma de un nico rbol, en esta arquitectura existe siempre un punto de confianza comn entre dos usuarios, que es la raz de rbol IPRA. En PEM todos los usuarios estn en posesin de la clave pblica de IPRA, la cual les es facilitada como parte del procedimiento de registro o en el proceso de instalacin del software PEM. PEM no prev el uso del Directorio X.500 para el almacenamiento de certificados y CRLs pero deja libertad a las diversas entidades de su arquitectura para utilizarlo.
Cada usuario y AC de PEM conoce el conjunto de certificados que forman su camino de certificacin hasta IPRA, ya que cuando una AC emite un certificado lo enva a su propietario incluyendo los certificados que forman el camino de certificacin desde el nuevo certificado hasta IPRA y opcionalmente algn certificado cruzado que la AC considere de inters. El procedimiento habitual en PEM, es que los usuarios en el proceso de envi de mensajes incluyan en campos opcionales el certificado de la clave, pareja de la clave de firma, y en otros todos los certificados que conforman su camino de Certificacin hasta IPRA o hasta un nodo comn en el rbol. De esta forma el usuario receptor podr validar la firma comenzando por el certificado de la PCA emitido por IPRA. Un usuario PEM debera consultar regularmente las CRLs correspondientes, para tener la seguridad de que los certificados que intervienen en el proceso de validacin no han sido revocados. PEM tambin describe procedimientos para la consulta, obtencin y almacenamiento de CRLs en las bases de datos de la PCAs. 1.5.3.3. Evaluacin
La definicin y creacin de la infraestructura PEM ha representado, sin duda alguna uno de los hitos ms importantes en el desarrollo de entornos de seguridad en redes. A PEM se le deben muchas cosas, por ejemplo su definicin de mensaje cifrado utilizando criptografa de simtrica y asimtrica, se ha convertido en un estndar que utilizan la mayora de las aplicaciones, el cual se conoce con el nombre de mensaje envuelto. A PEM tambin se le debe la definicin de un modelo de confianza basado en jerarqua de CAs que ha sido considerado el patrn de los modelos que aparecieron con posteridad. A pesar del gran avance que supuso PEM, su arquitectura presenta una serie de deficiencias. Algunas de estas deficiencias derivan de la utilizacin de la versin 1 del certificado. Las experimentaciones con PEM han servido para identificar estas deficiencias y buscar soluciones, algunas de las cuales ya se han implementado en la versin 3. En PEM no se puede determinar directamente a que tipo de entidad pertenece un certificado, ya que esta informacin, que puede resultar de especial relevancia, solo se puede obtener de forma indirecta observando el DN del propietario del certificado. La centralizacin de las CRLs en las bases de datos de las PCAs puede provocar problemas de gestin, en el caso de que estas listas crezcan considerablemente.
15
2. PARTE II, MODELO PROPUESTO DE PKI Luego del anlisis y evaluacin realizada en el anterior acpite, se propone un modelo de Infraestructura de Clave Pblica, basado en el uso del certificado X.509 versin 3, y CLRs versin 2, en el que se definen algunas caractersticas comunes y algunas nuevas, con el objetivo de cubrir las deficiencias detectadas en otros modelos y de garantizar la interaccin con el usuario, en un mbito nacional, y porque no decirlo, tambin internacional. La adopcin generalizada del certificado X.509 por parte de los distintos organismos, empresas e instituciones a nivel internacional que han desarrollado distintos modelos, ha convertido a este certificado en el estndar de facto en el campo de la certificacin. El modelo propuesto, toma como base la utilizacin del certificado X.509 en su versin 3, y una organizacin jerrquica de ACs, que permitir, un mejor control y seguimiento de la certificacin que se vayan realizando. Los modelos jerrquicos son los que mejor se adaptan a la naturaleza organizacional de los usuarios de estas infraestructuras, proporcionando a su vez, un sistema de confianza slido y robusto. PGP Criptosistema Utilizado RSA CAST-IDEATripleDES MD5, SHA-1 NO NO NO Usuarios PEM RSA DES MODELO PROPUESTO Definido por el RSA Dominio AES SHA-256, SHA-512 SI OPCIONAL SI PCA CA RA EuPKI
Soporte Certificados X.509 Soporte Directorio X.500 Tipo Organizacin Jerrquica Tipos de Autoridades
SI NO SI IPRA PCA CA
SI NO SI/NO CA RA (CKGS, UKGS, CSP, KA) Comercio Electrnico, e-administracin
Aplicaciones Soportadas
Correo Electrnico Correo Correo Electrnico Transacciones Electrnico Transacciones Electrnicas Electrnicas e-administracin e-administracin Tabla 2. Caractersticas principales del modelo Propuesto
16
2.1. Especificacin de la Arquitectura PKI

PCA
CA
CA
CA
CA
RA
RA
RA
RA
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 raz, y es el nodo que define las polticas de certificacin, para todo el modelo, sin embargo esto no significa que no existan subpoliticas propias de una AC en particular (e.j. otros documentos de respaldo para registro) En este caso si existieran varias ACs, una podra tener alcance internacional y las dems nacionales, de las cuales podran subdividirse por tipo de organizacin (ejemplo Universidad, sector pblico, sector privado, Banca, y otros). A este nivel, solo existir una sola poltica de certificacin (la cual podra ser una simple o compuestas por varias subpoliticas, que estarn aplicados en un mbito nacional), siguiendo con los lineamientos de sencillez y confiabilidad por parte del usuario. Para el modelo propuesto, se utiliza los campos de extensin de los certificados X.509, los cuales podrn incluir informacin sobre el camino de certificacin que existe, desde el certificado hasta la raz de su rbol (para el caso en que se tenga varias ACs), lo que facilita de sobremanera, pues se conocera de antemano el camino o los certificados necesarios en cualquier proceso de verificacin. Otro objetivo del Modelo es respecto al almacenamiento y localizacin de certificados y CRLs, incluyendo la utilizacin del Directorio X.500 de forma opcional. 2.2. Componentes Bsicos de la PKI 2.2.1. PCA - Policy CAs Para que un entorno de certificacin funcione correctamente es necesario definir una serie de reglas que indiquen la forma de aplicar los certificados. Este conjunto de reglas que constituyen la poltica de certificacin, tiene que estar definido por las autoridades reconocidas en el entorno. Por lo tanto, las CAs actuarn bajo una determinada poltica de certificacin. Estas CAs especficas suelen denominarse PCAs (Policy CAs).
Una PCA puede estar representada por una empresa nica, o una institucin, pero en nuestro modelo lo aconsejable y recomendable, es que estas estn definidas por un grupo de instituciones del mismo medio. (ej. Adsib, Ministerio de Educacin y Cultura, Cmara de Comercio, Universidad, etc). Todo con el fin de definir el entorno, alcance y medios de las polticas de seguridad en la plataforma. Una poltica de seguridad establece y define la direccin de mximo nivel de una organizacin sobre seguridad de informacin, as como los procesos y principios para el uso de la criptografa. Por lo general, incluye declaraciones sobre cmo gestionar la empresa las claves y la informacin critica, y establecer el nivel de control requerido para afrontar los niveles de riesgo.
PCA
Identidad PCA
Politicas de Seguridad, Normas y Procedimientos
Privacidad y seguridad de la PCA
Polticas de Certificacin
Gestin de CRLs
Otras Polticas
Repositorio Llaves
Repositorio Documentos
Figura 2.2.1. Especificacin de la PCA Identidad de la PCA. Se deben dar a conocer el DN (Distinguided Name) de la PCA, informacin que permita establecer contacto personal (direccin postal, nmero de telfono, opcionalmente nmero de fax y direccin de correo electrnico), fecha de publicacin de su informe de poltica y duracin prevista. Privacidad y seguridad de la PCA. La PCA deber especificar las medidas tcnicas y los procedimientos de seguridad que seguir en la generacin y proteccin de sus claves. Tambin podr imponer requisitos de seguridad sobre las CAs certificadas y deber dictar medidas de seguridad para proteger la informacin recogida en los procesos de certificacin de las CAs subordinadas. Mecanismos de proteccin. Se deben definir los requerimientos hardware y software necesarios para proteger la infraestructura de una CA. Polticas de Certificacin. Cada PCA deber indicar la poltica y procedimientos que gobiernan la certificacin de las CAs subordinadas, y transitivamente tambin a los usuarios o CAs que sean certificados por las anteriores. Por ejemplo, se deber especificar el procedimiento de registro, el perodo de validez de los certificados, tamao de las claves, etc. Gestin de CRLs. Se especificar la frecuencia de emisin de CRLs para el subrbol bajo la PCA, la direccin en la que las CAs subordinadas debern depositar las CRLs emitidas, la direccin de consulta de CRLs, los procedimientos adicionales como almacenamiento de CRLs antiguas y las posibles ayudas que pueda tener de CAs para mantener y gestionar las CRLs.
18
Otras Polticas. Se puede aadir cualquier otra informacin que deban conocer los usuarios, teniendo en cuenta que los documentos de poltica se consideran casi inmutables y de larga duracin.
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 de una persona, servidor o programa. Actuara como una especie de notario electrnico. Su funcin principal es el de avalar los datos de cualquier certificado emitido por la PKI, el problema si la CA avala, quien le aval a ella?, para el caso de nuestro modelo, si bien se puede partir de una entidad fiable y la creacin de certificados raz autoafirmadas, esto no es recomendable, lo correcto y buen camino 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 esquema jerrquico de autoridades certificadoras, formndose as una cadena de certificados, en los que unas AC se avalan a otras hasta llegar a la AC superior, que se avala a s misma. Esta jerarqua de firmas y la cadena con ella formada estn contempladas en el estndar X.509 v3, que indica la forma correcta de realizar estas cadenas de certificaciones. El Certificado Digital vincula pues indisolublemente a una persona o entidad con una llave pblica, y mediante el sistema de firma digital se asegura que el certificado que recibimos es realmente de la persona que consta en el mismo. El sistema de firma digital liga un documento digital con una clave de cifrado. Caractersticas recomendables de una CA: Independencia (ausencia de inters financiero o de otro tipo en las transacciones subyacentes). Recursos y capacidad financiera para asumir la responsabilidad por el riesgo de prdida Experiencia en tecnologas de clave pblica y familiaridad con procedimientos de seguridad apropiados. Longevidad (tiempo de conservacin de certificados). Aprobacin del equipo y los programas utilizados por terceros. Mantenimiento de un registro de auditoria y realizacin de auditorias por una entidad independiente. Existencia de un Plan de Contingencia para casos de emergencia Seleccin y administracin del personal. Disposiciones para proteger su propia clave privada Seguridad interna. Disposiciones para suspender las operaciones, incluida la notificacin a los usuarios. Garantas y representaciones. Limitacin de la responsabilidad. Seguros. Capacidad para intercambiar datos con otras autoridades certificadoras. Procedimientos de revocacin.
19
CA
Aplicacin de Politicas de Seguridad, Normas y Procedimientos
Certificacin
Sistema de Generacin de Claves Generacin de Certificados Sistema de Distribucin de Certificados Procedimiento de Revocacin Publicacion de CRLs
Repositorio de Llaves
Repositorio de Certificados
CRLs
Figura 2.2.2. Especificacin 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 los usuarios y entrega la solicitud de certificado al CA. La calidad de este proceso de autentificacin establece el nivel de confianza que puede otorgarse a los certificados. Las RAs no realizan ninguna labor de certificacin, su funcionalidad es la de registrar a las entidades o usuarios finales. Es decir, estas Autoridades se encargaran de garantizar que el binomio formado por una entidad y el par de claves que la identifica, slo este registrado una sola vez. Las Autoridades de Registro estarn asociadas a las distintas Autoridades de Certificacin que definen la jerarqua de un rbol, tanto a las Autoridades del nodo PCA, como a las CAs normales. Aunque en el Modelo las RAs son entidades lgicas separadas de las CAs, en la prctica pueden ser una misma entidad fsica, con un mismo DN (Distinguished Name). Es decir, una CA puede tener asociada y ubicada fsicamente en el mismo sitio, a una RA que se encargue del registro de las entidades a las que certifica. Para garantizar la validez del procedimiento de registro, cada RA deber tener un par de claves asimtricas, con la clave pblica certificada por una CA que sea un punto de confianza de todas las CAs para las que realiza funciones de registro. Cuando una RA y una CA coincidan fsicamente, la RA podr considerar el par de claves de la CA y su certificado como propios. Las RAs pueden abrir varias oficinas regionales dispersas por todo el pas, llegando hasta los usuarios en los sitios ms remotos, mientras que la AC se limitara as a certificar a todos los usuarios aceptados por las RAs dependientes de ella. Gracias a esta descentralizacin se agiliza el proceso de certificacin y se aumenta la eficacia en la gestin de solicitudes.
Una PKI incluir una o varias Autoridades de Registro para certificar la identidad de los usuarios; una o varias Autoridades de Certificacin que emitan los certificados de clave pblica; un repositorio de certificados, accesible va web u otro medio, donde se almacenen los certificados; las listas de revocacin de certificados (CRL), donde se listan los certificados suspendidos o revocados; y, por supuesto, los propios certificados.
RA
Aplicacin de Politicas de Seguridad, Normas y Procedimientos de Registro
Registro en Linea (Web)
Registro Fsico
Sistema de Registro en Linea Sistema de Verificacin Automtica de Datos
Sistema de Registro Fsico
Repositorio de Solicitudes
Repositorio de Solicitudes
Verificacin manual de Datos - Presentacin de Documentos
Figura 2.2.3. Especificacin de la CA 2.3. Funciones de la PKI Las funciones que la plataforma deber ofrecer son las siguientes:
Autoridad de Registro 2. Datos del Usuario Autoridad de Certificacin
1. -Verificacin y Validacin
3. Clave Pblica 4. Certificado
5. Publicacin
6. Certificado de Clave Pblica Usuario
Directorio de Servicios
Generacin de Llaves
Base de Datos
Figura 2.3. Funciones de la PKI

2.3.1. Atencin de Solicitud de Certificados La emisin de Certificados de Identidad Personal exigen el reconocimiento previo de todos aquellos elementos caractersticos y nicos que son propios del solicitante; a estos caracteres se les denomina identificadores intrnsecos (fotografa, firma manuscrita, huellas dactilares, timbre de voz, fondo de ojo, marcas de nacimiento, etc.). Segn el nmero e importancia de los identificadores intrnsecos que las Autoridades de Registro verifican, registran y archivan para la emisin de sus certificados de identidad, diferente ser la confianza que stos puedan ofrecer. Una Autoridad de Registro puede requerir slo el Carnet de Identidad y comprobar que la fotografa y la apariencia del solicitante coinciden, en el caso de personas, en el caso de equipos electrnicos, servidores, computadores, podra ser adems algunas caractersticas del equipo (ej. Nro de Serie). 2.3.1.1. Generacin y Registro de Claves.
La generacin y registro de claves, es tambin un pilar fundamental, y cualquiera que desee firmar digitalmente mensajes o recibir envos cifrados y/o firmarlos, debe poseer un par de claves dentro de algn criptosistema de clave pblica. Es ms, otras entidades de la red como son las estaciones de trabajo, los servidores, las impresoras, etc., tambin pueden (y deben) tener sus pares de claves; de la misma forma que lo harn las personas. Dado que la identidad de cada entidad se basa en el secreto de una de las claves, la privada, cada usuario deber generar por sus propios medios su par de claves, para el modelo se propone un Subsistema para la generacin de Claves por parte del usuario, es decir una aplicacin donde el usuario o entidad final pueda llenar los datos de la Solicitud del Registro y adems pueda genera sus claves, lgicamente la aplicacin ser tambin de fuente abierta. Tambin el modelo considera la disponibilidad de que las entidades puedan generar sus claves a travs de un portal o pagina web (lgicamente con elementos o componentes que se ejecuten en el equipo del Cliente) En cualquier caso, las claves privadas nunca deben viajar por la red y habrn de ser distribuidas a travs de canales no telemticos de seguridad y confidencialidad probadas. Una vez, completado la solicitud y generacin las claves, la entidad final debe registrar su clave pblica ante la Autoridad de Certificacin a travs de una Autoridad de Registro aceptada dentro del escenario. Para la inscripcin slo tiene que enviar su clave pblica y, el documento digital de solicitud firmado con dicha clave. Para completar el proceso de inscripcin, el solicitante deber: o bien enviar otro Certificado Digital de Identidad expedido por alguna otra Autoridad de Certificacin aceptada, o bien deber enviar un documento fsico vlido dentro de los procedimientos administrativos habituales en el que asume la responsabilidad del compromiso indicado en la solicitud digital que ha enviado.
2.3.2. Emisin de Certificado Satisfechas las condiciones marcadas por la Autoridad de Registro en su documento pblico de Poltica de Emisin de Certificados incluida en su Poltica de Seguridad, esta autoridad enva todos los documentos a la Autoridad de Certificacin, la cual podr generar el certificado correspondiente y
devolver al solicitante un certificado digital que atestigua la validez de su clave pblica para actuar dentro del sistema. El certificado que se utiliza en el Modelo, es el certificado X.509 en su versin 3. Esto es conveniente de utilizar por la definicin de extensiones que tiene y poder incluir informacin relativa a la poltica de certificacin, al uso del certificado y a la identificacin del camino de certificacin. 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 Certificacin pasa al estado de Suspendido. Con ello no se invalida de forma irreversible el certificado, sino que se le retira de circulacin hasta que se le vuelva a dar el estado de Activo. Revocado: Cuando las condiciones que llevaron a la emisin de un certificado cambian antes de que ste expire, y son de importancia suficiente, la Autoridad de Certificacin deber anularlo; para ello, emite un segundo certificado especial, denominado de revocacin, por el cual, desde ese instante desautoriza 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 es posterior a la fecha de caducidad indicada en el propio certificado. El estado de certificado caducado no le resta valor histrico ya que, mientras estuvo activo, las operaciones en las que particip eran perfectamente vlidas.
La Autoridad de Certificacin debe tener en todo momento registrado cuales son los estados en los que se encuentran sus certificados. En la literatura informtica se habla de las Listas de Certificados Revocados o CRLs, como unas listas negras en las que la entidad, pblica a los cuatro vientos cuales son los certificados que ha anulado para, con ello, desentenderse de las responsabilidades que pudieran acarrear la utilizacin y/o aceptacin por parte de alguna entidad de los mencionados certificados. Segn la importancia de las transacciones que realicen las entidades basndose en los certificados digitales que utilizan, algunas veces no ser necesario que consulten si las credenciales presentadas estn todava vigentes en el momento de la transaccin, pero habr otros casos en los que este requisito sea absolutamente necesario, por lo que la entidad se pondr en contacto con la Autoridad de Certificacin y le consultara por el estado de vigencia (actividad) de ese certificado en concreto (nmero de referencia). 2.3.3. Almacenamiento en la CA de llaves La Autoridad de Certificacin, se encargan de verificar las condiciones que a parecen en sus polticas pblicas 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 Certificacin es firmador digital, para lo cual deben disponer de una clave privada que slo conocen ellos y que custodian con niveles de seguridad iguales o superiores a los declarados pblicamente. Para conseguir este nivel de seguridad para las claves privadas de la CA, stas se generan y almacenan permanentemente en unidades hardware de alta seguridad (recomendable), sometidas a sofisticadas medidas de seguridad fsica y dentro de entornos a prueba de intrusin electrnica, que es lo recomendado y aconsejable. A dichas unidades se las denomina Unidades de Firmado de Certificados, CSU. Estas unidades son, por su naturaleza, irrepetibles, y estn diseadas para que, ante la sospecha de cualquier intento de intromisin, las claves y dems informaciones relacionadas con ellas se destruyan antes de que puedan ser alcanzadas desde el exterior.
Las CSUs estn fsicamente apantalladas para evitar ataques electromagnticos, y tienen un amplio conjunto de sensores tolerantes a fallos permanentemente a la escucha de cualquier sntoma que pueda indicar la existencia de un ataque. Los administradores de la Autoridad de Certificacin no tienen acceso a la clave privada, sino a un equipo hardware que firma los documentos que stos le entreguen. Lamentablemente, por el alto costo de estos equipos, y la inexistencia de espacios fsicos para ello, en este modelo propuesto no se considera este punto, sino ms bien de la existencia de una Base de datos referente a ella, con la proteccin y seguridad, que nos brinda los algoritmos criptogrficos. Tambin la utilizacin de Software Libre para la implementacin del modelo, hace que se utilice una aplicacin especial 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 en aquellos en los que no se utiliza. En aquellos entornos en los que se utiliza el Directorio X.500, el mecanismo de almacenamiento y obtencin de certificados y CRLs se simplifica. Cada entidad de una infraestructura queda unvocamente identificada por su DN X.500 que indica cul es su entrada en el Directorio. La recomendacin X.500 define los atributos necesarios para almacenar la informacin relativa a certificacin en el Directorio, de forma que cada entidad puede almacenar sus certificados en la correspondiente entrada. Si la entidad es una CA, adems de sus certificados, en su entrada puede almacenar las CRLs asociadas. Cuando una entidad necesita obtener un certificado de otra entidad o una CRL, una vez identificado el nombre de la otra entidad, puede localizar la informacin buscada en la entrada del Directorio de la otra entidad y la puede extraer, ya que estos atributos se configuran con permiso de lectura para todo el mundo. En el caso de utilizacin del Directorio como lugar de almacenamiento de certificados y CRLs es recomendable que el acceso al Directorio sea seguro. La utilizacin del Directorio X.500, para este modelo es opcional, pro la razn de que se tienen aplicaciones un poco mas seguras (ej. Base de Datos en MySQL). En el Modelo se propone, que cada Autoridad de Certificacin tenga asociado un servidor de certificados y CRLs que permita la obtencin por parte de cualquier usuario, del certificado de la propia CA, de las CRLs que tenga asociadas y de cualquier certificado que haya sido emitido por ella. Este servidor obtendr los certificados de una base de datos local asociada a la CA, o bien del Directorio X.500. Lo usual en las distintas aplicaciones que incorporan servicios de seguridad, es que se produzca un intercambio inicial de los certificados de las entidades comunicantes. Otro aspecto relacionado con el almacenamiento de certificados y CRLs, es que los usuarios finales generalmente realizan comunicaciones con un grupo limitado y ms o menos estable de participantes. 2.3.5. Polticas de Certificacin Ya se abordo el tema de las Polticas de Seguridad que tiene que ser definidas por la PCA, sin embargo tambin y de acuerdo al dominio de aplicacin se podra tener algunas Polticas de Seguridad Propias de cada CA. Procedimientos para el registro de usuarios. Se deben definir los mecanismos para la identificacin y aceptacin de usuarios finales.
24
Procedimientos para la gestin de claves. Se deben definir aspectos relacionados con la generacin, distribucin y validez de las claves. Tambin se deben especificar los mecanismos de distribucin permitidos, el tamao de las claves y su perodo de validez. Registro y auditoria. Se deben definir los mecanismos necesarios para registrar y auditar los eventos y la informacin que resulte necesaria para garantizar la proteccin de una CA y los usuarios que dependen de ella.
2.3.6. Servicios de Certificacin Uno de los mecanismos ms utilizados en entornos de seguridad, y que ms ligado se encuentra a los modelos de certificacin basados en la utilizacin de claves asimtricas, es la firma digital. El proceso de verificacin de una firma digital implica la utilizacin de la correspondiente clave pblica. Para confiar en la validez de esta clave es necesario comprobar la validez de su certificado. El uso de claves pblicas para proporcionar el servicio de confidencialidad, bien directamente, o bien utilizando una cubierta digital, implica tambin la validacin del correspondiente certificado. En general se puede decir, que cualquier proceso de verificacin o validacin de mecanismos de seguridad basados en tcnicas criptogrficas asimtricas, implica la validacin del certificado de la correspondiente clave pblica, proceso a que a su vez lleva implcita la validacin de una cadena de certificados que garantice el establecimiento de la confianza entre dos entidades. El proceso de validacin o certificacin se puede realizar de la siguiente manera Obtencin del certificado a validar o certificar Determinacin de la posibilidad de establecer la confianza entre las entidades implicadas. En caso de poder establecer la confianza, identificacin de los certificados necesarios en el proceso. Obtencin de los certificados identificados.
Como todos los usuarios operaran bajo la misma poltica siempre se puede establecer la confianza entre ellos. El nodo comn en el rbol ser siempre la CA que los certifica a todos, y el certificado en el que finaliza el proceso de validacin es el certificado autofirmado por la propia CA. 2.3.7. Servicios de Revocacin de Certificados Los certificados que no han vencido su perodo de validez pueden ser revocados por la Autoridad que los emiti. La principal causa de la revocacin es que se haya detectado un compromiso de la clave secreta asociada, aunque pueden existir otros motivos, como pueden ser el cese de la actividad para que el certificado haya sido emitido, que el propietario del certificado cambie de papel dentro del grupo o cambie de afiliacin, o simplemente, que la CA emisora decida revocarlo. En cualquier caso la decisin de revocar un certificado debe ser tomada por la CA emisora, pero se permite a cada usuario que pueda solicitar la revocacin de su propio certificado. En el caso de que la solicitud de revocacin de un certificado provenga de una entidad que no es la propietaria, es responsabilidad de la CA comprobar los motivos por los que se solicita la revocacin. Al igual que la renovacin de un certificado de una CA implica la revocacin de todos certificados que dependen del mismo, la revocacin del certificado de una CA produce el mismo efecto, con la diferencia de que si el certificado revocado no es sustituido por uno nuevo.
25
2.4. Escenarios de Aplicacin Los escenarios de aplicacin del modelo puede ser varias: (Comunicaciones entre servidores, Correo electrnico, Intercambio Electrnico de Datos (EDI), Redes Privadas Virtuales (VPN)). Pero el modelo propuesto esta mas orientado a lo que es el Intercambio Electrnico de Datos, o Seguridad en las transacciones electrnicas especficamente en las Entidades Estatales.
26
3. PARTE III, INSTALACION E IMPLEMENTACION 3.1. Software a Utilizar Software GNU/Linux Apache WWW Server modssl SSL/TLS Apache module Shared Memory Allocation-mm OpenSSL SSL/TLS software OpenLDAP LDAP software MySQL OpenCA Perl interpreter Modulos perl (CPAN) Propsito Sitio - url Plataforma de la implementacin www.linux.org del Modelo Como servidor de paginas Web, www.apache.org solicitud, registro, listado de CLRs www.modssl.org www.ossp.org/pkg/lib/mm/ Asegurar las transacciones, publicar www.openssl.org paginas web seguras (https://) Para soporte de Directorio X.500 www.openldap.org (opcional) Servidor de Base de Datos www.mysql.com Para soporte de Servidor CA y www.openca.org Servidor RA Para compilar todas las www.perl.org herramientas Algunas libreras y mdulos que www.cpan.org son necesarias durante la instalacin de los diferentes mdulos.
Linux, es un Sistema Operativo libre, el cual podemos utilizarlo, para la instalacin utilizaremos la versin de Red Hat 9. SSL es un protocolo seguro de Internet inventado por la Empresa NetScape, No es exclusivo del Comercio Electrnico, por el contrario sirve para cualquier comunicacin va protocolos TCP/IP y, por lo tanto, tambin para transacciones administrativas. Este protocolo esta implementado por defecto en todos los navegadores. Se instalara la versin 0.9.8 de OPENSSL: Apache, es uno de los ms extendidos servidores de Internet, se instalara la versin Apache_1.3.33 Mod_ssl, es un modulo complemento a lo que es el servidor Apache adicionando a este caractersticas de seguridad, Mod_ssl-2.8.23-1.3.33 MySQL, es un servidor de Base de Datos, flexible y potente, se utilizar la versin mysql-standard4.0.20-pc-linux-i686. OpenCA, es un servidor para Autoridades de Certificacin, se utilizara la versin openca-0.9.2.2 MM, son mdulos para compartir memoria, que son necesarios en ambientes seguros, Mm_1.3.1 La instalacin deber realizarse segn el orden establecido lneas mas abajo: 1. 2. 3. 4. 5. 6. Openssl-0.9.8 Mm_1.3.1 Mod_ssl-2.8.23-1.3.33 Apache_1.3.33 MySQL-standard-4.0.20-pc-linux-i686. OpenCA-0.9.2.2
27
3.1.1.Sistema Operativo Para la instalacin e implementacin de la PKI, se utilizara Linux Red Hat, en su versin 9, la instalacin al ser sencillo no necesita de mas comentarios, eso si la Instalacin se lo realiza con solo algunos componentes mnimos, No se instala mod_ssl, no se instala openssl, entre otros. 3.1.2. OPEN SSL La instalacin 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 instalacin del servidor apache # /usr/local/apache/bin/apachectl start http://localhost # /usr/local/apache/bin/apachectl stop Comprobamos la instalacin con SSL # /usr/local/apache/bin/apachectl startssl https://localhost
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 caractersticas y lo ejecutamos, como Autoridad de Certificacin: Archivo ./configure.redhat.ca #!/bin/sh PREFIX=$1 VER=0.9.1 if [ -z "${PREFIX}" ] ; then PREFIX=/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 \
--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="webmaster@pkibolivia.org" # ./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=$1 VER=0.9.1 if [ -z "${PREFIX}" ] ; then PREFIX=/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 \
--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 \ --with-service-mail-account=webmaster@pkibolivia.org # ./configure.redhat.ra # make ra
Luego de todo el proceso de instalacin se deber configurar algunos archivos que nos permitirn mejorar la seguridad de nuestra plataforma Editar el archivo /usr/local/apache/conf/httpd.conf adicionando dos paginas virtuales. <IfDefine SSL> Listen 80 Listen 443 Listen 1010 Listen 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.org ServerAdmin webmaster@pkibolivia.org ErrorLog /usr/local/openca.0.9.1/logs/ca_ca-error_log CustomLog /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.org ServerAdmin webmaster@pkibolivia.org ErrorLog /usr/local/openca.0.9.1/logs/ra_ra-error_log CustomLog /usr/local/openca.0.9.1/logs/ra_ra-access_log common </VirtualHost>
31
32
33
4. PARTE IV, CONCLUSIONES Y RECOMENDACIONES 4.1. Conclusiones La consideracin de una buena Infraestructura de Clave Pblica es de gran relevancia, pues esto podr delimitar el marco de accin de las transacciones realizadas. Es necesario introducir y reglamentar adecuadamente a las denominadas Autoridades de Certificacin como emisoras de Certificados Digitales que den fe de que los usuarios poseen ciertos atributos y las calificaciones necesarias para realizar ciertas transacciones ya sean estas administrativas y/o electrnicas. A falta de leyes y reglamentaciones en nuestro pas, es necesario iniciar el estudio de las posibles normativas que deban aplicarse a los certificados digitales, firmas, criptografa as como tambin, la regulacin de las Autoridades de Certificacin, y sus caractersticas que conllevan. Aunque ya se tenga un borrador del Ante proyecto de Ley. Es muy importante la base de los certificados X.509, y algunas de sus extensiones, para el planteamiento del modelo, y los procedimientos a seguir para la implantacin del modelo. La utilizacin de mecanismos de seguridad basados en criptografa de clave pblica conlleva la necesidad de establecer un sistema de certificacin que garantice la propiedad de las claves. Los sistemas de certificacin que ofrecen un esquema de confianza ms robusto, son aquellos que basan la confianza en terceras partes, las cuales reciben el nombre de Autoridades de Certificacin. As mismo la utilizacin de las Firmas Digitales, son de vital importancia, para asegurar las transacciones realizadas, a travs de las redes, interconectadas, puestas aseguran y minimizan los riesgos, de modificacin y autenticacin de las entidades involucradas en dicha transaccin. Cuando los entornos de certificacin engloban a un nmero de entidades significativo, es necesario plantearse la necesidad de distribuir las tareas de certificacin entre varias Autoridades. En el caso de existir 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, sino ms definir estos procedimientos a sectores especficos o particularizados. El planteamiento del modelo, es una novedad en nuestro pas, debido a la inexistencia de estos, y lgicamente a la falta de leyes que normen y reglamenten este tipo de tecnologa. 4.2. Recomendaciones Que el gobierno, se encargue de promover la creacin y difusin de contenidos tecnologicos, para el mismo bienestar de las Entidades Estatales. Formar un Grupo investigativo sobres estas tecnologas y aprovechar el mximo del software libre para el beneficio de nuestras entidades estatales. Encontrar o crear un ente coordinador, para la implementacin 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 este propsito.
5. BIBLIOGRAFIA [Lucena, 2003], Lucena, Lpez Manuel Jos, Criptografa y Seguridad en Computadores, tercera edicin, 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 Users Guide, Ago. 1994. [RSA, 2001], http://www.rsa.com [AGUIRRE, 1999], Rami Aguirre Jorge, Aplicaciones Criptogrficas, segunda edicin, Universidad Politcnica 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, Santidran Lourdes, Organizacin y jerarquizacin de Autoridades de Certificacin para la provisin de servicios de Seguridad en redes telemticas, Facultad de Informtica, Universidad Politcnica de Madrid, 1998 Comercio Electrnico en Bolivia, www.marketing-rentable.com/marketing-4/comercio-electronicoen-bolivia.html Estadisticas sobre Bolivia, www.boliviabiz.com Centro de Promocin Bolivia (Ceprobol), www.b2bolivia.com.bo Bolivia y el Comercio Electrnico, 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.org www.modssl.org www.openldap.org www.mysql.com www.perl.org www.ossp.org/pkg/lib/mm/ www.cpan.org
35

PKI y Software Libre

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

PKI y Software Libre

Hochgeladen von

Copyright:

Verfügbare Formate

RESUMEN

Remberto Gonzales Cruz e-mail: rembert@usfx.edu.bo, rembertus@gmail.com

Remberto Gonzales Cruz e-mail: rembert@usfx.edu.bo, rembertus@gmail.com

Remberto Gonzales Cruz e-mail: rembert@usfx.edu.bo, rembertus@gmail.com

Remberto Gonzales Cruz e-mail: rembert@usfx.edu.bo, rembertus@gmail.com

Remberto Gonzales Cruz e-mail: rembert@usfx.edu.bo, rembertus@gmail.com

Texto en Claro (plain text)

Criptograma (cipher text)

Texto en Claro (plain text)

Criptograma (cipher text)

Texto en Claro (plain text)

Texto en Claro (plain text)

Criptograma (cipher text)

Texto en Claro (plain text)

Remberto Gonzales Cruz e-mail: rembert@usfx.edu.bo, rembertus@gmail.com

Texto en Claro (plain text)

Resumen Del texto

Resumen Firmado con la Llave Privada

(plain text) + FIRMA

Llave Privada para Firmar

Remberto Gonzales Cruz e-mail: rembert@usfx.edu.bo, rembertus@gmail.com

Remberto Gonzales Cruz e-mail: rembert@usfx.edu.bo, rembertus@gmail.com

Figura 1.5.1.1. Arquitectura de EuPKI

Remberto Gonzales Cruz e-mail: rembert@usfx.edu.bo, rembertus@gmail.com

Remberto Gonzales Cruz e-mail: rembert@usfx.edu.bo, rembertus@gmail.com

Figura 1.5.3.1. Arquitectura PEM

Remberto Gonzales Cruz e-mail: rembert@usfx.edu.bo, rembertus@gmail.com

Remberto Gonzales Cruz e-mail: rembert@usfx.edu.bo, rembertus@gmail.com

SI NO SI/NO CA RA (CKGS, UKGS, CSP, KA) Comercio Electrnico, e-administracin

Remberto Gonzales Cruz e-mail: rembert@usfx.edu.bo, rembertus@gmail.com

2.1. Especificacin de la Arquitectura PKI

Politicas de Seguridad, Normas y Procedimientos

Privacidad y seguridad de la PCA

Remberto Gonzales Cruz e-mail: rembert@usfx.edu.bo, rembertus@gmail.com

Remberto Gonzales Cruz e-mail: rembert@usfx.edu.bo, rembertus@gmail.com

Aplicacin de Politicas de Seguridad, Normas y Procedimientos

Aplicacin de Politicas de Seguridad, Normas y Procedimientos de Registro

Registro en Linea (Web)

Sistema de Registro en Linea Sistema de Verificacin Automtica de Datos

Sistema de Registro Fsico

Verificacin manual de Datos - Presentacin de Documentos

3. Clave Pblica 4. Certificado

6. Certificado de Clave Pblica Usuario

Figura 2.3. Funciones de la PKI

Remberto Gonzales Cruz e-mail: rembert@usfx.edu.bo, rembertus@gmail.com

Remberto Gonzales Cruz e-mail: rembert@usfx.edu.bo, rembertus@gmail.com

Remberto Gonzales Cruz e-mail: rembert@usfx.edu.bo, rembertus@gmail.com

Remberto Gonzales Cruz e-mail: rembert@usfx.edu.bo, rembertus@gmail.com

Remberto Gonzales Cruz e-mail: rembert@usfx.edu.bo, rembertus@gmail.com

Remberto Gonzales Cruz e-mail: rembert@usfx.edu.bo, rembertus@gmail.com

Remberto Gonzales Cruz e-mail: rembert@usfx.edu.bo, rembertus@gmail.com

Remberto Gonzales Cruz e-mail: rembert@usfx.edu.bo, rembertus@gmail.com

Das könnte Ihnen auch gefallen