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