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