Changeset aab7301 in libros
- Timestamp:
- Apr 28, 2014, 4:59:48 PM (10 years ago)
- Branches:
- master, revisionfinal
- Children:
- ed97591
- Parents:
- 36f1601
- Location:
- maquetacion
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
maquetacion/capitulo1/certificadosElectronicos.tex
rdcee5d3 raab7301 1 1 \subsubsection{Certificados electrónicos} 2 \label{subsubsection:certificadosElectronicos} 2 3 3 4 -
maquetacion/capitulo5/capitulo5.tex
rdcee5d3 raab7301 6 6 7 7 8 9 10 11 12 A continuación el contenido del artículo de ROOTVE 8 La gestión de certificados electrónicos de una Infraestructura 9 de Clave Pública (ICP) para establecer identidades digitales se conoce como 10 Certificación Electrónica. Entre los procesos de gestión están la generación, 11 almacenamiento y publicación de certificados, así como la publicación de información 12 y consulta del estado de vigencia y validez de los mismos. 13 14 En la sección \ref{subsubsection:certificadosElectronicos} se presentó el 15 certificado electrónico como un documento electrónico que permite establecer 16 la identidad digital de personas y/o dispositivos. 17 18 13 19 14 20 15 21 %\begin{abstract} 16 Una Autoridad de Certificación Raíz (AC Raíz) es un componente que tiene el rol de ser el 17 punto más alto de confianza en una estructura jerárquica denominada Infraestructura de Clave 18 Pública (ICP). Una ICP provee de certificados digitales bajo estándar X.509 a personas, 19 direcciones IP y direcciones en la Web; proporcionando seguridad lógica, y vinculación 20 legal a las transacciones que realiza el propietario del certificado en 21 la Internet. La confianza reside en la protección a través de esquemas fuertes de 22 seguridad física y lógica de la clave privada que permite la emisión de estos certificados. Este trabajo muestra el proceso de desarrollo de una aplicación para gestionar el componente mencionado utilizando bibliotecas, herramientas, compiladores, sistemas operativos y licencias compatibles con los principios del software libre. En primer lugar, se determinan los requisitos a ser satisfechos en función de una descripción general de las funciones y características de una 23 Autoridad de Certificación; posteriormente, se dise~nan funcionalidades y se especifican requisitos, con el objetivo de producir una visión formal de los procesos a automatizar. Se dedica una sección a la implementación que consiste, en la codificación en un lenguaje de programación, de los procesos previstos en las etapas anteriores, como también, de la incorporación de mecanismos fuertes de validación de identidad de usuarios, registro de eventos, firma de acciones por parte de los administradores de la aplicación, y especificación de conexiones con hardware especializado, como tarjetas inteligentes. Finalmente, se muestra el despliegue y configuración de la aplicación, que involucra la instalación en un ambiente seguro (bóveda o centro de datos) y el enlace de la AC Raíz con los demás componentes de la infraestructura. 22 Una Autoridad de Certificación Raíz (AC Raíz) es un componente que tiene el rol de ser el 23 punto más alto de confianza en un ICP. Una ICP genera certificados electrónicos de acuerdo al 24 estándar X.509 proporcionando seguridad lógica, y vinculación 25 legal a las transacciones que realiza el titular del certificado en 26 la Internet. La confianza reside en la protección, a través de esquemas fuertes de 27 seguridad física y lógica, de la clave privada que permite la generación de estos certificados. 28 29 %Este trabajo muestra el proceso de desarrollo de una aplicación para gestionar el 30 En este capítulo se describe el proceso de desarrollo de una aplicación para gestionar 31 una Autoridad de Certificación Raíz utilizando bibliotecas, herramientas, compiladores, 32 sistemas operativos y licencias compatibles con los principios del software libre. 33 En primer lugar, se determinan los requisitos a ser satisfechos en función de una 34 descripción general de las funciones y características de una Autoridad de 35 Certificación; posteriormente, se dise~nan funcionalidades y se especifican 36 requisitos, con el objetivo de producir una visión formal de los procesos a 37 automatizar. Se dedica una sección de este capítulo a la implementación que consiste 38 en la codificación en un lenguaje de programación, de los procesos previstos en las 39 etapas anteriores, como también, de la incorporación de mecanismos fuertes de 40 validación de identidad de usuarios, registro de eventos, firma de acciones por parte 41 de los administradores de la aplicación, y especificación de conexiones con hardware 42 especializado, como tarjetas inteligentes. Finalmente, se describe el despliegue y 43 configuración de la aplicación, que involucra la instalación en un ambiente seguro 44 (bóveda o centro de datos) y el enlace de la AC Raíz con los demás componentes 45 de la infraestructura. 24 46 25 47 … … 27 49 28 50 %\begin{abstract} 29 A Certification Authority Root (CA Root) is a component which role is to represent the highest confidence point in a hierarchical structure denominated Public Key Infrastructure (PKI). A PKI provides people, IP addresses and Web domains with digital certificates under X.509 standard, offering logic security and legal entailment to transactions performed on the internet by the certificate’s owner. Confidence resides in private key protection through strong physical and logical security schemes, so these schemes allow the certificate emission. This work shows the development process of a CA root management application. For this development it's used libraries, tools, compilers, operating systems and licenses compatible with the principles of free software. In first place, the requirements to satisfy are determined based on a general description of a CA's functions and characteristics; subsequently, functionalities are designed and requirements are specified in order to produce a formal vision of the processes30 to automate. A section is dedicated to the implementation, this consists on codification in a programming language of the processes forseen in the previous stages, like also, of the incorporation of strong mechanisms of validation of identity of users, registry of events, actions signature by application's administrators, and connections specification with specialized hardware, like smart cards. Finally, application display and configuration are shown, it involves its installation in a safe environment (vault or data center) and CA Root connection with other components of the infrastructure.51 %A Certification Authority Root (CA Root) is a component which role is to represent the highest confidence point in a hierarchical structure denominated Public Key Infrastructure (PKI). A PKI provides people, IP addresses and Web domains with digital certificates under X.509 standard, offering logic security and legal entailment to transactions performed on the internet by the certificate’s owner. Confidence resides in private key protection through strong physical and logical security schemes, so these schemes allow the certificate emission. This work shows the development process of a CA root management application. For this development it's used libraries, tools, compilers, operating systems and licenses compatible with the principles of free software. In first place, the requirements to satisfy are determined based on a general description of a CA's functions and characteristics; subsequently, functionalities are designed and requirements are specified in order to produce a formal vision of the processes 52 %to automate. A section is dedicated to the implementation, this consists on codification in a programming language of the processes forseen in the previous stages, like also, of the incorporation of strong mechanisms of validation of identity of users, registry of events, actions signature by application's administrators, and connections specification with specialized hardware, like smart cards. Finally, application display and configuration are shown, it involves its installation in a safe environment (vault or data center) and CA Root connection with other components of the infrastructure. 31 53 %\end{abstract} 32 54 … … 37 59 \section{Introducción} 38 60 39 \label{sec:intro}La disponibilidad de Internet como medio digital seguro permite que cualquier persona, empresa, institución, o administración realice transacciones gubernamentales, comerciales o personales en la mayoría de los casos, tal cual, como se realizarían en una oficina o espacio físico de forma presencial. Dado este hecho, al utilizar Internet para establecer relaciones humanas, se está de acuerdo que es necesario trasladar el concepto de ``identidad'' al medio digital\cite{NIC:03}. La criptografía provee algoritmos y mecanismos para construir este concepto en la red, ya que es posible utilizar herramientas que aporten elementos para definir la identidad de un usuario, entidad o institución, de la misma forma de la que se está familiarizado en el mundo real. 40 41 En muchas ocasiones para realizar actividades cotidianas personales o de trabajo, se debe establecer contacto con un individuo u organización que no se conoce o del cuál no se tiene ninguna referencia. Mediante un contacto personal o directo, los sentidos humanos permiten percibir un gran número de detalles que le caracterizan, y cuya combinación muy probablemente le hace irrepetible. Esta combinación permite identificar al individuo de forma única y certera. Dicho esto, la identidad se define como el reconocimiento que se hace de las credenciales físicas o informativas, que ese individuo ofrece para que se le acepte como poseedor de una determinada individualidad \cite{STAL:03}. Las credenciales físicas pueden ser documentos como la Cédula de Identidad, el Pasaporte, la Licencia de Conducir, entre otros. Todos los documentos citados generalmente incluyen una fotografía que permite la comparación con la apariencia del interlocutor; también usualmente se agrega otra característica 42 informativa que puede ser un nombre, una firma manuscrita y posiblemente un número de referencia. 43 44 Cuando se traslada el concepto de identidad al medio informático, se habla de identidad digital, y se hace necesario contar credenciales traducibles a información binaria. Por otro lado, la criptografía, por sí misma no proporciona este concepto: es el uso de una infraestructura computacional que utiliza algoritmos criptográficos para representar credenciales digitales, como por ejemplo el certificado digital, y que son otorgados por terceros de confianza, denominados Autoridades de Certificación (AC), y que se describen como Raíz cuando son el punto inicial de una jerarquía, las que proveen a usuarios y organizaciones de identidad digital, y que cuenta con las mismas connotaciones que tiene este concepto en el ámbito personal y jurídico. 61 \label{sec:intro}La disponibilidad de Internet como medio digital seguro permite 62 que cualquier persona, empresa, institución, o administración realice transacciones 63 gubernamentales, comerciales o personales en la mayoría de los casos, tal cual, 64 como se realizarían en una oficina o espacio físico de forma presencial. Dado este 65 hecho, al utilizar Internet para establecer relaciones humanas, se está de acuerdo 66 que es necesario trasladar el concepto de ``identidad'' al medio digital\cite{NIC:03}. 67 La criptografía provee algoritmos y mecanismos para construir este concepto 68 en la red, ya que es posible utilizar herramientas que aporten elementos para 69 definir la identidad de un usuario, entidad o institución, de la misma forma de 70 la que se está familiarizado en el mundo real. 71 72 En muchas ocasiones para realizar actividades cotidianas personales o de trabajo, 73 se debe establecer contacto con un individuo u organización que no se conoce o del 74 cuál no se tiene ninguna referencia. Mediante un contacto personal o directo, los 75 sentidos humanos permiten percibir un gran número de detalles que le caracterizan, y 76 cuya combinación muy probablemente le hace irrepetible. Esta combinación permite 77 identificar al individuo de forma única y certera. Dicho esto, la identidad se 78 define como el reconocimiento que se hace de las credenciales físicas o informativas, 79 que ese individuo ofrece para que se le acepte como poseedor de una determinada 80 individualidad \cite{STAL:03}. Las credenciales físicas pueden ser documentos como 81 la Cédula de Identidad, el Pasaporte, la Licencia de Conducir, entre otros. Todos los 82 documentos citados generalmente incluyen una fotografía que permite la comparación 83 con la apariencia del interlocutor; también usualmente se agrega otra característica 84 informativa que puede ser un nombre, una firma manuscrita y posiblemente un número 85 de referencia. 86 87 Cuando se traslada el concepto de identidad al medio informático, se habla de 88 identidad digital, y se hace necesario contar credenciales traducibles a 89 información binaria. Por otro lado, la criptografía, por sí misma no proporciona este 90 concepto: es el uso de una infraestructura computacional que utiliza algoritmos 91 criptográficos para representar credenciales digitales, como por ejemplo el certificado 92 electrónico, y que son otorgados por terceros de confianza, denominados Autoridades 93 de Certificación (AC), y que se describen como Raíz cuando son el punto inicial de una 94 jerarquía, las que proveen a usuarios y organizaciones de identidad digital, y que 95 cuenta con las mismas connotaciones que tiene este concepto en el ámbito personal 96 y jurídico. 45 97 \\ 46 Uno de los problemas que aparece en este punto, en la disponibilidad de la infraestructura mencionada anteriormente, la cuál debe contar como un elemento obligatorio una aplicación que gestione, bajo un estándar aceptado, como lo es el estándar X.509\cite{NASH:02}, los certificados digitales que emite la AC. La discusión de importantes aspectos que surgen en las diferentes etapas del proceso desarrollo de la aplicación de gestión, y que están vinculados con los principios del software libre y los requisitos muy particulares del ambiente de despliegue, subrayan los objetivos de este trabajo. 98 Uno de los problemas que aparece en este punto, es la disponibilidad de la 99 infraestructura mencionada anteriormente, la cuál debe contar como un elemento 100 obligatorio una aplicación que gestione, bajo un estándar aceptado, como lo es el 101 estándar X.509\cite{NASH:02}, los certificados electrónicos que emite la AC. 102 La discusión de importantes aspectos que surgen en las diferentes etapas del 103 proceso desarrollo de la aplicación de gestión, y que están vinculados con los 104 principios del software libre y los requisitos muy particulares del ambiente 105 de despliegue, subrayan los objetivos propuestos en este capítulo. %de este trabajo. 47 106 48 107 \section{Marco Teórico} 49 108 50 Con el objetivo de contextualizar los términos ``identidad'', ``confianza'', o ``transacción segura'' y``AC Raíz'' en el medio digital, y específicamente en relación con internet; es imprescindible en una primera aproximación, discutir sobre determinados temas y conceptos vinculados con la seguridad informática. En los párrafos siguientes se abordan brevemente algunos de los puntos más importantes relacionados con el tema. 109 Con el objetivo de contextualizar los términos ``identidad'', ``confianza'', o 110 ``transacción segura'' y``AC Raíz'' en el medio digital, y específicamente en 111 relación con internet; es imprescindible en una primera aproximación, discutir sobre 112 determinados temas y conceptos vinculados con la seguridad informática. En los párrafos 113 siguientes se abordan brevemente algunos de los puntos más importantes relacionados con el tema. 51 114 52 115 \subsection{Seguridad Informática} 53 116 54 Se ha llegado a un consenso sobre lo que significa seguridad informática\cite{STAL:03}. En general, se dice que un activo de información, (información digital con un valor real para una empresa o persona) está asegurado si cumple con niveles aceptables relativos a su valor potencial en los siguientes aspectos: 117 Se ha llegado a un consenso sobre lo que significa seguridad informática\cite{STAL:03}. 118 En general, se dice que un activo de información, (información digital con un valor 119 real para una empresa o persona) está asegurado si cumple con niveles aceptables 120 relativos a su valor potencial en los siguientes aspectos: 55 121 \\ \\ 56 \textbf{Disponibilidad:} es el grado en que un dato está en el lugar, momento y forma en que es requerido por uno o un conjunto de usuarios autorizados. Como premisa, un sistema seguro debe mantener la información disponible para los usuarios autorizados. Disponibilidad también significa que el sistema, debe mantenerse funcionando eficientemente y es capaz de recuperarse rápidamente en caso de fallo. 122 \textbf{Disponibilidad:} es el grado en que un dato está en el lugar, momento y 123 forma en que es requerido por uno o un conjunto de usuarios autorizados. Como 124 premisa, un sistema seguro debe mantener la información disponible para los 125 usuarios autorizados. Disponibilidad también significa que el sistema, debe 126 mantenerse funcionando eficientemente y es capaz de recuperarse rápidamente 127 en caso de fallo. 57 128 \\ \\ 58 \textbf{Confidencialidad:} es el aspecto de la seguridad que permite mantener en secreto la información y solo los usuarios autorizados pueden manipularla. Igual que para la disponiblidad, los usuarios pueden ser personas, procesos o programas. Para evitar que nadie no autorizado pueda tener acceso a la información transferida y que recorre la Red se utilizan técnicas de cifrado o codificación de datos. Hay que mantener una cierta coherencia para determinar cuál es el grado de confidencialidad de la información que se está manejando, para así evitar un esfuerzo suplementario a la hora de decodificar una información previamente codificada. 129 \textbf{Confidencialidad:} es el aspecto de la seguridad que permite mantener en 130 secreto la información y solo los usuarios autorizados pueden manipularla. 131 Igual que para la disponibilidad, los usuarios pueden ser personas, procesos o 132 programas. Para evitar que nadie no autorizado pueda tener acceso a la información 133 transferida y que recorre la Red se utilizan técnicas de cifrado o codificación de 134 datos. Hay que mantener una cierta coherencia para determinar cuál es el grado de 135 confidencialidad de la información que se está manejando, para así evitar un esfuerzo 136 suplementario a la hora de decodificar una información previamente codificada. 59 137 \\ \\ 60 \textbf{Integridad:} corresponde a garantizar que la información transmitida entre dos entidades autorizadas no sea modificada por un tercero no autorizado. Un mecanismo para lograrlo es la utilización de firmas digitales. 61 Mediante una firma digital se codifican los mensajes a transferir, de forma que una función, denominada hash \cite{ACE:03}, calcula un resumen de dicho mensaje y se le a~nade. La validación de la integridad del mensaje se realiza aplicándole al original la misma función y comparando el resultado con el resumen que se a~nadió al final cuando se calculo por primera vez antes de enviarlo. 62 Mantener la integridad es importante para verificar que en el tiempo de viaje por la Red de la información entre el sitio emisor y receptor ningún agente externo o extra\~no ha modificado el mensaje. 138 \textbf{Integridad:} corresponde a garantizar que la información transmitida entre dos 139 entidades autorizadas no sea modificada por un tercero no autorizado. Un mecanismo 140 para lograrlo es la utilización de firmas electrónicas. 141 Mediante una firma electrónica se codifican los mensajes a transferir, de forma que una 142 función, denominada hash \cite{ACE:03}, calcula un resumen de dicho mensaje y se 143 le a~nade. La validación de la integridad del mensaje se realiza aplicándole al original la 144 misma función y comparando el resultado con el resumen que se a~nadió al final cuando 145 se calculó por primera vez antes de enviarlo. 146 Mantener la integridad es importante para verificar que en el tiempo de viaje por 147 la Red de la información entre el sitio emisor y receptor ningún agente externo o 148 extra\~no ha modificado el mensaje. 63 149 64 150 \subsection{Criptografía} 65 La criptografía es la ciencia o arte información utilizando técnicas matemáticas que hagan posible el intercambio de mensajes de manera que sólo puedan ser leídos por las personas o usuarios autorizados \cite{STAL:03}. La criptografía ha tomado gran importancia en los últimos a~nos, ya que es posible transformar las ``técnicas matemáticas'' en algoritmos que pueden ser comprendidos por una computadora. Se puede clasificar la criptografía en dos tipos, según el tipo de clave que se utilice: 66 67 \textbf{Criptografía Simétrica:} los sistemas de criptografía simétrica son aquellos que utilizan una única clave para cifrar y descifrar un texto claro. Este tipo de sistema conlleva una desventaja, que consiste en el conocimiento de las partes (emisor y receptor) de la clave única que les permite intercambiar información por un canal seguro. Como respuesta a ello, se hace necesario formalizar un procedimiento que muestre a las partes autorizadas la información sobre la clave, sin que sea develada a un tercero no autorizado. 68 69 \textbf{Criptografía Asimétrica:} también se conoce como Sistema de Cifrado de Clave Pública\cite{STAL:03}. Usa dos claves diferentes, una de ellas es la Clave Pública que puede ser enviada a cualquier persona y otra, que se denomina Clave Privada que es secreta, y no debe ser revelada. A diferencia del sistema de cifrado simétrico donde las partes deben concertar un procedimiento para conocer la clave única, en este tipo de sistema el remitente usa la clave pública del dest inatario para cifrar el documento. Una vez que el documento o mensaje ha sido cifrado, solamente con la clave privada del destinatario el mensaje puede ser descifrado. 70 71 \subsection{Certificados digitales} 72 73 Un certificado digital es un documento de acreditación que permite a las partes tener confianza en las transacciones que realicen en internet. Por tanto, garantiza la identidad de su poseedor mediante un sistema de claves administrado por una tercera parte de confianza. Para validar un certificado basta con conocer la clave pública de la tercera parte conocida como la Autoridad de Confianza (AC). Para cuidarnos de que piratas informáticos cambien su clave pública por la de la autoridad de confianza, la AC debe crear un certificado con su propia información de identidad y a la vez su clave pública y firmar el certificado, este certificado se le conoce como certificado autofirmado. 74 Dado que los certificados son información pública y lo que se desea es que todos tengan acceso a ellos, pueden hacerse copias del certificado de acuerdo sea necesario. Los certificados digitales permiten varias cosas, entre ellas se pueden citar que los usuarios pueden a~nadir firmas electrónicas a los formularios en línea; que los destinatarios pueden comprobar la autenticidad del correo electrónico confidencial; que los compradores pueden estar seguros de que un website es legítimo; y por último, controla el acceso a bancos y comercios online, así como los intranets y extranets. 151 La criptografía es la ciencia o arte información utilizando técnicas matemáticas 152 que hagan posible el intercambio de mensajes de manera que sólo puedan ser leídos 153 por las personas o usuarios autorizados \cite{STAL:03}. La criptografía ha tomado 154 gran importancia en los últimos a~nos, ya que es posible transformar las 155 ``técnicas matemáticas'' en algoritmos que pueden ser comprendidos por una computadora. 156 Se puede clasificar la criptografía en dos tipos, según el tipo de clave que se utilice: 157 158 \textbf{Criptografía Simétrica:} los sistemas de criptografía simétrica son aquellos 159 que utilizan una única clave para cifrar y descifrar un texto claro. Este tipo de 160 sistema conlleva una desventaja, que consiste en el conocimiento de las partes 161 (emisor y receptor) de la clave única que les permite intercambiar información 162 por un canal seguro. Como respuesta a ello, se hace necesario formalizar un procedimiento 163 que muestre a las partes autorizadas la información sobre la clave, sin que sea 164 develada a un tercero no autorizado. 165 166 \textbf{Criptografía Asimétrica:} también se conoce como Sistema de Cifrado 167 de Clave Pública\cite{STAL:03}. Usa dos claves diferentes, una de ellas es la 168 Clave Pública que puede ser enviada a cualquier persona y otra, que se 169 denomina Clave Privada que es secreta, y no debe ser revelada. A diferencia del 170 sistema de cifrado simétrico donde las partes deben concertar un procedimiento 171 para conocer la clave única, en este tipo de sistema el remitente usa la clave 172 pública del destinatario para cifrar el documento. Una vez que el documento o 173 mensaje ha sido cifrado, solamente con la clave privada del destinatario el 174 mensaje puede ser descifrado. 175 176 \subsection{Certificados electrónicos} 177 178 Un certificado electrónico es un documento de acreditación que permite a las partes 179 tener confianza en las transacciones que realicen en internet. Por tanto, 180 garantiza la identidad de su poseedor mediante un sistema de claves administrado 181 por una tercera parte de confianza. Para validar un certificado basta con conocer 182 la clave pública de la tercera parte conocida como la Autoridad de Certificación (AC). 183 Para cuidarnos de que piratas informáticos cambien su clave pública por la de la 184 autoridad de confianza, la AC debe crear un certificado con su propia información de 185 identidad y a la vez su clave pública y firmar el certificado, este certificado se le 186 conoce como certificado autofirmado. 187 Dado que los certificados son información pública y lo que se desea es que todos 188 tengan acceso a ellos, pueden hacerse copias del certificado de acuerdo sea necesario. 189 Los certificados electrónicos permiten varias cosas, entre ellas se pueden citar que los 190 usuarios pueden a~nadir firmas electrónicas a los formularios en línea; que los 191 destinatarios pueden comprobar la autenticidad del correo electrónico confidencial; 192 que los compradores pueden estar seguros de que un website es legítimo; y por último, 193 controla el acceso a bancos y comercios online, así como los intranets y extranets. 75 194 76 195 \subsection{Estándar X.509} 77 196 78 197 79 X.509 y X.500 fueron originalmente dise\~nados a mediados de los a\~nos 80, antes del enorme crecimiento de usuarios en Internet. Es por esto por lo que se dise\~naron para operar en un ambiente donde sólo los computadores se interconectaban intermitentemente entre ellos. En las versiones 1 y 2 de X.509 se utiliza una lista estandarizada denominada ``CRL'' (Certificate Revocation List) que contiene la información referente a clientes o certificados que han sido revocados. 80 81 La versión 3 introduce cambios significativos en el estándar. El cambio fundamental es el hacer el formato de los certificados y los CRLs extensible. Ahora los que implementen X.509 pueden definir el contenido de los certificados como crean conveniente. Además se han definido extensiones estándares para proveer una funcionalidad mejorada. 82 83 84 Con la utilización de la tecnología de certificados digitales se provee a los clientes (personas o programas) de un nivel más alto en los procesos de autenticación y autorización, ya que se le otorga al cliente algo que puede poseer, incluso incluir dentro de elemento físico, como una tarjeta inteligente. Los certificados en el formato X.509 v3 contienen datos del sujeto, como su nombre, dirección, correo electrónico, etc. (Ver Fig. \ref{fig:estandarx509}) 85 86 En la versión 3 de X.509, no hace falta aplicar restricciones sobre la estructura del certificado, gracias a la definición de las extensiones de certificados. Se permite que una organización pueda definir sus propias extensiones para contener información específica dentro de su entorno de operación. Este tipo de certificados es el que usa el protocolo de comercio electrónico SET (del inglés Secure Electronic Transaction, Transacción Electrónica Segura) \cite{IBM:98}. 198 X.509 y X.500 fueron originalmente dise\~nados a mediados de los a\~nos 80, antes 199 del enorme crecimiento de usuarios en Internet. Es por esto por lo que se 200 dise\~naron para operar en un ambiente donde sólo los computadores se interconectaban 201 intermitentemente entre ellos. En las versiones 1 y 2 de X.509 se utiliza una 202 lista estandarizada denominada lista de revocación de certificados (CRL por sus siglas en inglés) 203 que contiene la información referente a certificados que han sido revocados. 204 205 La versión 3 introduce cambios significativos en el estándar. El cambio fundamental 206 es el hacer el formato de los certificados y las CRL extensible. Ahora los que 207 implementen X.509 pueden definir el contenido de los certificados como crean 208 conveniente. Además se han definido extensiones estándares para proveer una 209 funcionalidad mejorada. 210 211 212 Con la utilización de la tecnología de certificados electrónicos se provee a los 213 clientes (personas o programas) de un nivel más alto en los procesos de 214 autenticación y autorización, ya que se le otorga al cliente algo que puede poseer, 215 incluso incluir dentro de elemento físico, como una tarjeta inteligente. 216 Los certificados en el formato X.509 v3 contienen datos del sujeto, 217 como su nombre, dirección, correo electrónico, etc. (Ver Fig. \ref{fig:estandarx509}) 218 219 En la versión 3 de X.509, no hace falta aplicar restricciones sobre la estructura 220 del certificado, gracias a la definición de las extensiones de certificados. 221 Se permite que una organización pueda definir sus propias extensiones para 222 contener información específica dentro de su entorno de operación. 223 %Este tipo de certificados es el que usa el protocolo de comercio electrónico 224 %SET (del inglés Secure Electronic Transaction, Transacción Electrónica Segura) \cite{IBM:98}. 87 225 88 226 \begin{figure}[htb] … … 94 232 95 233 96 Los certificados digitales tienen multitud de usos, entre los tipos de certificados más utilizados están: 234 %Los certificados electrónicos tienen multitud de usos, entre los tipos de certificados 235 %más utilizados están: 236 237 Entre los tipos de certificados más comunes están: 238 97 239 98 240 \begin{itemize} 99 \item \textbf{Certificado de Servidor SSL (del inglés Socket Secure Layer, Nivel de Conexión Segura):} Permite incorporar el protocolo SSL a un servidor web con el objetivo que toda la comunicación entre el cliente y el servidor permanezca segura, cifrando la información que envía cada parte. El certificado del servidor posibilita la autenticación fuerte, es decir, que el servidor puede exigir certificados personales de navegación a los usuarios para acceder a determinadas carpetas, lo que repercute en la seguridad y en la comodidad por la ausencia de cuentas y contrase\~nas para la identificación de los usuarios. 100 101 \item \textbf{Certificados personales (Correo y navegación):} Un certificado digital personal es la herramienta necesaria para navegar, comprar y enviar/recibir correo a través de Internet, de una manera segura. Con el uso de este certificado se puede firmar o cifrar los mensajes de correo para tener la seguridad que el receptor será el único lector de nuestro mensaje. Se puede aumentar la seguridad y confianza entre el cliente y el servidor web, al autenticarse también al usuario, esto también va a permitir a las empresas la posibilidad de personalizar los contenidos a un usuario concreto, con la certeza que otros usuarios no podrán ver dicho contenido, tales como información confidencial, ofertas especiales, entre otros. 102 103 \item \textbf{Certificado para firma de código:} El certificado para la firma de código permite a un administrador, desarrollador o empresa de software firmar su software y macros, y distribuirlo de una forma segura. Esta solución de Seguridad es el requisito mínimo que necesitan nuestros clientes o lista de correo, para confiar y tener la seguridad de que el fichero que reciben o se descargan, proviene exclusivamente de una empresa determinada. Con ello se evitan los problemas causados por la suplantación de personalidad y la distribución de objetos da\~ninos o perjudiciales bajo esta supuesta identidad. Cualquier modificación (por ejemplo: inclusión de un troyano o infección de un virus) sobre el software original lo invalidará, con lo que el usuario tendrá la confirmación para rechazarlo al comprobar que la firma electrónica no corresponde con la del software modificado. 241 \item \textbf{Certificado de Servidor de Conexión Segura (SSL por sus siglas en inglés):} 242 Permite incorporar el protocolo SSL a un servidor web con el objetivo que 243 toda la comunicación entre el cliente y el servidor permanezca segura, 244 cifrando la información que envía cada parte. El certificado del servidor posibilita 245 la autenticación fuerte, es decir, que el servidor puede exigir certificados 246 personales de navegación a los usuarios para acceder a determinadas carpetas, 247 lo que repercute en la seguridad y en la comodidad por la ausencia de cuentas 248 y contrase\~nas para la identificación de los usuarios. 249 250 \item \textbf{Certificados personales (Correo electrónico y navegación):} Un certificado electrónico 251 personal es la herramienta necesaria para navegar, comprar y enviar/recibir correo 252 a través de Internet, de una manera segura. Con el uso de este certificado se puede 253 firmar o cifrar los mensajes de correo para tener la seguridad que el receptor será 254 el único lector de nuestro mensaje. Se puede aumentar la seguridad y confianza entre el 255 cliente y el servidor web, al autenticarse también al usuario, esto también va a permitir 256 a las empresas la posibilidad de personalizar los contenidos a un usuario concreto, 257 con la certeza que otros usuarios no podrán ver dicho contenido, tales como información 258 confidencial, ofertas especiales, entre otros. 259 260 \item \textbf{Certificado para firma de código:} El certificado para la firma de 261 código permite a un administrador, desarrollador o empresa de software firmar su 262 software y macros, y distribuirlo de una forma segura. Esta solución de Seguridad es el 263 requisito mínimo que necesitan los clientes o lista de correo, para confiar y 264 tener la seguridad de que el fichero que reciben o se descargan, proviene exclusivamente 265 de una empresa determinada. Con ello se evitan los problemas causados por la 266 suplantación de personalidad y la distribución de objetos da\~ninos o perjudiciales 267 bajo esta supuesta identidad. Cualquier modificación (por ejemplo: inclusión de un 268 troyano o infección de un virus) sobre el software original lo invalidará, con lo que el 269 usuario tendrá la confirmación para rechazarlo al comprobar que la firma electrónica 270 no corresponde con la del software modificado. 104 271 \end{itemize} 272 273 105 274 \subsection{Lenguaje Unificado de Modelado} 106 275 107 UML ( del inglés Unified Modeling Language, Lenguaje de Modelado Unificado) es un lenguaje que permite diseñar sistemas a través de modelos, que se componen de un conjunto de símbolos y diagramas en donde se plasma las ideas de funcionalidad. El UML fue creado por Grady Booch, James Rumbaugh e Ivar Jacobson en el a~no 1997\cite{SCHM:03},\cite{BOOC:99} y \cite{MULL:97}. Cada diagrama tiene fines distintos dentro del proceso de desarrollo, su finalidad es presentar diversas perspectivas de un sistema. La clave está en organizar el proceso de dise~no de tal forma que los analistas, clientes, desarrolladores y otras personas involucradas en el desarrollo del modelo lo comprendan y convengan con él. Los diagramas que componen el lenguaje son: 276 %UML ( del inglés Unified Modeling Language, Lenguaje de Modelado Unificado) es un lenguaje 277 El Lenguaje de Modelado Unificado (UML por sus siglas en inglés) 278 permite diseñar sistemas a través de modelos, que se componen de un conjunto 279 de símbolos y diagramas en donde se plasma las ideas de funcionalidad. 280 El UML fue creado por Grady Booch, James Rumbaugh e Ivar Jacobson en el a~no 281 1997\cite{SCHM:03},\cite{BOOC:99} y \cite{MULL:97}. Cada diagrama tiene fines distintos 282 dentro del proceso de desarrollo, su finalidad es presentar diversas perspectivas 283 de un sistema. La clave está en organizar el proceso de dise~no de tal forma que los analistas, 284 clientes, desarrolladores y otras personas involucradas en el desarrollo del modelo 285 lo comprendan y convengan con él. Los diagramas que componen el lenguaje son: 108 286 109 287 \begin{itemize} … … 118 296 \end{itemize} 119 297 120 En este trabajo se utilizaron esencialmente los diagramas de clases, los diagramas de casos de uso y los diagramas de actividades, que se describen brevemente a continuación: 121 122 \textbf{Diagramas de clases:} son representaciones gráficas de las categorías en que pueden clasificarse los objetos del mundo real. En general, se hace una descripción de las categorías que se utilizan en la aplicación a desarrollar. Los clases se dise~nan en funcion de sus atributos y relaciones con otras clases. 123 124 \textbf{Diagramas de casos de uso:} son descripciones de las acciones que debe realizar el usuario en el sistema \cite{SCHM:03}. Por ejemplo: Usuario que tiene la necesidad de expedir un certificado digital a una AC de confianza. 125 126 127 \textbf{Diagramas de actividades:} muestran el flujo de actividades que ocurren dentro de un caso de uso o dentro de un comportamiento de un objeto\cite{SCHM:03}. Por ejemplo, las actividades que se realizan para expedir un certificado digital. 298 %En este trabajo se utilizaron esencialmente los diagramas de clases, los diagramas de 299 En este capítulo se utilizaron esencialmente los diagramas de clases, los diagramas de 300 casos de uso y los diagramas de actividades, que se describen brevemente a continuación: 301 302 \textbf{Diagramas de clases:} son representaciones gráficas de las categorías en que 303 pueden clasificarse los objetos del mundo real. En general, se hace una descripción 304 de las categorías que se utilizan en la aplicación a desarrollar. Los clases se 305 dise~nan en función de sus atributos y relaciones con otras clases. 306 307 \textbf{Diagramas de casos de uso:} son descripciones de las acciones que debe 308 realizar el usuario en el sistema \cite{SCHM:03}. Por ejemplo: Usuario que tiene la 309 necesidad de expedir un certificado electrónico a una AC de confianza. 310 311 312 \textbf{Diagramas de actividades:} muestran el flujo de actividades que ocurren 313 dentro de un caso de uso o dentro de un comportamiento de un objeto\cite{SCHM:03}. 314 Por ejemplo, las actividades que se realizan para expedir un certificado electrónico. 128 315 129 316 \subsection{Software Libre} 130 317 131 \label{sec:softlibre}El software libre \cite{FSF:07} es un asunto de libertad, no de precio. Para que un programa, aplicación o conjunto concreto se considere ``software libre'' debe cumplir con las siguientes libertades: 1) Libertad de ejecutar el programa en cualquier sitio, cualquier propósito, por siempre; 2) Libertad de estudiarlo y adaptarlo a nuestras necesidades; 3) Libertad de redistribuirlo a cualquiera, logrando ayudar a un amigo o vecino; y por último 4)la Libertad de mejorar el programa y publicar las mejoras. 132 133 Las libertades antes expuestas, proveen muchos beneficios a los usuarios finales. En particular, en el área de seguridad informática. Se pueden nombrar entre los beneficios más importantes: la no dependencia de un único fabricante, y la posibilidad de realizar auditorías y pruebas exhaustivas por parte de terceros, que pueden ser personas, empresas o instituciones diferentes responsables del proyecto de software. Los procesos de adaptación, mantenimiento, integración y auditorías son más transparentes y colaborativos. 318 \label{sec:softlibre}El software libre \cite{FSF:07} es un asunto de libertad, 319 no de precio. Para que un programa, aplicación o conjunto concreto se 320 considere ``software libre'' debe cumplir con las siguientes libertades: 321 1) Libertad de ejecutar el programa en cualquier sitio, cualquier propósito, 322 por siempre; 2) Libertad de estudiarlo y adaptarlo a nuestras necesidades; 323 3) Libertad de redistribuirlo a cualquiera, logrando ayudar a un amigo o vecino; 324 y por último 4)la Libertad de mejorar el programa y publicar las mejoras. 325 326 Las libertades antes expuestas, proveen muchos beneficios a los usuarios finales. 327 En particular, en el área de seguridad informática. Se pueden nombrar entre los 328 beneficios más importantes: la no dependencia de un único fabricante, y la posibilidad 329 de realizar auditorías y pruebas exhaustivas por parte de terceros, que pueden 330 ser personas, empresas o instituciones diferentes responsables del proyecto 331 de software. Los procesos de adaptación, mantenimiento, integración y auditorías 332 son más transparentes y colaborativos. 134 333 135 334 136 335 \section{Infraestructura de Clave Pública} 137 336 138 Uno de los problemas del despliegue de la tecnologías basada en certificados y firmas digitales, es contar con un elemento que proporcione una relación fuerte de confianza entre dos o más sujetos que desean realizar una operación o transacción utilizando como medio Internet. Es por ello, que se recurre a establecer un tercero de confianza, que se define, como un actor encargado de brindar confianza basada en la disponibilidad de una infraestructura robusta que incluya el uso tecnologías basadas en algoritmos criptográficos estandarizados, y la aplicación estricta de políticas para los procesos de registro, publicación, firma, renovación y revocación de certificados. 139 El tercero de confianza se denomina Infraestructura de Clave Pública (ICP)\cite{NASH:02}, y consiste en la combinación de hardware y software, políticas y procedimientos que permiten asegurar la identidad de los participantes en un intercambio de datos usando criptografía pública. Una ICP debe proporcionar los tres conceptos de seguridad mencionados anteriormente. 337 Uno de los problemas del despliegue de la tecnologías basada en certificados y 338 firmas electrónicas, es contar con un elemento que proporcione una relación 339 fuerte de confianza entre dos o más sujetos que desean realizar una operación o 340 transacción utilizando como medio Internet. Es por ello, que se recurre a 341 establecer un tercero de confianza, que se define, como un actor encargado de 342 brindar confianza basada en la disponibilidad de una infraestructura robusta que 343 incluya el uso tecnologías basadas en algoritmos criptográficos estandarizados, 344 y la aplicación estricta de políticas para los procesos de registro, publicación, 345 firma, renovación y revocación de certificados. 346 El tercero de confianza se denomina Infraestructura de Clave Pública (ICP)\cite{NASH:02}, 347 y consiste en la combinación de hardware y software, políticas y procedimientos 348 que permiten asegurar la identidad de los participantes en un intercambio de datos 349 usando criptografía pública. Una ICP debe proporcionar los tres conceptos de 350 seguridad mencionados anteriormente. 140 351 141 352 \subsection{Componentes de la Infraestructura de Claves Pública (ICP)} 142 Los componentes habituales que conforman la infraestructura son los siguientes (Ver Fig. \ref{fig:arquitecturapsc}): 353 Los componentes habituales que conforman la infraestructura son los siguientes 354 (Ver Fig. \ref{fig:arquitecturapsc}): 143 355 \begin{itemize} 144 \item Autoridad de Registro (AR): es el nodo o conjunto de nodos responsables del registro y la autenticación inicial de los usuarios a quiénes se les expide un certificado, después de aprobada una solicitud de registro. 145 \item Autoridad de Certificación (AC): es el nodo central de la infraestructura, se encarga de los procedimientos de firma, renovación y revocación de certificados digitales. El procedimiento de firma de certificados utiliza la clave privada de la AC. 146 \item Interfaz con los clientes (PUB): es el nodo que brinda toda la información a las entidades finales (usuarios) sobre el estado de su certificado, además de ofrecer una información general al público en general sobre los aspectos y servicios relevantes de la ICP. 356 \item Autoridad de Registro (AR): es el nodo o conjunto de nodos responsables 357 del registro y la autenticación inicial de los usuarios a quiénes 358 se les expide un certificado, después de aprobada una solicitud de registro. 359 \item Autoridad de Certificación (AC): es el nodo central de la infraestructura, 360 se encarga de los procedimientos de firma, renovación y revocación de 361 certificados digitales. El procedimiento de firma de certificados utiliza 362 la clave privada de la AC. 363 \item Interfaz con los clientes (PUB): es el nodo que brinda toda la información 364 a las entidades finales (usuarios) sobre el estado de su certificado, además de 365 ofrecer una información general al público en general sobre los aspectos y servicios 366 relevantes de la ICP. 147 367 \end{itemize} 148 368 149 369 150 Los nodos de una ICP pueden ordenarse según diversos modelos. El más utilizado es el modelo jerárquico, que presenta una raíz y nodos hijos que distribuyen los certificados a los clientes o entidades finales (Ver Fig. \ref{fig:jerarquia}). Se muestra un ejemplo de modelo de jerarquía de una ICP de cuatro niveles, que se encuentra en el tercer nivel del modelo, que certifica a los usuarios. 370 Los nodos de una ICP pueden ordenarse según diversos modelos. El más utilizado es 371 el modelo jerárquico, que presenta una raíz y nodos hijos que distribuyen los 372 certificados a los clientes o entidades finales (Ver Fig. \ref{fig:jerarquia}). 373 Se muestra un ejemplo de modelo de jerarquía de una ICP de cuatro niveles, 374 que se encuentra en el tercer nivel del modelo, que certifica a los usuarios. 151 375 152 376 \begin{figure}[htb] … … 157 381 \end{figure} 158 382 159 Este modelo de establecimiento de relaciones de confianza, es necesaria entre múltiples autoridades de certificación para garantizar que los usuarios (entidades finales) no tengan que depender y confiar en una sola AC, algo que haría imposible el manejo de estabilidad, administración y protección. El objetivo es que las entidades finales que utilizan identidades creadas por una AC puedan confiar en ellas, aunque dichas partes tenga una autoridad expedidora diferente. 383 Este modelo de establecimiento de relaciones de confianza, es necesaria entre 384 múltiples autoridades de certificación para garantizar que los usuarios 385 (entidades finales) no tengan que depender y confiar en una sola AC, algo que haría 386 imposible el manejo de estabilidad, administración y protección. El objetivo 387 es que las entidades finales que utilizan identidades creadas por una AC puedan 388 confiar en ellas, aunque dichas partes tenga una autoridad expedidora diferente. 160 389 161 390 … … 163 392 \section{Desarrollo de la aplicación} 164 393 165 En los párrafos siguientes se discute los aspectos, procesos y técnicas principales, que se siguen a lo largo del desarrollo de la aplicación (software) de gestión del componente Autoridad Certificadora Raíz. 394 En los párrafos siguientes se discuten los aspectos, procesos y técnicas 395 principales, que se siguen a lo largo del desarrollo de la aplicación (software) 396 de gestión del componente Autoridad Certificadora Raíz. 166 397 167 398 … … 169 400 170 401 171 Uno de los objetivos de esta etapa es determinar el rol del componente AC Raíz en la ICP, con la finalidad de obtener los requisitos, procesos y funciones que deben ser implementados por el software. Este rol tiene que ver con la definición de la AC Raíz como elemento central y de máximo resguardo de la infraestructura, ya que este nodo inicial o ``Raíz'' contiene la clave privada que valida todos los certificados de los otros nodos de la jerarquía. 172 173 Se considera como punto importante en esta etapa, distinguir las diferencias entre una AC Raíz y una AC de un Proveedor de Servicios de Certificación (PSC). La diferencia principal entre estos dos tipos de AC, es la cantidad de certificados que deben gestionar (firmar, renovar, revocar, etc) , en un determinado periodo cada uno de ellos. Esto es, una AC Raíz solo gestiona un número mínimo de certificados, los cuáles sirven para dar inicio a la jerarquía (certificados otorgados a los PSC), por el contrario, una AC de un PSC debe gestionar un número mucho mayor de certificados, ya que la función de este nodo es entregar certificados periódicamente a usuarios, también llamados entidades finales. 174 175 La diferencia de escala de los dos tipos de AC conlleva a que la AC Raíz tenga características particulares, que tienen que ver los niveles y elementos de seguridad tanto físicos como lógicos que deben considerarse en la gestión del componente. Por ejemplo, la desconexión de red del equipo donde se ejecuta la aplicación de gestión hace que la recepción y entrega de certificados se realice a través de unidades de memoria externas y portátiles, debidamente validadas, con las cuáles el software debe mantener una comunicación segura. 176 177 La conexión de la aplicación con hardware especializado, como el almacenador y generador de claves públicas/privadas (Hardware Security Module: HSM) o las tarjetas inteligentes, es un factor que debe considerarse en el momento de enumerar las funciones iniciales del software de gestión. 178 179 La selección del sistema operativo Linux\cite{SARW:03} para desplegar la aplicación, ya que cumple con los principios del software libre, y cuenta con gran número de herramientas en el área de programación \cite{KURT:01}, es un requisito no funcional que se establece en esta etapa. 180 181 Considerando los aspectos nombrados anteriormente, en este punto se elabora una lista inicial de requisitos, con la cual debe cumplir la aplicación. Como técnicas utilizadas en ésta etapa están la realización de entrevistas a clientes, a posibles administradores y operadores; la elaboración de tablas comparativas entre diferentes aplicaciones que existen en las bibliotecas o portales de software libre, con la finalidad de evaluar las herramientas a utilizar en la elaboración de la aplicación. 402 Uno de los objetivos de esta etapa es determinar el rol del componente AC Raíz 403 en la ICP, con la finalidad de obtener los requisitos, procesos y funciones que 404 deben ser implementados por el software. Este rol tiene que ver con la definición 405 de la AC Raíz como elemento central y de máximo resguardo de la infraestructura, 406 ya que este nodo inicial o ``Raíz'' contiene la clave privada que valida todos los 407 certificados de los otros nodos de la jerarquía. 408 409 Se considera como punto importante en esta etapa, distinguir las diferencias entre 410 una AC Raíz y una AC de un Proveedor de Servicios de Certificación (PSC). La diferencia 411 principal entre estos dos tipos de AC, es la cantidad de certificados que deben gestionar 412 (firmar, renovar, revocar, etc) , en un determinado periodo cada uno de ellos. Esto es, una 413 AC Raíz solo gestiona un número mínimo de certificados, los cuáles sirven para dar inicio a 414 la jerarquía (certificados otorgados a los PSC), por el contrario, una AC de un PSC debe 415 gestionar un número mucho mayor de certificados, ya que la función de este nodo es 416 entregar certificados periódicamente a usuarios, también llamados entidades finales. 417 418 La diferencia de escala de los dos tipos de AC conlleva a que la AC Raíz tenga 419 características particulares, que tienen que ver los niveles y elementos de seguridad 420 tanto físicos como lógicos que deben considerarse en la gestión del componente. 421 Por ejemplo, la desconexión de red del equipo donde se ejecuta la aplicación de 422 gestión hace que la recepción y entrega de certificados se realice a través de 423 unidades de memoria externas y portátiles, debidamente validadas, con las cuáles 424 el software debe mantener una comunicación segura. 425 426 427 La conexión de la aplicación con hardware especializado, como el Módulo de Seguridad en Hardware 428 (HSM por sus siglas en inglés) que permite generar y almacenar claves o las tarjetas inteligentes, 429 es un factor que debe considerarse en el momento de enumerar las funciones iniciales del software de gestión. 430 431 La selección del sistema operativo Linux\cite{SARW:03} para desplegar la aplicación, 432 ya que cumple con los principios del software libre, y cuenta con gran número de 433 herramientas en el área de programación \cite{KURT:01}, es un requisito no funcional 434 que se establece en esta etapa. 435 436 Considerando los aspectos nombrados anteriormente, en este punto se elabora una lista 437 inicial de requisitos, con la cual debe cumplir la aplicación. Como técnicas utilizadas 438 en ésta etapa están la realización de entrevistas a clientes, a posibles administradores 439 y operadores; la elaboración de tablas comparativas entre diferentes aplicaciones que 440 existen en las bibliotecas o portales de software libre, con la finalidad de evaluar las 441 herramientas a utilizar en la elaboración de la aplicación. 182 442 183 443 184 444 \subsection{Dise\~no} 185 445 186 La etapa de dise\~no consiste en elaborar diagramas formales que permitan en la etapa de implementación representar requisitos y procesos de la gestión del componente AC Raíz en un lenguaje de programación. Para el dise\~no de requisitos se utilizan los diagramas de casos de uso del lenguaje UML, que muestran una primera aproximación las operaciones que se deben realizar en relación con las entradas dadas por los usuarios. Los actores (usuarios) del caso de uso principal que se muestra en la Fig. \ref{fig:casodeusoprincipal} son: el Administrador del componente AC, el Administrador del Componente AR, el Administrador del componente PUB, y el actor PSC, quiénes son los que interactúan con la aplicación. 446 La etapa de dise\~no consiste en elaborar diagramas formales que permitan en la etapa 447 de implementación representar requisitos y procesos de la gestión del componente AC Raíz 448 en un lenguaje de programación. Para el dise\~no de requisitos se utilizan los diagramas 449 de casos de uso del lenguaje UML, que muestran una primera aproximación las operaciones 450 que se deben realizar en relación con las entradas dadas por los usuarios. Los actores 451 (usuarios) del caso de uso principal que se muestra en la Fig. \ref{fig:casodeusoprincipal} 452 son: el Administrador del componente AC, el Administrador del Componente AR, el Administrador 453 del componente PUB, y el actor PSC, quiénes son los que interactúan con la aplicación. 187 454 188 455 \begin{figure}[htb] … … 193 460 \end{figure} 194 461 195 Para el resto de la especificación de requisitos se elaboran casos de uso que modelan las funcionalidades con que debe contar la aplicación. Para cada actor, se especifican el correspondiente diagrama de caso de uso. En la Fig. \ref{fig:casodeusoac} se muestra el caso de uso para el actor del componente AC. Las acciones que realiza este actor son emisión, renovación y revocación de certificados, que conlleva procesos de firma con la clave privada, modificación de los periodos de vigencia del certificado y elaboración de listas de certificados revocados respectivamente para casa caso de uso. 462 Para el resto de la especificación de requisitos se elaboran casos de uso que modelan 463 las funcionalidades con que debe contar la aplicación. Para cada actor, se especifican 464 el correspondiente diagrama de caso de uso. En la Fig. \ref{fig:casodeusoac} se 465 muestra el caso de uso para el actor del componente AC. Las acciones que realiza 466 este actor son emisión, renovación y revocación de certificados, que conlleva procesos 467 de firma con la clave privada, modificación de los periodos de vigencia del certificado 468 y elaboración de listas de certificados revocados respectivamente para casa caso de uso. 196 469 197 470 \begin{figure}[htb] … … 203 476 204 477 205 También en esta etapa se construye el modelo de datos de la aplicación. La Fig. \ref{fig:diagramadeclases} muestra de forma parcial, ya que no se incluyen los atributos, el diagrama de clases que explica el modelo de datos. Se consideran como objetos persistentes del sistema a elementos como usuarios, clientes, certificados, autoridades o proveedores de certificación, solicitudes de autoridad de certificación, solicitudes de entidad finales, y sus respectivas relaciones. 478 También en esta etapa se construye el modelo de datos de la aplicación. 479 La Fig. \ref{fig:diagramadeclases} muestra de forma parcial, ya que no se incluyen 480 los atributos, el diagrama de clases que explica el modelo de datos. Se consideran 481 como objetos persistentes del sistema a elementos como usuarios, clientes, 482 certificados, autoridades o proveedores de certificación, solicitudes de autoridad de 483 certificación, solicitudes de entidad finales, y sus respectivas relaciones. 206 484 207 485 \begin{figure}[htb] … … 213 491 214 492 215 Para modelar la secuencia de acciones que se realizan para cada caso de uso se utilizan los diagramas de actividades. La Fig. \ref{fig:diagramaactividades} muestra el diagrama de actividades general para el caso de uso ``Emisión de certificados''' del actor Administrador del componente AC. Para este conjunto de actividades participan cuatro (4) actores: Administrador del PSC, quién entrega los recaudos necesarios para que se le firme su solicitud, el Administrador de la AR, quién es el encargado de chequear los recaudos entregados por el PSC, el Administrador de la AC Raíz y el Administrador PUB, este último encargado de de publicar en los diferentes repositorios los certificados (claves públicas) para que sean visibles por el mayor número de usuarios interesados. 493 Para modelar la secuencia de acciones que se realizan para cada caso de uso se 494 utilizan los diagramas de actividades. La Fig. \ref{fig:diagramaactividades} 495 muestra el diagrama de actividades general para el caso de uso ``Emisión de 496 certificados''' del actor Administrador del componente AC. Para este conjunto de 497 actividades participan cuatro (4) actores: Administrador del PSC, quién entrega los 498 recaudos necesarios para que se le firme su solicitud, el Administrador de la AR, 499 quién es el encargado de chequear los recaudos entregados por el PSC, el Administrador 500 de la AC Raíz y el Administrador PUB, este último encargado de de publicar en los 501 diferentes repositorios los certificados (claves públicas) para que sean visibles por 502 el mayor número de usuarios interesados. 216 503 217 504 … … 227 514 228 515 229 En esta etapa se utiliza como insumo los diagramas de casos de uso, diagrama de clases y actividades, generados en la etapa de dise~no. Se traduce el diagrama de clases al que se hace referencia en la Fig. \ref{fig:diagramaactividades} en un modelo de datos relacional, y se genera un script SQL que genera el mapa de tablas relacional, donde las tablas representan relaciones tales como usuarios, clientes, certificados, y las demás entidades que conforman el modelo de datos. 230 231 Se utilizan y validan los diagramas de casos de uso mediante la elaboración de interfaces gráficas de usuarios y funcionalidades de interacción con el usuario. Los diagramas de actividades ayudan en el planteamiento de algoritmos que proveen funcionalidades o características con las cuáles debe contar la aplicación y que deben estar en coordinación con los respuestas y valores esperados. 232 233 234 Haciendo uso de las ventajas que trae el uso de software libre (Sección \ref{sec:softlibre}), se implementa la aplicación utilizando la mayor cantidad de líneas de códigos disponibles en los repositorios y proyectos de la comunidad, de tal manera que satisfagan los requisitos y funcionalidades planteadas en la etapa de dise~no. En este sentido, se utiliza el código fuente del proyecto XCA \cite{XCA:03}, desarrollado por Christian Hohnst\"{a}dt, que tiene como objetivo proveer una aplicación escrita en el lenguaje de programación C++\cite{STRO:02} y la biblioteca Trolltech Qt\cite{BLAN:06}, que cumpla con el estándar X.509. La aplicación satisface los requisitos básicos para la gestión del componente de gestión de AC Raíz, esto es, los diagramas UML de la etapa de dise~no calzan con un gran conjunto de requisitos satisfechos en el proyecto XCA, esto ocurre debido a que este trabajo comparte objetivos con dicho proyecto; por ejemplo, para el caso de uso de la Fig. \ref{fig:casodeusoac}, 235 donde el actor debe ejecutar tres acciones: emitir, renovar y revocar certificados, la aplicación XCA incorpora estas tres actividades, pero se hace necesario adaptar la interfaz de usuario y agregar características en función de los requisitos capturados. 236 237 Es importante recalcar, que XCA no sastiface todos los requisitos documentados en la etapa de dise~no. En respuesta a este hecho, se realiza un proceso de completación de funcionalidades. En este sentido, se incorporan características a la aplicación acorde con la especificaciones de dise~no, entre las cuáles se enumeran: 516 En esta etapa se utiliza como insumo los diagramas de casos de uso, diagrama 517 de clases y actividades, generados en la etapa de dise~no. Se traduce el 518 diagrama de clases al que se hace referencia en la Fig. \ref{fig:diagramaactividades} 519 en un modelo de datos relacional, y se genera un script SQL que genera el mapa de 520 tablas relacional, donde las tablas representan relaciones tales como usuarios, 521 clientes, certificados, y las demás entidades que conforman el modelo de datos. 522 523 Se utilizan y validan los diagramas de casos de uso mediante la elaboración de 524 interfaces gráficas de usuarios y funcionalidades de interacción con el usuario. 525 Los diagramas de actividades ayudan en el planteamiento de algoritmos que proveen 526 funcionalidades o características con las cuáles debe contar la aplicación y 527 que deben estar en coordinación con los respuestas y valores esperados. 528 529 530 Haciendo uso de las ventajas que trae el uso de software libre (Sección \ref{sec:softlibre}), 531 se implementa la aplicación utilizando la mayor cantidad de líneas de códigos 532 disponibles en los repositorios y proyectos de la comunidad, de tal manera que 533 satisfagan los requisitos y funcionalidades planteadas en la etapa de dise~no. 534 En este sentido, se utiliza el código fuente del proyecto XCA \cite{XCA:03}, 535 desarrollado por Christian Hohnst\"{a}dt, que tiene como objetivo proveer una 536 aplicación escrita en el lenguaje de programación C++\cite{STRO:02} y la 537 biblioteca Trolltech Qt\cite{BLAN:06}, que cumpla con el estándar X.509. La aplicación 538 satisface los requisitos básicos para la gestión del componente de gestión de AC Raíz, 539 esto es, los diagramas UML de la etapa de dise~no calzan con un gran conjunto de requisitos 540 satisfechos en el proyecto XCA, esto ocurre debido a que este trabajo comparte 541 objetivos con dicho proyecto; por ejemplo, para el caso de uso de la Fig. \ref{fig:casodeusoac}, 542 donde el actor debe ejecutar tres acciones: emitir, renovar y revocar certificados, 543 la aplicación XCA incorpora estas tres actividades, pero se hace necesario adaptar 544 la interfaz de usuario y agregar características en función de los requisitos capturados. 545 546 Es importante recalcar, que XCA no sastiface todos los requisitos documentados en la 547 etapa de dise~no. En respuesta a este hecho, se realiza un proceso de completación de 548 funcionalidades. En este sentido, se incorporan características a la aplicación acorde 549 con la especificaciones de dise~no, entre las cuáles se enumeran: 238 550 \begin{itemize} 239 \item La incorporación de un sub-sistema de seguridad para acceso a los activos de información que gestiona la aplicación, que incluya aspectos de autenticación y autorización de usuarios, como lo es la validación de credenciales a través del uso de tarjetas inteligentes, el registro y firma digital de las acciones realizadas por los usuarios dentro de la aplicación. 240 En La fig \ref{fig:registro} se muestra la característica de registro de acciones. La ventana a la derecha muestra los detalles de la acción seleccionada en la lista, se incluyen datos importantes como nombre de la cuenta de usuario, fecha, hora, y otros datos particulares relacionadas con la acción realizada por el correspondiente usuario. 551 \item La incorporación de un sub-sistema de seguridad para acceso a los activos de 552 información que gestiona la aplicación, que incluya aspectos de autenticación y 553 autorización de usuarios, como lo es la validación de credenciales a través del 554 uso de tarjetas inteligentes, el registro y firma digital de las acciones realizadas 555 por los usuarios dentro de la aplicación. 556 En La fig \ref{fig:registro} se muestra la característica de registro de acciones. 557 La ventana a la derecha muestra los detalles de la acción seleccionada en la lista, 558 se incluyen datos importantes como nombre de la cuenta de usuario, fecha, hora, y 559 otros datos particulares relacionadas con la acción realizada por el correspondiente 560 usuario. 241 561 242 562 \begin{figure}[htb] … … 247 567 \end{figure} 248 568 249 \item Estandarización del sistema de gestión de documentos como solicitudes, plantillas de certificados y certificados. 250 251 \item Conexión a través de una interfaz propia con el hardware donde se resguardan las claves privadas (HSM). 569 \item Estandarización del sistema de gestión de documentos como solicitudes, 570 plantillas de certificados y certificados. 571 572 \item Conexión a través de una interfaz propia con el hardware donde se resguardan 573 las claves privadas (HSM). 252 574 253 575 \end{itemize} 254 576 255 También en esta etapa se seleccionan e integran las tecnologías a utilizar para la codificación y creación de la aplicación de gestión del componente AC Raíz. Los tipos de tecnologías que deben seleccionarse son: bibliotecas para construir la interfaz hombre-máquina (HMI), motor criptográfico, conexiones con hardware, interfaces con repositorio de datos y algoritmos de cálculo criptográfico más utilizados. 256 257 258 Como criptosistema se utiliza OpenSSL version 0.9.8 \cite{VIEG:2002}, que provee de un conjunto de funciones criptográficas apegadas al estándar X.509. . Para la construcción de interfaces hombre-máquina y uso de algoritmos generales se selecciona la biblioteca Trolltech Qt. Como interfaz para el uso de tarjetas inteligentes se utilizo el estándar PKCS11, también conocido como Cryptoki, que especifica una forma para interactuar con este hardware criptográfico\cite{NIC:03}. 577 También en esta etapa se seleccionan e integran las tecnologías a utilizar para 578 la codificación y creación de la aplicación de gestión del componente AC Raíz. 579 Los tipos de tecnologías que deben seleccionarse son: bibliotecas para construir 580 la interfaz hombre-máquina (HMI), motor criptográfico, conexiones con hardware, 581 interfaces con repositorio de datos y algoritmos de cálculo criptográfico más utilizados. 582 583 584 Como criptosistema se utiliza OpenSSL version 0.9.8 \cite{VIEG:2002}, que provee 585 de un conjunto de funciones criptográficas apegadas al estándar X.509. . Para la 586 construcción de interfaces hombre-máquina y uso de algoritmos generales se 587 selecciona la biblioteca Trolltech Qt. Como interfaz para el uso de tarjetas 588 inteligentes se utilizo el estándar PKCS11, también conocido como Cryptoki, que 589 especifica una forma para interactuar con este hardware criptográfico\cite{NIC:03}. 259 590 260 591 … … 262 593 \subsection{Pruebas} 263 594 264 Esta etapa tiene dos objetivos. El primero de consiste en asegurar que la aplicación funcione correctamente, es decir, que se generen la menor cantidad de salidas inesperadas o fallas a entradas dadas. En relación al logro de este objetivo se utilizan un conjunto de técnicas aplicadas a lo largo del proceso de desarrollo, entre las cuáles se pueden citar la revisión en parejas\cite{PRESS:05}, que consiste que la programación se realice en equipo de dos programadores por computador, uno de ellos se encarga de escribir los algoritmos en un lenguaje de programación, y el segundo de ellos de revisarlo inmediatamente, después de periodo de unas horas, que debe ser definido con anticipación, se intercambian los roles. Otra de las técnicas utilizadas que es importante nombrar son las pruebas unitarias\cite{PRESS:05}, las cuáles consisten en aplicar un número casos de pruebas a métodos o módulos peque~nos de la aplicación (unidades), de tal manera que se asegura que funcionan correctamente de 265 forma independiente. Seguidamente, se realizan pruebas de integración, que consisten en probar módulos más complejos formados por las unidades revisadas en las pruebas unitarias. Las pruebas unitarias y de integración presentan la ventajas que son automatizables, y por lo tanto, se cuenta como herramientas de software para llevarlas a cabo. 266 267 268 El segundo objetivo, es que se satisfagan los requisitos plasmados en la etapa de dise~no, y que se extraen de los diagramas UML , es decir, la aplicación debe cumplir con las características necesarias para resolver el problema de gestión de una AC Raíz. En este sentido, se toma una estrategia basada en prototipos con liberaciones periódicas, que permite a los usuarios y desarrolladores de la comunidad chequear el progreso en el proyecto. Los prototipos son chequeados por los usuarios y la modificación de requisitos y notificación de errores son notificados en un sistema web de chequeo y seguimiento \cite{TRAC:07}. 269 270 También se habilita un sistema de control de versiones de licencia libre llamado subversion \cite{PILA:04}, que permite a los programadores involucrados en el proyecto obtener en todo momento y de forma local o remota la última versión de los programas fuentes. 271 272 Debido a que la aplicación de gestión de AC Raiz debe ser parte de una infraestructura, es necesario realizar pruebas en condiciones similares a la configuración final de ésta; por ello se simula la configuración de producción que conlleva pruebas con el sistema operativo y el donde se instala la aplicación, conexión con tarjetas inteligentes y el módulo de seguridad en hardware, controles de acceso físico y lógico, y desconexión de red, ya que la autoridad debe operar fuera de línea. 595 Esta etapa tiene dos objetivos. El primero de consiste en asegurar que la 596 aplicación funcione correctamente, es decir, que se generen la menor cantidad 597 de salidas inesperadas o fallas a entradas dadas. En relación al logro de este 598 objetivo se utilizan un conjunto de técnicas aplicadas a lo largo del proceso 599 de desarrollo, entre las cuáles se pueden citar la revisión en parejas\cite{PRESS:05}, 600 que consiste que la programación se realice en equipo de dos programadores por 601 computador, uno de ellos se encarga de escribir los algoritmos en un lenguaje 602 de programación, y el segundo de ellos de revisarlo inmediatamente, después de 603 periodo de unas horas, que debe ser definido con anticipación, se intercambian 604 los roles. Otra de las técnicas utilizadas que es importante nombrar son las 605 pruebas unitarias\cite{PRESS:05}, las cuáles consisten en aplicar un número 606 casos de pruebas a métodos o módulos peque~nos de la aplicación (unidades), 607 de tal manera que se asegura que funcionan correctamente de forma independiente. 608 Seguidamente, se realizan pruebas de integración, que consisten en probar módulos 609 más complejos formados por las unidades revisadas en las pruebas unitarias. 610 Las pruebas unitarias y de integración presentan la ventajas que son automatizables, 611 y por lo tanto, se cuenta como herramientas de software para llevarlas a cabo. 612 613 614 El segundo objetivo, es que se satisfagan los requisitos plasmados en la etapa 615 de dise~no, y que se extraen de los diagramas UML , es decir, la aplicación 616 debe cumplir con las características necesarias para resolver el problema de 617 gestión de una AC Raíz. En este sentido, se toma una estrategia basada en 618 prototipos con liberaciones periódicas, que permite a los usuarios y desarrolladores 619 de la comunidad chequear el progreso en el proyecto. Los prototipos son 620 chequeados por los usuarios y la modificación de requisitos y notificación de 621 errores son notificados en un sistema web de chequeo y seguimiento \cite{TRAC:07}. 622 623 También se habilita un sistema de control de versiones de licencia libre 624 llamado subversion \cite{PILA:04}, que permite a los programadores involucrados 625 en el proyecto obtener en todo momento y de forma local o remota la última 626 versión de los programas fuentes. 627 628 Debido a que la aplicación de gestión de AC Raiz debe ser parte de una 629 infraestructura, es necesario realizar pruebas en condiciones similares a la 630 configuración final de ésta; por ello se simula la configuración de producción que 631 conlleva pruebas con el sistema operativo y el donde se instala la aplicación, 632 conexión con tarjetas inteligentes y el módulo de seguridad en hardware, 633 controles de acceso físico y lógico, y desconexión de red, ya que la autoridad 634 debe operar fuera de línea. 273 635 274 636 275 637 \subsection{Despliegue y configuración} 276 El despliegue consiste en la instalación en condiciones reales de la aplicación de gestión de AC Raíz dentro de la infraestructura. La figura \ref{fig:arquitecturapsc} muestra una propuesta para el despliegue de la infraestructura. La aplicación se instala en un computador desconectado de red que debe estar ubicado dentro de un lugar físico seguro, lo que significa que el acceso a personas deber estar restringuido por llaves y controles biométricos, y el flujo de información digital hacia adentro y afuera de la bóveda debe ser realizado a través de dispositivos de memoria secundaria con seguridad incorporada, tal como un lapiz usb (pendrive) con bloqueo por contrase~na, como se muestra en la figura. También es necesario la habilitación de servidores para la validación de los periodos de vigencia de los certificados (OSCP), y para la generación de solicitudes de firma de certificados, donde las entidades finales o usuarios consignan los recaudos. 638 El despliegue consiste en la instalación en condiciones reales de la 639 aplicación de gestión de AC Raíz dentro de la infraestructura. La figura \ref{fig:arquitecturapsc} 640 muestra una propuesta para el despliegue de la infraestructura. La aplicación se 641 instala en un computador desconectado de red que debe estar ubicado dentro de un 642 lugar físico seguro, lo que significa que el acceso a personas deber estar 643 restringido por llaves y controles biométricos, y el flujo de información digital 644 hacia adentro y afuera de la bóveda debe ser realizado a través de dispositivos 645 de memoria secundaria con seguridad incorporada, tal como un lapiz usb (pendrive) 646 con bloqueo por contrase~na, como se muestra en la figura. También es necesario 647 la habilitación de servidores para la validación de los periodos de vigencia de 648 los certificados (OSCP), y para la generación de solicitudes de firma de certificados, 649 donde las entidades finales o usuarios consignan los recaudos. 277 650 278 651 \begin{figure}[htb] … … 283 656 \end{figure} 284 657 285 Por otro lado, la configuración conlleva el establecimiento de parámetros para el funcionamiento la aplicación, tales como métodos de control y restricción de acceso, ubicación de archivos y directorios, rutas para importación e exportación de datos, perfiles de usuario, generación y nombres de claves, inicialización de tarjetas inteligentes, inicialización de HSM, y copias de seguridad. 286 287 \section{Conclusiones} 288 289 La puesta en marcha de una AC Raíz supone obligatoriamente contar con una aplicación que gestione este componente de la infraestructura. En este sentido, éste trabajo mostró el proceso de desarrollo de una aplicación que respondiera a los requisitos particulares de gestión, determinados por el rol de confianza raíz y última que debe representar la Autoridad. En función de ello, la aplicación tiene un alto grado de especialización, ya que cuenta con un mercado relativo de pocos usuarios, si se compara con el mercado de los sistemas de información o aplicaciones de ofimática, y su operación se realiza en condiciones estandándares y específicas. A pesar de este hecho, para la construcción de la aplicación se integraron varios proyectos disponibles en los repositorios de software libre, que permitió disponer de un criptosistema estándar y suficientemente completo para cumplir con los requisitos descritos en la etapa de dise~no. La criptografía se utiliza como herramienta para 290 otorgar las tres propiedades (Confidencialidad, Integridad y Disponibilidad) de la seguridad informática a los datos que gestiona la aplicación, y en virtud de ello el hardware criptográfico utilizado como las tarjetas inteligentes y el módulo de seguridad en hardware configuran un ``mundo seguro'' que cumple con los estándares aceptados a nivel mundial. 291 292 En la etapa de dise~no, los diagramas de casos de uso y actividades sirvieron para obtener una visión formal de los requisitos y de los procesos con los que cumplir la aplicación. Estos documentos de dise~no en el lenguaje UML, permitieron alcanzar de manera más rápida y certera los objetivos que son coincidentes con la gestión real de una AC Raíz. 293 294 Al seguir el estándar X.509 se asegura que los certificados, solicitudes y claves gestionados por la aplicación sean compatibles con el esquema de seguridad basado en un tercero de confianza, y aceptado por gran cantidad de aplicaciones y sitios de comercio y transacciones seguras en internet. 295 296 Para la tarea de eliminación de fallas las técnicas como la colaboración utilizando herramientas web, la programación en equipos y las pruebas unitarias y de integración sirvieron para los procesos de prevención, notificación, búsqueda y arreglo de errores, permitiendo además guardar una bitácora del progreso a la solución a problemas. La implementación de características específicas en función de los requisitos cada vez más refinados y particulares que surgieron en las iteraciones de prototipos probados con usuarios y condiciones reales. 297 298 La combinación de diversos elementos como software, hardware y la configuración de un espacio físico adecuado, esto es, que cumpla determinadas reglas para el control de acceso, conforma la infraestructura necesaria para la operación de una AC, incluso que ésta no sea Raíz, y sea parte de otro nodo de la jerarquía. Las condiciones de seguridad lógica y física pueden reproducirse exactamente para los nodos intermedios y los nodos Proveedores de Servicios de Certificación de la ICP, tomando en cuenta el escalamiento. 658 Por otro lado, la configuración conlleva el establecimiento de parámetros para 659 el funcionamiento la aplicación, tales como métodos de control y restricción de 660 acceso, ubicación de archivos y directorios, rutas para importación e exportación 661 de datos, perfiles de usuario, generación y nombres de claves, inicialización 662 de tarjetas inteligentes, inicialización de HSM, y copias de seguridad. 663 664 \section{Lecciones aprendidas} 665 666 La puesta en marcha de una AC Raíz supone obligatoriamente contar con una 667 aplicación que gestione este componente de la infraestructura. En este sentido, 668 éste capítulo mostró el proceso de desarrollo de una aplicación que respondiera 669 a los requisitos particulares de gestión, determinados por el rol de confianza 670 raíz y última que debe representar la Autoridad. En función de ello, la 671 aplicación tiene un alto grado de especialización, ya que cuenta con un 672 mercado relativo de pocos usuarios, si se compara con el mercado de los sistemas 673 de información o aplicaciones de ofimática, y su operación se realiza en 674 condiciones estandándares y específicas. A pesar de este hecho, para la 675 construcción de la aplicación se integraron varios proyectos disponibles en los 676 repositorios de software libre, que permitió disponer de un criptosistema 677 estándar y suficientemente completo para cumplir con los requisitos descritos 678 en la etapa de dise~no. La criptografía se utiliza como herramienta para 679 otorgar las tres propiedades (Confidencialidad, Integridad y Disponibilidad) 680 de la seguridad informática a los datos que gestiona la aplicación, y en virtud 681 de ello el hardware criptográfico utilizado como las tarjetas inteligentes y 682 el módulo de seguridad en hardware configuran un ``mundo seguro'' que cumple 683 con los estándares aceptados a nivel mundial. 684 685 En la etapa de dise~no, los diagramas de casos de uso y actividades sirvieron 686 para obtener una visión formal de los requisitos y de los procesos con los que 687 cumplir la aplicación. Estos documentos de dise~no en el lenguaje UML, permitieron 688 alcanzar de manera más rápida y certera los objetivos que son coincidentes con la 689 gestión real de una AC Raíz. 690 691 Al seguir el estándar X.509 se asegura que los certificados, solicitudes y claves 692 gestionados por la aplicación sean compatibles con el esquema de seguridad basado 693 en un tercero de confianza, y aceptado por gran cantidad de aplicaciones y sitios 694 de comercio y transacciones seguras en internet. 695 696 Para la tarea de eliminación de fallas las técnicas como la colaboración utilizando 697 herramientas web, la programación en equipos y las pruebas unitarias y de integración 698 sirvieron para los procesos de prevención, notificación, búsqueda y arreglo de 699 errores, permitiendo además guardar una bitácora del progreso a la solución a 700 problemas. La implementación de características específicas en función de los 701 requisitos cada vez más refinados y particulares que surgieron en las iteraciones 702 de prototipos probados con usuarios y condiciones reales. 703 704 La combinación de diversos elementos como software, hardware y la configuración de 705 un espacio físico adecuado, esto es, que cumpla determinadas reglas para el 706 control de acceso, conforma la infraestructura necesaria para la operación de 707 una AC, incluso que ésta no sea Raíz, y sea parte de otro nodo de la jerarquía. 708 Las condiciones de seguridad lógica y física pueden reproducirse exactamente para 709 los nodos intermedios y los nodos Proveedores de Servicios de Certificación de la 710 ICP, tomando en cuenta el escalamiento. 299 711 300 712 %\appendices … … 303 715 304 716 305 \emph{AC}: Autoridad de Certificación; componente de la PKI encargada de guardar de firmar, renovar, revocar las claves de los usuarios o entidades finales. 306 307 \emph{AR}: Autoridad de Registro; componente de la PKI encargada de validar los recaudos de un PSC o Entidad Final, es decir, su identidad, y generar la solicitud para una firma de Certificados. 308 309 \emph{Entidad Final}: Persona natural o jurídica a la que un PSC le expide un certificado digital. 310 311 \emph{PSC}: Proveedor de Servicios de Certificación Digital; Organización que mantiene la infraestructura de nodo de una ICP, y está autorizada a expedir certificados a las personas naturales y jurídicas que soliciten y reunan los recaudos necesarios para obtener un certificado digital. 312 313 \emph{PUB}: Publicador; componente de la PKI encargada de mantener accesibles los certificados digitales emitidos por la PKI en medios como portales Web o directorios. 717 \emph{AC}: Autoridad de Certificación; componente de la PKI encargada de guardar 718 de firmar, renovar, revocar las claves de los usuarios o entidades finales. 719 720 \emph{AR}: Autoridad de Registro; componente de la PKI encargada de validar los 721 recaudos de un PSC o Entidad Final, es decir, su identidad, y generar la solicitud para una firma de Certificados. 722 723 \emph{Entidad Final}: Persona natural o jurídica a la que un PSC le expide un 724 certificado digital. 725 726 \emph{PSC}: Proveedor de Servicios de Certificación Digital; Organización que 727 mantiene la infraestructura de nodo de una ICP, y está autorizada a expedir 728 certificados a las personas naturales y jurídicas que soliciten y reunan los 729 recaudos necesarios para obtener un certificado digital. 730 731 \emph{PUB}: Publicador; componente de la PKI encargada de mantener accesibles 732 los certificados digitales emitidos por la PKI en medios como portales Web o directorios. 314 733 315 \emph{PKI}: Public Key Infrastructure, Infraestructura de clave pública; es el conjunto formado por software, hardware, y políticas que asegura en la internet la propiedad de la claves públicas de los usuarios. 316 317 \emph{HSM}: Hardware Security Module; módulo de seguridad en hardware, equipo físico computacional que contiene funciones criptográficas, en específico funciona para almacenar con un alto nivel de seguridad claves privadas. 734 \emph{PKI}: Public Key Infrastructure, Infraestructura de clave pública; es el 735 conjunto formado por software, hardware, y políticas que asegura en la internet la 736 propiedad de la claves públicas de los usuarios. 737 738 \emph{HSM}: Hardware Security Module; módulo de seguridad en hardware, equipo físico 739 computacional que contiene funciones criptográficas, en específico funciona para 740 almacenar con un alto nivel de seguridad claves privadas. 318 741 319 742 %\bibliography{BibACRaizArticulo} 320 743 %\bibliographystyle{plain} 321 744 745 746 747 748 749 750 751 752 753 % ***************************************************************************** 754 % ***************************************************************************** 755 % a partir de aquí se encuentra el contenido original del artículo de ROOTVE 756 757 % A continuación el contenido del artículo de ROOTVE 758 % 759 % 760 % %\begin{abstract} 761 % Una Autoridad de Certificación Raíz (AC Raíz) es un componente que tiene el rol de ser el 762 % punto más alto de confianza en una estructura jerárquica denominada Infraestructura de Clave 763 % Pública (ICP). Una ICP provee de certificados digitales bajo estándar X.509 a personas, 764 % direcciones IP y direcciones en la Web; proporcionando seguridad lógica, y vinculación 765 % legal a las transacciones que realiza el propietario del certificado en 766 % la Internet. La confianza reside en la protección a través de esquemas fuertes de 767 % seguridad física y lógica de la clave privada que permite la emisión de estos certificados. 768 % Este trabajo muestra el proceso de desarrollo de una aplicación para gestionar el 769 % componente mencionado utilizando bibliotecas, herramientas, compiladores, 770 % sistemas operativos y licencias compatibles con los principios del software libre. 771 % En primer lugar, se determinan los requisitos a ser satisfechos en función de una 772 % descripción general de las funciones y características de una Autoridad de 773 % Certificación; posteriormente, se dise~nan funcionalidades y se especifican 774 % requisitos, con el objetivo de producir una visión formal de los procesos a 775 % automatizar. Se dedica una sección a la implementación que consiste, en la 776 % codificación en un lenguaje de programación, de los procesos previstos en las 777 % etapas anteriores, como también, de la incorporación de mecanismos fuertes de 778 % validación de identidad de usuarios, registro de eventos, firma de acciones por parte 779 % de los administradores de la aplicación, y especificación de conexiones con hardware 780 % especializado, como tarjetas inteligentes. Finalmente, se muestra el despliegue y 781 % configuración de la aplicación, que involucra la instalación en un ambiente seguro 782 % (bóveda o centro de datos) y el enlace de la AC Raíz con los demás componentes de la infraestructura. 783 % 784 % 785 % %\end{abstract} 786 % 787 % %\begin{abstract} 788 % A Certification Authority Root (CA Root) is a component which role is to represent the highest confidence point in a hierarchical structure denominated Public Key Infrastructure (PKI). A PKI provides people, IP addresses and Web domains with digital certificates under X.509 standard, offering logic security and legal entailment to transactions performed on the internet by the certificate’s owner. Confidence resides in private key protection through strong physical and logical security schemes, so these schemes allow the certificate emission. This work shows the development process of a CA root management application. For this development it's used libraries, tools, compilers, operating systems and licenses compatible with the principles of free software. In first place, the requirements to satisfy are determined based on a general description of a CA's functions and characteristics; subsequently, functionalities are designed and requirements are specified in order to produce a formal vision of the processes 789 % to automate. A section is dedicated to the implementation, this consists on codification in a programming language of the processes forseen in the previous stages, like also, of the incorporation of strong mechanisms of validation of identity of users, registry of events, actions signature by application's administrators, and connections specification with specialized hardware, like smart cards. Finally, application display and configuration are shown, it involves its installation in a safe environment (vault or data center) and CA Root connection with other components of the infrastructure. 790 % %\end{abstract} 791 % 792 % %\begin{keywords} Infraestructura de Clave Pública, Estándar X.509, Certificado Digital, Firma Electrónica, Autoridad de Certificación Raíz. 793 % %\end{keywords} 794 % 795 % 796 % \section{Introducción} 797 % 798 % \label{sec:intro}La disponibilidad de Internet como medio digital seguro permite 799 % que cualquier persona, empresa, institución, o administración realice transacciones 800 % gubernamentales, comerciales o personales en la mayoría de los casos, tal cual, 801 % como se realizarían en una oficina o espacio físico de forma presencial. Dado este 802 % hecho, al utilizar Internet para establecer relaciones humanas, se está de acuerdo 803 % que es necesario trasladar el concepto de ``identidad'' al medio digital\cite{NIC:03}. 804 % La criptografía provee algoritmos y mecanismos para construir este concepto 805 % en la red, ya que es posible utilizar herramientas que aporten elementos para 806 % definir la identidad de un usuario, entidad o institución, de la misma forma de 807 % la que se está familiarizado en el mundo real. 808 % 809 % En muchas ocasiones para realizar actividades cotidianas personales o de trabajo, 810 % se debe establecer contacto con un individuo u organización que no se conoce o del 811 % cuál no se tiene ninguna referencia. Mediante un contacto personal o directo, los 812 % sentidos humanos permiten percibir un gran número de detalles que le caracterizan, y 813 % cuya combinación muy probablemente le hace irrepetible. Esta combinación permite 814 % identificar al individuo de forma única y certera. Dicho esto, la identidad se 815 % define como el reconocimiento que se hace de las credenciales físicas o informativas, 816 % que ese individuo ofrece para que se le acepte como poseedor de una determinada 817 % individualidad \cite{STAL:03}. Las credenciales físicas pueden ser documentos como 818 % la Cédula de Identidad, el Pasaporte, la Licencia de Conducir, entre otros. Todos los 819 % documentos citados generalmente incluyen una fotografía que permite la comparación 820 % con la apariencia del interlocutor; también usualmente se agrega otra característica 821 % informativa que puede ser un nombre, una firma manuscrita y posiblemente un número 822 % de referencia. 823 % 824 % Cuando se traslada el concepto de identidad al medio informático, se habla de 825 % identidad digital, y se hace necesario contar credenciales traducibles a 826 % información binaria. Por otro lado, la criptografía, por sí misma no proporciona este 827 % concepto: es el uso de una infraestructura computacional que utiliza algoritmos 828 % criptográficos para representar credenciales digitales, como por ejemplo el certificado 829 % digital, y que son otorgados por terceros de confianza, denominados Autoridades 830 % de Certificación (AC), y que se describen como Raíz cuando son el punto inicial de una 831 % jerarquía, las que proveen a usuarios y organizaciones de identidad digital, y que 832 % cuenta con las mismas connotaciones que tiene este concepto en el ámbito personal 833 % y jurídico. 834 % \\ 835 % Uno de los problemas que aparece en este punto, en la disponibilidad de la 836 % infraestructura mencionada anteriormente, la cuál debe contar como un elemento 837 % obligatorio una aplicación que gestione, bajo un estándar aceptado, como lo es el 838 % estándar X.509\cite{NASH:02}, los certificados digitales que emite la AC. 839 % La discusión de importantes aspectos que surgen en las diferentes etapas del 840 % proceso desarrollo de la aplicación de gestión, y que están vinculados con los 841 % principios del software libre y los requisitos muy particulares del ambiente 842 % de despliegue, subrayan los objetivos de este trabajo. 843 % 844 % \section{Marco Teórico} 845 % 846 % Con el objetivo de contextualizar los términos ``identidad'', ``confianza'', o 847 % ``transacción segura'' y``AC Raíz'' en el medio digital, y específicamente en 848 % relación con internet; es imprescindible en una primera aproximación, discutir sobre 849 % determinados temas y conceptos vinculados con la seguridad informática. En los párrafos 850 % siguientes se abordan brevemente algunos de los puntos más importantes relacionados con el tema. 851 % 852 % \subsection{Seguridad Informática} 853 % 854 % Se ha llegado a un consenso sobre lo que significa seguridad informática\cite{STAL:03}. 855 % En general, se dice que un activo de información, (información digital con un valor 856 % real para una empresa o persona) está asegurado si cumple con niveles aceptables 857 % relativos a su valor potencial en los siguientes aspectos: 858 % \\ \\ 859 % \textbf{Disponibilidad:} es el grado en que un dato está en el lugar, momento y 860 % forma en que es requerido por uno o un conjunto de usuarios autorizados. Como 861 % premisa, un sistema seguro debe mantener la información disponible para los 862 % usuarios autorizados. Disponibilidad también significa que el sistema, debe 863 % mantenerse funcionando eficientemente y es capaz de recuperarse rápidamente 864 % en caso de fallo. 865 % \\ \\ 866 % \textbf{Confidencialidad:} es el aspecto de la seguridad que permite mantener en 867 % secreto la información y solo los usuarios autorizados pueden manipularla. 868 % Igual que para la disponiblidad, los usuarios pueden ser personas, procesos o 869 % programas. Para evitar que nadie no autorizado pueda tener acceso a la información 870 % transferida y que recorre la Red se utilizan técnicas de cifrado o codificación de 871 % datos. Hay que mantener una cierta coherencia para determinar cuál es el grado de 872 % confidencialidad de la información que se está manejando, para así evitar un esfuerzo 873 % suplementario a la hora de decodificar una información previamente codificada. 874 % \\ \\ 875 % \textbf{Integridad:} corresponde a garantizar que la información transmitida entre dos 876 % entidades autorizadas no sea modificada por un tercero no autorizado. Un mecanismo 877 % para lograrlo es la utilización de firmas digitales. 878 % Mediante una firma digital se codifican los mensajes a transferir, de forma que una 879 % función, denominada hash \cite{ACE:03}, calcula un resumen de dicho mensaje y se 880 % le a~nade. La validación de la integridad del mensaje se realiza aplicándole al original la 881 % misma función y comparando el resultado con el resumen que se a~nadió al final cuando 882 % se calculo por primera vez antes de enviarlo. 883 % Mantener la integridad es importante para verificar que en el tiempo de viaje por 884 % la Red de la información entre el sitio emisor y receptor ningún agente externo o 885 % extra\~no ha modificado el mensaje. 886 % 887 % \subsection{Criptografía} 888 % La criptografía es la ciencia o arte información utilizando técnicas matemáticas 889 % que hagan posible el intercambio de mensajes de manera que sólo puedan ser leídos 890 % por las personas o usuarios autorizados \cite{STAL:03}. La criptografía ha tomado 891 % gran importancia en los últimos a~nos, ya que es posible transformar las 892 % ``técnicas matemáticas'' en algoritmos que pueden ser comprendidos por una computadora. 893 % Se puede clasificar la criptografía en dos tipos, según el tipo de clave que se utilice: 894 % 895 % \textbf{Criptografía Simétrica:} los sistemas de criptografía simétrica son aquellos 896 % que utilizan una única clave para cifrar y descifrar un texto claro. Este tipo de 897 % sistema conlleva una desventaja, que consiste en el conocimiento de las partes 898 % (emisor y receptor) de la clave única que les permite intercambiar información 899 % por un canal seguro. Como respuesta a ello, se hace necesario formalizar un procedimiento 900 % que muestre a las partes autorizadas la información sobre la clave, sin que sea 901 % develada a un tercero no autorizado. 902 % 903 % \textbf{Criptografía Asimétrica:} también se conoce como Sistema de Cifrado 904 % de Clave Pública\cite{STAL:03}. Usa dos claves diferentes, una de ellas es la 905 % Clave Pública que puede ser enviada a cualquier persona y otra, que se 906 % denomina Clave Privada que es secreta, y no debe ser revelada. A diferencia del 907 % sistema de cifrado simétrico donde las partes deben concertar un procedimiento 908 % para conocer la clave única, en este tipo de sistema el remitente usa la clave 909 % pública del dest inatario para cifrar el documento. Una vez que el documento o 910 % mensaje ha sido cifrado, solamente con la clave privada del destinatario el 911 % mensaje puede ser descifrado. 912 % 913 % \subsection{Certificados digitales} 914 % 915 % Un certificado digital es un documento de acreditación que permite a las partes 916 % tener confianza en las transacciones que realicen en internet. Por tanto, 917 % garantiza la identidad de su poseedor mediante un sistema de claves administrado 918 % por una tercera parte de confianza. Para validar un certificado basta con conocer 919 % la clave pública de la tercera parte conocida como la Autoridad de Confianza (AC). 920 % Para cuidarnos de que piratas informáticos cambien su clave pública por la de la 921 % autoridad de confianza, la AC debe crear un certificado con su propia información de 922 % identidad y a la vez su clave pública y firmar el certificado, este certificado se le 923 % conoce como certificado autofirmado. 924 % Dado que los certificados son información pública y lo que se desea es que todos 925 % tengan acceso a ellos, pueden hacerse copias del certificado de acuerdo sea necesario. 926 % Los certificados digitales permiten varias cosas, entre ellas se pueden citar que los 927 % usuarios pueden a~nadir firmas electrónicas a los formularios en línea; que los 928 % destinatarios pueden comprobar la autenticidad del correo electrónico confidencial; 929 % que los compradores pueden estar seguros de que un website es legítimo; y por último, 930 % controla el acceso a bancos y comercios online, así como los intranets y extranets. 931 % 932 % \subsection{Estándar X.509} 933 % 934 % 935 % X.509 y X.500 fueron originalmente dise\~nados a mediados de los a\~nos 80, antes 936 % del enorme crecimiento de usuarios en Internet. Es por esto por lo que se 937 % dise\~naron para operar en un ambiente donde sólo los computadores se interconectaban 938 % intermitentemente entre ellos. En las versiones 1 y 2 de X.509 se utiliza una 939 % lista estandarizada denominada ``CRL'' (Certificate Revocation List) que contiene la 940 % información referente a clientes o certificados que han sido revocados. 941 % 942 % La versión 3 introduce cambios significativos en el estándar. El cambio fundamental 943 % es el hacer el formato de los certificados y los CRLs extensible. Ahora los que 944 % implementen X.509 pueden definir el contenido de los certificados como crean 945 % conveniente. Además se han definido extensiones estándares para proveer una 946 % funcionalidad mejorada. 947 % 948 % 949 % Con la utilización de la tecnología de certificados digitales se provee a los 950 % clientes (personas o programas) de un nivel más alto en los procesos de 951 % autenticación y autorización, ya que se le otorga al cliente algo que puede poseer, 952 % incluso incluir dentro de elemento físico, como una tarjeta inteligente. 953 % Los certificados en el formato X.509 v3 contienen datos del sujeto, 954 % como su nombre, dirección, correo electrónico, etc. (Ver Fig. \ref{fig:estandarx509}) 955 % 956 % En la versión 3 de X.509, no hace falta aplicar restricciones sobre la estructura 957 % del certificado, gracias a la definición de las extensiones de certificados. 958 % Se permite que una organización pueda definir sus propias extensiones para 959 % contener información específica dentro de su entorno de operación. 960 % Este tipo de certificados es el que usa el protocolo de comercio electrónico 961 % SET (del inglés Secure Electronic Transaction, Transacción Electrónica Segura) \cite{IBM:98}. 962 % 963 % \begin{figure}[htb] 964 % \centering 965 % \includegraphics[width=8cm]{imagenes/estandarX509.png} 966 % \caption{Especificación del estandar X.509} 967 % \label{fig:estandarx509} 968 % \end{figure} 969 % 970 % 971 % Los certificados digitales tienen multitud de usos, entre los tipos de certificados 972 % más utilizados están: 973 % 974 % \begin{itemize} 975 % \item \textbf{Certificado de Servidor SSL (del inglés Socket Secure Layer, Nivel de Conexión Segura):} 976 % Permite incorporar el protocolo SSL a un servidor web con el objetivo que 977 % toda la comunicación entre el cliente y el servidor permanezca segura, 978 % cifrando la información que envía cada parte. El certificado del servidor posibilita 979 % la autenticación fuerte, es decir, que el servidor puede exigir certificados 980 % personales de navegación a los usuarios para acceder a determinadas carpetas, 981 % lo que repercute en la seguridad y en la comodidad por la ausencia de cuentas 982 % y contrase\~nas para la identificación de los usuarios. 983 % 984 % \item \textbf{Certificados personales (Correo y navegación):} Un certificado digital 985 % personal es la herramienta necesaria para navegar, comprar y enviar/recibir correo 986 % a través de Internet, de una manera segura. Con el uso de este certificado se puede 987 % firmar o cifrar los mensajes de correo para tener la seguridad que el receptor será 988 % el único lector de nuestro mensaje. Se puede aumentar la seguridad y confianza entre el 989 % cliente y el servidor web, al autenticarse también al usuario, esto también va a permitir 990 % a las empresas la posibilidad de personalizar los contenidos a un usuario concreto, 991 % con la certeza que otros usuarios no podrán ver dicho contenido, tales como información 992 % confidencial, ofertas especiales, entre otros. 993 % 994 % \item \textbf{Certificado para firma de código:} El certificado para la firma de 995 % código permite a un administrador, desarrollador o empresa de software firmar su 996 % software y macros, y distribuirlo de una forma segura. Esta solución de Seguridad es el 997 % requisito mínimo que necesitan nuestros clientes o lista de correo, para confiar y 998 % tener la seguridad de que el fichero que reciben o se descargan, proviene exclusivamente 999 % de una empresa determinada. Con ello se evitan los problemas causados por la 1000 % suplantación de personalidad y la distribución de objetos da\~ninos o perjudiciales 1001 % bajo esta supuesta identidad. Cualquier modificación (por ejemplo: inclusión de un 1002 % troyano o infección de un virus) sobre el software original lo invalidará, con lo que el 1003 % usuario tendrá la confirmación para rechazarlo al comprobar que la firma electrónica 1004 % no corresponde con la del software modificado. 1005 % \end{itemize} 1006 % \subsection{Lenguaje Unificado de Modelado} 1007 % 1008 % UML ( del inglés Unified Modeling Language, Lenguaje de Modelado Unificado) es un lenguaje 1009 % que permite diseñar sistemas a través de modelos, que se componen de un conjunto 1010 % de símbolos y diagramas en donde se plasma las ideas de funcionalidad. 1011 % El UML fue creado por Grady Booch, James Rumbaugh e Ivar Jacobson en el a~no 1012 % 1997\cite{SCHM:03},\cite{BOOC:99} y \cite{MULL:97}. Cada diagrama tiene fines distintos 1013 % dentro del proceso de desarrollo, su finalidad es presentar diversas perspectivas 1014 % de un sistema. La clave está en organizar el proceso de dise~no de tal forma que los analistas, 1015 % clientes, desarrolladores y otras personas involucradas en el desarrollo del modelo 1016 % lo comprendan y convengan con él. Los diagramas que componen el lenguaje son: 1017 % 1018 % \begin{itemize} 1019 % \item Diagramas de casos de uso 1020 % \item Diagramas de estados 1021 % \item Diagramas de secuencias 1022 % \item Diagramas de colaboraciones 1023 % \item Diagramas de distribución 1024 % \item Diagramas de actividades 1025 % \item Diagramas de componentes 1026 % \item Diagrama de despliegue 1027 % \end{itemize} 1028 % 1029 % En este trabajo se utilizaron esencialmente los diagramas de clases, los diagramas de 1030 % casos de uso y los diagramas de actividades, que se describen brevemente a continuación: 1031 % 1032 % \textbf{Diagramas de clases:} son representaciones gráficas de las categorías en que 1033 % pueden clasificarse los objetos del mundo real. En general, se hace una descripción 1034 % de las categorías que se utilizan en la aplicación a desarrollar. Los clases se 1035 % dise~nan en funcion de sus atributos y relaciones con otras clases. 1036 % 1037 % \textbf{Diagramas de casos de uso:} son descripciones de las acciones que debe 1038 % realizar el usuario en el sistema \cite{SCHM:03}. Por ejemplo: Usuario que tiene la 1039 % necesidad de expedir un certificado digital a una AC de confianza. 1040 % 1041 % 1042 % \textbf{Diagramas de actividades:} muestran el flujo de actividades que ocurren 1043 % dentro de un caso de uso o dentro de un comportamiento de un objeto\cite{SCHM:03}. 1044 % Por ejemplo, las actividades que se realizan para expedir un certificado digital. 1045 % 1046 % \subsection{Software Libre} 1047 % 1048 % \label{sec:softlibre}El software libre \cite{FSF:07} es un asunto de libertad, 1049 % no de precio. Para que un programa, aplicación o conjunto concreto se 1050 % considere ``software libre'' debe cumplir con las siguientes libertades: 1051 % 1) Libertad de ejecutar el programa en cualquier sitio, cualquier propósito, 1052 % por siempre; 2) Libertad de estudiarlo y adaptarlo a nuestras necesidades; 1053 % 3) Libertad de redistribuirlo a cualquiera, logrando ayudar a un amigo o vecino; 1054 % y por último 4)la Libertad de mejorar el programa y publicar las mejoras. 1055 % 1056 % Las libertades antes expuestas, proveen muchos beneficios a los usuarios finales. 1057 % En particular, en el área de seguridad informática. Se pueden nombrar entre los 1058 % beneficios más importantes: la no dependencia de un único fabricante, y la posibilidad 1059 % de realizar auditorías y pruebas exhaustivas por parte de terceros, que pueden 1060 % ser personas, empresas o instituciones diferentes responsables del proyecto 1061 % de software. Los procesos de adaptación, mantenimiento, integración y auditorías 1062 % son más transparentes y colaborativos. 1063 % 1064 % 1065 % \section{Infraestructura de Clave Pública} 1066 % 1067 % Uno de los problemas del despliegue de la tecnologías basada en certificados y 1068 % firmas digitales, es contar con un elemento que proporcione una relación 1069 % fuerte de confianza entre dos o más sujetos que desean realizar una operación o 1070 % transacción utilizando como medio Internet. Es por ello, que se recurre a 1071 % establecer un tercero de confianza, que se define, como un actor encargado de 1072 % brindar confianza basada en la disponibilidad de una infraestructura robusta que 1073 % incluya el uso tecnologías basadas en algoritmos criptográficos estandarizados, 1074 % y la aplicación estricta de políticas para los procesos de registro, publicación, 1075 % firma, renovación y revocación de certificados. 1076 % El tercero de confianza se denomina Infraestructura de Clave Pública (ICP)\cite{NASH:02}, 1077 % y consiste en la combinación de hardware y software, políticas y procedimientos 1078 % que permiten asegurar la identidad de los participantes en un intercambio de datos 1079 % usando criptografía pública. Una ICP debe proporcionar los tres conceptos de 1080 % seguridad mencionados anteriormente. 1081 % 1082 % \subsection{Componentes de la Infraestructura de Claves Pública (ICP)} 1083 % Los componentes habituales que conforman la infraestructura son los siguientes 1084 % (Ver Fig. \ref{fig:arquitecturapsc}): 1085 % \begin{itemize} 1086 % \item Autoridad de Registro (AR): es el nodo o conjunto de nodos responsables 1087 % del registro y la autenticación inicial de los usuarios a quiénes 1088 % se les expide un certificado, después de aprobada una solicitud de registro. 1089 % \item Autoridad de Certificación (AC): es el nodo central de la infraestructura, 1090 % se encarga de los procedimientos de firma, renovación y revocación de 1091 % certificados digitales. El procedimiento de firma de certificados utiliza 1092 % la clave privada de la AC. 1093 % \item Interfaz con los clientes (PUB): es el nodo que brinda toda la información 1094 % a las entidades finales (usuarios) sobre el estado de su certificado, además de 1095 % ofrecer una información general al público en general sobre los aspectos y servicios 1096 % relevantes de la ICP. 1097 % \end{itemize} 1098 % 1099 % 1100 % Los nodos de una ICP pueden ordenarse según diversos modelos. El más utilizado es 1101 % el modelo jerárquico, que presenta una raíz y nodos hijos que distribuyen los 1102 % certificados a los clientes o entidades finales (Ver Fig. \ref{fig:jerarquia}). 1103 % Se muestra un ejemplo de modelo de jerarquía de una ICP de cuatro niveles, 1104 % que se encuentra en el tercer nivel del modelo, que certifica a los usuarios. 1105 % 1106 % \begin{figure}[htb] 1107 % \centering 1108 % \includegraphics[width=8cm]{imagenes/jerarquia.png} 1109 % \caption{Modelo jerárquico de una ICP} 1110 % \label{fig:jerarquia} 1111 % \end{figure} 1112 % 1113 % Este modelo de establecimiento de relaciones de confianza, es necesaria entre 1114 % múltiples autoridades de certificación para garantizar que los usuarios 1115 % (entidades finales) no tengan que depender y confiar en una sola AC, algo que haría 1116 % imposible el manejo de estabilidad, administración y protección. El objetivo 1117 % es que las entidades finales que utilizan identidades creadas por una AC puedan 1118 % confiar en ellas, aunque dichas partes tenga una autoridad expedidora diferente. 1119 % 1120 % 1121 % 1122 % \section{Desarrollo de la aplicación} 1123 % 1124 % En los párrafos siguientes se discute los aspectos, procesos y técnicas 1125 % principales, que se siguen a lo largo del desarrollo de la aplicación (software) 1126 % de gestión del componente Autoridad Certificadora Raíz. 1127 % 1128 % 1129 % \subsection{Conceptualización} 1130 % 1131 % 1132 % Uno de los objetivos de esta etapa es determinar el rol del componente AC Raíz 1133 % en la ICP, con la finalidad de obtener los requisitos, procesos y funciones que 1134 % deben ser implementados por el software. Este rol tiene que ver con la definición 1135 % de la AC Raíz como elemento central y de máximo resguardo de la infraestructura, 1136 % ya que este nodo inicial o ``Raíz'' contiene la clave privada que valida todos los 1137 % certificados de los otros nodos de la jerarquía. 1138 % 1139 % Se considera como punto importante en esta etapa, distinguir las diferencias entre 1140 % una AC Raíz y una AC de un Proveedor de Servicios de Certificación (PSC). La diferencia 1141 % principal entre estos dos tipos de AC, es la cantidad de certificados que deben gestionar 1142 % (firmar, renovar, revocar, etc) , en un determinado periodo cada uno de ellos. Esto es, una 1143 % AC Raíz solo gestiona un número mínimo de certificados, los cuáles sirven para dar inicio a 1144 % la jerarquía (certificados otorgados a los PSC), por el contrario, una AC de un PSC debe 1145 % gestionar un número mucho mayor de certificados, ya que la función de este nodo es 1146 % entregar certificados periódicamente a usuarios, también llamados entidades finales. 1147 % 1148 % La diferencia de escala de los dos tipos de AC conlleva a que la AC Raíz tenga 1149 % características particulares, que tienen que ver los niveles y elementos de seguridad 1150 % tanto físicos como lógicos que deben considerarse en la gestión del componente. 1151 % Por ejemplo, la desconexión de red del equipo donde se ejecuta la aplicación de 1152 % gestión hace que la recepción y entrega de certificados se realice a través de 1153 % unidades de memoria externas y portátiles, debidamente validadas, con las cuáles 1154 % el software debe mantener una comunicación segura. 1155 % 1156 % La conexión de la aplicación con hardware especializado, como el almacenador 1157 % y generador de claves públicas/privadas (Hardware Security Module: HSM) o las 1158 % tarjetas inteligentes, es un factor que debe considerarse en el momento de enumerar 1159 % las funciones iniciales del software de gestión. 1160 % 1161 % La selección del sistema operativo Linux\cite{SARW:03} para desplegar la aplicación, 1162 % ya que cumple con los principios del software libre, y cuenta con gran número de 1163 % herramientas en el área de programación \cite{KURT:01}, es un requisito no funcional 1164 % que se establece en esta etapa. 1165 % 1166 % Considerando los aspectos nombrados anteriormente, en este punto se elabora una lista 1167 % inicial de requisitos, con la cual debe cumplir la aplicación. Como técnicas utilizadas 1168 % en ésta etapa están la realización de entrevistas a clientes, a posibles administradores 1169 % y operadores; la elaboración de tablas comparativas entre diferentes aplicaciones que 1170 % existen en las bibliotecas o portales de software libre, con la finalidad de evaluar las 1171 % herramientas a utilizar en la elaboración de la aplicación. 1172 % 1173 % 1174 % \subsection{Dise\~no} 1175 % 1176 % La etapa de dise\~no consiste en elaborar diagramas formales que permitan en la etapa 1177 % de implementación representar requisitos y procesos de la gestión del componente AC Raíz 1178 % en un lenguaje de programación. Para el dise\~no de requisitos se utilizan los diagramas 1179 % de casos de uso del lenguaje UML, que muestran una primera aproximación las operaciones 1180 % que se deben realizar en relación con las entradas dadas por los usuarios. Los actores 1181 % (usuarios) del caso de uso principal que se muestra en la Fig. \ref{fig:casodeusoprincipal} 1182 % son: el Administrador del componente AC, el Administrador del Componente AR, el Administrador 1183 % del componente PUB, y el actor PSC, quiénes son los que interactúan con la aplicación. 1184 % 1185 % \begin{figure}[htb] 1186 % \centering 1187 % \includegraphics[width=8cm]{imagenes/casodeusogeneral.png} 1188 % \caption{Caso de uso principal} 1189 % \label{fig:casodeusoprincipal} 1190 % \end{figure} 1191 % 1192 % Para el resto de la especificación de requisitos se elaboran casos de uso que modelan 1193 % las funcionalidades con que debe contar la aplicación. Para cada actor, se especifican 1194 % el correspondiente diagrama de caso de uso. En la Fig. \ref{fig:casodeusoac} se 1195 % muestra el caso de uso para el actor del componente AC. Las acciones que realiza 1196 % este actor son emisión, renovación y revocación de certificados, que conlleva procesos 1197 % de firma con la clave privada, modificación de los periodos de vigencia del certificado 1198 % y elaboración de listas de certificados revocados respectivamente para casa caso de uso. 1199 % 1200 % \begin{figure}[htb] 1201 % \centering 1202 % \includegraphics[width=8cm]{imagenes/casodeusoac.png} 1203 % \caption{Caso de uso para el actor Administrador Autoridad de Certificación} 1204 % \label{fig:casodeusoac} 1205 % \end{figure} 1206 % 1207 % 1208 % También en esta etapa se construye el modelo de datos de la aplicación. 1209 % La Fig. \ref{fig:diagramadeclases} muestra de forma parcial, ya que no se incluyen 1210 % los atributos, el diagrama de clases que explica el modelo de datos. Se consideran 1211 % como objetos persistentes del sistema a elementos como usuarios, clientes, 1212 % certificados, autoridades o proveedores de certificación, solicitudes de autoridad de 1213 % certificación, solicitudes de entidad finales, y sus respectivas relaciones. 1214 % 1215 % \begin{figure}[htb] 1216 % \centering 1217 % \includegraphics[width=8cm]{imagenes/diagramadeclases.png} 1218 % \caption{Diagrama de clases} 1219 % \label{fig:diagramadeclases} 1220 % \end{figure} 1221 % 1222 % 1223 % Para modelar la secuencia de acciones que se realizan para cada caso de uso se 1224 % utilizan los diagramas de actividades. La Fig. \ref{fig:diagramaactividades} 1225 % muestra el diagrama de actividades general para el caso de uso ``Emisión de 1226 % certificados''' del actor Administrador del componente AC. Para este conjunto de 1227 % actividades participan cuatro (4) actores: Administrador del PSC, quién entrega los 1228 % recaudos necesarios para que se le firme su solicitud, el Administrador de la AR, 1229 % quién es el encargado de chequear los recaudos entregados por el PSC, el Administrador 1230 % de la AC Raíz y el Administrador PUB, este último encargado de de publicar en los 1231 % diferentes repositorios los certificados (claves públicas) para que sean visibles por 1232 % el mayor número de usuarios interesados. 1233 % 1234 % 1235 % \begin{figure}[htb] 1236 % \centering 1237 % \includegraphics[width=8cm]{imagenes/diagramaactividades.png} 1238 % \caption{Diagrama de actividades} 1239 % \label{fig:diagramaactividades} 1240 % \end{figure} 1241 % 1242 % 1243 % \subsection{Implementación} 1244 % 1245 % 1246 % En esta etapa se utiliza como insumo los diagramas de casos de uso, diagrama 1247 % de clases y actividades, generados en la etapa de dise~no. Se traduce el 1248 % diagrama de clases al que se hace referencia en la Fig. \ref{fig:diagramaactividades} 1249 % en un modelo de datos relacional, y se genera un script SQL que genera el mapa de 1250 % tablas relacional, donde las tablas representan relaciones tales como usuarios, 1251 % clientes, certificados, y las demás entidades que conforman el modelo de datos. 1252 % 1253 % Se utilizan y validan los diagramas de casos de uso mediante la elaboración de 1254 % interfaces gráficas de usuarios y funcionalidades de interacción con el usuario. 1255 % Los diagramas de actividades ayudan en el planteamiento de algoritmos que proveen 1256 % funcionalidades o características con las cuáles debe contar la aplicación y 1257 % que deben estar en coordinación con los respuestas y valores esperados. 1258 % 1259 % 1260 % Haciendo uso de las ventajas que trae el uso de software libre (Sección \ref{sec:softlibre}), 1261 % se implementa la aplicación utilizando la mayor cantidad de líneas de códigos 1262 % disponibles en los repositorios y proyectos de la comunidad, de tal manera que 1263 % satisfagan los requisitos y funcionalidades planteadas en la etapa de dise~no. 1264 % En este sentido, se utiliza el código fuente del proyecto XCA \cite{XCA:03}, 1265 % desarrollado por Christian Hohnst\"{a}dt, que tiene como objetivo proveer una 1266 % aplicación escrita en el lenguaje de programación C++\cite{STRO:02} y la 1267 % biblioteca Trolltech Qt\cite{BLAN:06}, que cumpla con el estándar X.509. La aplicación 1268 % satisface los requisitos básicos para la gestión del componente de gestión de AC Raíz, 1269 % esto es, los diagramas UML de la etapa de dise~no calzan con un gran conjunto de requisitos 1270 % satisfechos en el proyecto XCA, esto ocurre debido a que este trabajo comparte 1271 % objetivos con dicho proyecto; por ejemplo, para el caso de uso de la Fig. \ref{fig:casodeusoac}, 1272 % donde el actor debe ejecutar tres acciones: emitir, renovar y revocar certificados, 1273 % la aplicación XCA incorpora estas tres actividades, pero se hace necesario adaptar 1274 % la interfaz de usuario y agregar características en función de los requisitos capturados. 1275 % 1276 % Es importante recalcar, que XCA no sastiface todos los requisitos documentados en la 1277 % etapa de dise~no. En respuesta a este hecho, se realiza un proceso de completación de 1278 % funcionalidades. En este sentido, se incorporan características a la aplicación acorde 1279 % con la especificaciones de dise~no, entre las cuáles se enumeran: 1280 % \begin{itemize} 1281 % \item La incorporación de un sub-sistema de seguridad para acceso a los activos de 1282 % información que gestiona la aplicación, que incluya aspectos de autenticación y 1283 % autorización de usuarios, como lo es la validación de credenciales a través del 1284 % uso de tarjetas inteligentes, el registro y firma digital de las acciones realizadas 1285 % por los usuarios dentro de la aplicación. 1286 % En La fig \ref{fig:registro} se muestra la característica de registro de acciones. 1287 % La ventana a la derecha muestra los detalles de la acción seleccionada en la lista, 1288 % se incluyen datos importantes como nombre de la cuenta de usuario, fecha, hora, y 1289 % otros datos particulares relacionadas con la acción realizada por el correspondiente 1290 % usuario. 1291 % 1292 % \begin{figure}[htb] 1293 % \centering 1294 % \includegraphics[width=8cm]{imagenes/registro.png} 1295 % \caption{Sistema de registro de acciones} 1296 % \label{fig:registro} 1297 % \end{figure} 1298 % 1299 % \item Estandarización del sistema de gestión de documentos como solicitudes, 1300 % plantillas de certificados y certificados. 1301 % 1302 % \item Conexión a través de una interfaz propia con el hardware donde se resguardan 1303 % las claves privadas (HSM). 1304 % 1305 % \end{itemize} 1306 % 1307 % También en esta etapa se seleccionan e integran las tecnologías a utilizar para 1308 % la codificación y creación de la aplicación de gestión del componente AC Raíz. 1309 % Los tipos de tecnologías que deben seleccionarse son: bibliotecas para construir 1310 % la interfaz hombre-máquina (HMI), motor criptográfico, conexiones con hardware, 1311 % interfaces con repositorio de datos y algoritmos de cálculo criptográfico más utilizados. 1312 % 1313 % 1314 % Como criptosistema se utiliza OpenSSL version 0.9.8 \cite{VIEG:2002}, que provee 1315 % de un conjunto de funciones criptográficas apegadas al estándar X.509. . Para la 1316 % construcción de interfaces hombre-máquina y uso de algoritmos generales se 1317 % selecciona la biblioteca Trolltech Qt. Como interfaz para el uso de tarjetas 1318 % inteligentes se utilizo el estándar PKCS11, también conocido como Cryptoki, que 1319 % especifica una forma para interactuar con este hardware criptográfico\cite{NIC:03}. 1320 % 1321 % 1322 % 1323 % \subsection{Pruebas} 1324 % 1325 % Esta etapa tiene dos objetivos. El primero de consiste en asegurar que la 1326 % aplicación funcione correctamente, es decir, que se generen la menor cantidad 1327 % de salidas inesperadas o fallas a entradas dadas. En relación al logro de este 1328 % objetivo se utilizan un conjunto de técnicas aplicadas a lo largo del proceso 1329 % de desarrollo, entre las cuáles se pueden citar la revisión en parejas\cite{PRESS:05}, 1330 % que consiste que la programación se realice en equipo de dos programadores por 1331 % computador, uno de ellos se encarga de escribir los algoritmos en un lenguaje 1332 % de programación, y el segundo de ellos de revisarlo inmediatamente, después de 1333 % periodo de unas horas, que debe ser definido con anticipación, se intercambian 1334 % los roles. Otra de las técnicas utilizadas que es importante nombrar son las 1335 % pruebas unitarias\cite{PRESS:05}, las cuáles consisten en aplicar un número 1336 % casos de pruebas a métodos o módulos peque~nos de la aplicación (unidades), 1337 % de tal manera que se asegura que funcionan correctamente de forma independiente. 1338 % Seguidamente, se realizan pruebas de integración, que consisten en probar módulos 1339 % más complejos formados por las unidades revisadas en las pruebas unitarias. 1340 % Las pruebas unitarias y de integración presentan la ventajas que son automatizables, 1341 % y por lo tanto, se cuenta como herramientas de software para llevarlas a cabo. 1342 % 1343 % 1344 % El segundo objetivo, es que se satisfagan los requisitos plasmados en la etapa 1345 % de dise~no, y que se extraen de los diagramas UML , es decir, la aplicación 1346 % debe cumplir con las características necesarias para resolver el problema de 1347 % gestión de una AC Raíz. En este sentido, se toma una estrategia basada en 1348 % prototipos con liberaciones periódicas, que permite a los usuarios y desarrolladores 1349 % de la comunidad chequear el progreso en el proyecto. Los prototipos son 1350 % chequeados por los usuarios y la modificación de requisitos y notificación de 1351 % errores son notificados en un sistema web de chequeo y seguimiento \cite{TRAC:07}. 1352 % 1353 % También se habilita un sistema de control de versiones de licencia libre 1354 % llamado subversion \cite{PILA:04}, que permite a los programadores involucrados 1355 % en el proyecto obtener en todo momento y de forma local o remota la última 1356 % versión de los programas fuentes. 1357 % 1358 % Debido a que la aplicación de gestión de AC Raiz debe ser parte de una 1359 % infraestructura, es necesario realizar pruebas en condiciones similares a la 1360 % configuración final de ésta; por ello se simula la configuración de producción que 1361 % conlleva pruebas con el sistema operativo y el donde se instala la aplicación, 1362 % conexión con tarjetas inteligentes y el módulo de seguridad en hardware, 1363 % controles de acceso físico y lógico, y desconexión de red, ya que la autoridad 1364 % debe operar fuera de línea. 1365 % 1366 % 1367 % \subsection{Despliegue y configuración} 1368 % El despliegue consiste en la instalación en condiciones reales de la 1369 % aplicación de gestión de AC Raíz dentro de la infraestructura. La figura \ref{fig:arquitecturapsc} 1370 % muestra una propuesta para el despliegue de la infraestructura. La aplicación se 1371 % instala en un computador desconectado de red que debe estar ubicado dentro de un 1372 % lugar físico seguro, lo que significa que el acceso a personas deber estar 1373 % restringido por llaves y controles biométricos, y el flujo de información digital 1374 % hacia adentro y afuera de la bóveda debe ser realizado a través de dispositivos 1375 % de memoria secundaria con seguridad incorporada, tal como un lapiz usb (pendrive) 1376 % con bloqueo por contrase~na, como se muestra en la figura. También es necesario 1377 % la habilitación de servidores para la validación de los periodos de vigencia de 1378 % los certificados (OSCP), y para la generación de solicitudes de firma de certificados, 1379 % donde las entidades finales o usuarios consignan los recaudos. 1380 % 1381 % \begin{figure}[htb] 1382 % \centering 1383 % \includegraphics[width=8cm]{imagenes/arquitecturapsc.png} 1384 % \caption{Configuración de los componentes del nodo raíz de una ICP} 1385 % \label{fig:arquitecturapsc} 1386 % \end{figure} 1387 % 1388 % Por otro lado, la configuración conlleva el establecimiento de parámetros para 1389 % el funcionamiento la aplicación, tales como métodos de control y restricción de 1390 % acceso, ubicación de archivos y directorios, rutas para importación e exportación 1391 % de datos, perfiles de usuario, generación y nombres de claves, inicialización 1392 % de tarjetas inteligentes, inicialización de HSM, y copias de seguridad. 1393 % 1394 % \section{Conclusiones} 1395 % 1396 % La puesta en marcha de una AC Raíz supone obligatoriamente contar con una 1397 % aplicación que gestione este componente de la infraestructura. En este sentido, 1398 % éste trabajo mostró el proceso de desarrollo de una aplicación que respondiera 1399 % a los requisitos particulares de gestión, determinados por el rol de confianza 1400 % raíz y última que debe representar la Autoridad. En función de ello, la 1401 % aplicación tiene un alto grado de especialización, ya que cuenta con un 1402 % mercado relativo de pocos usuarios, si se compara con el mercado de los sistemas 1403 % de información o aplicaciones de ofimática, y su operación se realiza en 1404 % condiciones estandándares y específicas. A pesar de este hecho, para la 1405 % construcción de la aplicación se integraron varios proyectos disponibles en los 1406 % repositorios de software libre, que permitió disponer de un criptosistema 1407 % estándar y suficientemente completo para cumplir con los requisitos descritos 1408 % en la etapa de dise~no. La criptografía se utiliza como herramienta para 1409 % otorgar las tres propiedades (Confidencialidad, Integridad y Disponibilidad) 1410 % de la seguridad informática a los datos que gestiona la aplicación, y en virtud 1411 % de ello el hardware criptográfico utilizado como las tarjetas inteligentes y 1412 % el módulo de seguridad en hardware configuran un ``mundo seguro'' que cumple 1413 % con los estándares aceptados a nivel mundial. 1414 % 1415 % En la etapa de dise~no, los diagramas de casos de uso y actividades sirvieron 1416 % para obtener una visión formal de los requisitos y de los procesos con los que 1417 % cumplir la aplicación. Estos documentos de dise~no en el lenguaje UML, permitieron 1418 % alcanzar de manera más rápida y certera los objetivos que son coincidentes con la 1419 % gestión real de una AC Raíz. 1420 % 1421 % Al seguir el estándar X.509 se asegura que los certificados, solicitudes y claves 1422 % gestionados por la aplicación sean compatibles con el esquema de seguridad basado 1423 % en un tercero de confianza, y aceptado por gran cantidad de aplicaciones y sitios 1424 % de comercio y transacciones seguras en internet. 1425 % 1426 % Para la tarea de eliminación de fallas las técnicas como la colaboración utilizando 1427 % herramientas web, la programación en equipos y las pruebas unitarias y de integración 1428 % sirvieron para los procesos de prevención, notificación, búsqueda y arreglo de 1429 % errores, permitiendo además guardar una bitácora del progreso a la solución a 1430 % problemas. La implementación de características específicas en función de los 1431 % requisitos cada vez más refinados y particulares que surgieron en las iteraciones 1432 % de prototipos probados con usuarios y condiciones reales. 1433 % 1434 % La combinación de diversos elementos como software, hardware y la configuración de 1435 % un espacio físico adecuado, esto es, que cumpla determinadas reglas para el 1436 % control de acceso, conforma la infraestructura necesaria para la operación de 1437 % una AC, incluso que ésta no sea Raíz, y sea parte de otro nodo de la jerarquía. 1438 % Las condiciones de seguridad lógica y física pueden reproducirse exactamente para 1439 % los nodos intermedios y los nodos Proveedores de Servicios de Certificación de la 1440 % ICP, tomando en cuenta el escalamiento. 1441 % 1442 % %\appendices 1443 % \section{Glosario} 1444 % \label{ap:glosario} 1445 % 1446 % 1447 % \emph{AC}: Autoridad de Certificación; componente de la PKI encargada de guardar 1448 % de firmar, renovar, revocar las claves de los usuarios o entidades finales. 1449 % 1450 % \emph{AR}: Autoridad de Registro; componente de la PKI encargada de validar los 1451 % recaudos de un PSC o Entidad Final, es decir, su identidad, y generar la solicitud para una firma de Certificados. 1452 % 1453 % \emph{Entidad Final}: Persona natural o jurídica a la que un PSC le expide un 1454 % certificado digital. 1455 % 1456 % \emph{PSC}: Proveedor de Servicios de Certificación Digital; Organización que 1457 % mantiene la infraestructura de nodo de una ICP, y está autorizada a expedir 1458 % certificados a las personas naturales y jurídicas que soliciten y reunan los 1459 % recaudos necesarios para obtener un certificado digital. 1460 % 1461 % \emph{PUB}: Publicador; componente de la PKI encargada de mantener accesibles 1462 % los certificados digitales emitidos por la PKI en medios como portales Web o directorios. 1463 % 1464 % \emph{PKI}: Public Key Infrastructure, Infraestructura de clave pública; es el 1465 % conjunto formado por software, hardware, y políticas que asegura en la internet la 1466 % propiedad de la claves públicas de los usuarios. 1467 % 1468 % \emph{HSM}: Hardware Security Module; módulo de seguridad en hardware, equipo físico 1469 % computacional que contiene funciones criptográficas, en específico funciona para 1470 % almacenar con un alto nivel de seguridad claves privadas. 1471 % 1472 % %\bibliography{BibACRaizArticulo} 1473 % %\bibliographystyle{plain} 1474 %
Note: See TracChangeset
for help on using the changeset viewer.