source: libros/maquetacion/capitulo5/capitulo5.tex @ 385f126

%\chapter{Certificaci\'on Electr\'onica}

\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}



\chapterauthors{Víctor Bravo y Antonio Araujo
\chapteraffil{Fundación Centro Nacional de Desarrollo e Investigación en Tecnologías Libres}
}
\label{capitulo5}

% Se crea un ambiente bibunit para el cual se creará la bibliografía
\begin{bibunit}[unsrt]

% Desarrollo de una aplicación para Gestión de una Autoridad de Certificación Raíz bajo Estándar X.509 utilizando Software Libre

% La gestión de certificados electrónicos de una Infraestructura
% de Clave Pública (ICP) para establecer identidades digitales se conoce como 
% Certificación Electrónica. Entre los procesos de gestión están la generación,
% almacenamiento y publicación de certificados, así como la publicación de información
% y consulta del estado de vigencia y validez de los mismos.
% 
% En la sección \ref{subsubsection:certificadosElectronicos} se presentó el 
% certificado electrónico como un documento electrónico que permite establecer
% la identidad digital de personas y/o dispositivos. 




%\begin{abstract}
Una Autoridad de Certificación Raíz (AC Raíz) es un componente que
tiene el rol de ser el 
punto más alto de confianza en una ICP. Una ICP genera certificados
electrónicos de acuerdo al 
estándar X.509 proporcionando seguridad lógica, y vinculación
legal a las transacciones que realiza el titular del certificado en 
la Internet. La confianza reside en la protección, a través de esquemas fuertes de 
seguridad física y lógica, de la clave privada que permite la
generación de estos certificados. 

Este trabajo muestra el proceso de desarrollo de una aplicación para gestionar 
una Autoridad de Certificación Raíz utilizando bibliotecas, herramientas,
compiladores, sistemas operativos y licencias compatibles con
los principios del software libre. 
En primer lugar, se determinan los requisitos a ser satisfechos en función de una 
descripción general de las funciones y características de una Autoridad de 
Certificación; posteriormente, se diseñan funcionalidades y se especifican 
requisitos, con el objetivo de producir una visión formal de los procesos a 
automatizar. Se dedica una sección a la implementación que consiste
en la codificación en un lenguaje de programación
de los procesos previstos en las etapas anteriores, como
también, de la incorporación de mecanismos fuertes de 
validación de identidad de usuarios, registro de eventos,
firma de acciones por parte de los administradores de la aplicación, y
especificación de conexiones con hardware especializado, como tarjetas
inteligentes. Finalmente, se describe el despliegue y 
configuración de la aplicación, que involucra la instalación
en un ambiente seguro (bóveda o centro de datos) y el enlace de la AC Raíz con
los demás componentes de la infraestructura.  


%\end{abstract}

%\begin{abstract}
%A Certification Authority Root (CA Root) is a component which role is to represent the highest 
% confidence point in a hierarchical structure denominated Public Key Infrastructure (PKI). 
% A PKI provides people, IP addresses and Web domains with digital certificates under X.509 
% standard, offering logic security and legal entailment to transactions performed on the 
% internet by the certificate’s owner. Confidence resides in private key protection through 
% strong physical and logical security schemes, so these schemes allow the certificate emission. 
% This work shows the development process of a CA root management application. For this development 
% it's used libraries, tools, compilers, operating systems and licenses compatible with the 
% principles of free software. In first place, the requirements to satisfy are determined 
% based on a general description of a CA's functions and characteristics; subsequently, 
% functionalities are designed and requirements are specified in order to produce a formal 
% vision of the processes 
%to automate. A section is dedicated to the implementation, this consists on codification 
% in a programming language of the processes forseen in the previous stages, like also, 
% of the incorporation of strong mechanisms of validation of identity of users, registry
% of events, actions signature by application's administrators, and connections 
% specification with specialized hardware, like smart cards. Finally, application display 
% and configuration are shown, it involves its installation in a safe environment 
% (vault or data center) and CA Root connection with other components of the infrastructure.
%\end{abstract}

%\begin{keywords} Infraestructura de Clave Pública, Estándar X.509, Certificado Digital, Firma Electrónica, Autoridad de Certificación Raíz.
%\end{keywords}


\section{Introducción}

\label{sec:intro}La disponibilidad de Internet como medio digital %seguro permite 
permite que cualquier persona, empresa, institución,
o administración realice transacciones 
gubernamentales, comerciales o personales en la mayoría de los casos, tal cual, 
como se realizarían en una oficina o espacio físico de forma presencial. Dado este 
hecho, al utilizar Internet para establecer relaciones humanas, se está de acuerdo 
que es necesario trasladar el concepto de ``identidad''
al medio digital\cite{NIC:03}. 
La criptografía provee algoritmos y mecanismos para construir este concepto 
en la red, ya que es posible utilizar herramientas que aporten elementos para 
definir la identidad de un usuario, entidad o institución, de la misma forma de 
la que se está familiarizado en el mundo real.

En muchas ocasiones para realizar actividades cotidianas personales
o de trabajo, se debe establecer contacto con un individuo u organización
que no se conoce o del cuál no se tiene ninguna referencia. Mediante un
contacto personal o directo, los sentidos humanos permiten percibir
un gran número de detalles que le caracterizan, y cuya combinación
muy probablemente le hace irrepetible. Esta combinación  permite 
identificar al individuo  de forma única y certera. Dicho esto,
la identidad se define como el reconocimiento que se hace de las
credenciales físicas o informativas, que ese individuo ofrece para
que se le acepte como poseedor de una determinada individualidad
\cite{STAL:03}. Las credenciales físicas pueden ser documentos como 
la Cédula de Identidad, el Pasaporte, la Licencia de Conducir,
entre otros. Todos los documentos citados  generalmente incluyen una
fotografía que permite la comparación con la apariencia del interlocutor;
también usualmente se agrega otra característica informativa que puede
ser un nombre, una  firma manuscrita y posiblemente un número de referencia.

Cuando se traslada el concepto de identidad al medio informático, se habla de 
identidad digital, y se hace necesario contar con credenciales traducibles a 
información binaria. Por otro lado, la criptografía, por sí misma
no proporciona este concepto: es el uso de una infraestructura
computacional que utiliza algoritmos criptográficos para representar
credenciales digitales, como por ejemplo el certificado 
electrónico, y que son otorgados por terceros de confianza,
denominados Autoridades de Certificación (AC), y que se describen
como Raíz cuando son el punto inicial de una jerarquía, las que
proveen a usuarios y organizaciones de identidad digital, y que 
cuenta con las mismas connotaciones que tiene este concepto en el ámbito personal 
y jurídico.
\\
Uno de los problemas que aparece en este punto, es la disponibilidad de la 
infraestructura mencionada anteriormente, la cuál debe contar como un elemento 
obligatorio una aplicación que gestione, bajo un estándar aceptado, como lo es el 
estándar X.509\cite{NASH:02}, los certificados electrónicos que emite la AC. 
La discusión de importantes aspectos que surgen en las diferentes etapas del 
proceso de desarrollo de la aplicación de gestión, y que están vinculados con
los principios del software libre y los requisitos muy particulares del ambiente 
de despliegue, subrayan los objetivos propuestos de este trabajo.

\section{Marco Teórico}

Con el objetivo de contextualizar los términos   ``identidad'', ``confianza'', o 
``transacción segura'' y``AC Raíz'' en el medio digital, y específicamente en 
relación con la Internet; es imprescindible en una primera aproximación,  
discutir sobre 
determinados temas y conceptos vinculados con la seguridad informática.
En los párrafos 
siguientes se abordan brevemente algunos de los puntos más importantes
relacionados con el tema. 
 
\subsection{Seguridad Informática}

Se ha llegado a un consenso sobre lo que significa seguridad
informática \cite{STAL:03}. 
En general, se dice que un activo de información, (información
digital con un valor 
real para una empresa o persona) está asegurado si cumple con
niveles  aceptables 
relativos a su valor potencial en los siguientes aspectos:
\\ \\
\textbf{Disponibilidad:} es el grado en que un dato está en el lugar, momento y 
forma en que es requerido por uno o un conjunto de usuarios autorizados. Como 
premisa, un sistema seguro debe mantener la información disponible para los 
usuarios autorizados. Disponibilidad también significa que el sistema, debe 
mantenerse funcionando eficientemente y es capaz de recuperarse rápidamente 
en caso de fallo.
\\ \\
\textbf{Confidencialidad:} es el aspecto de la seguridad que permite mantener en 
secreto la información y sólo los usuarios autorizados pueden manipularla. 
Igual que para la disponibilidad, los usuarios pueden ser personas, procesos o 
programas. Para evitar que ninguna persona no autorizada pueda tener acceso
a la información transferida y que recorre la red se utilizan técnicas de
cifrado o codificación de 
datos. Hay que mantener una cierta coherencia para determinar cuál es el grado de 
confidencialidad de la información que se está manejando, para así evitar
un esfuerzo 
suplementario a la hora de decodificar una información previamente codificada.
\\ \\
\textbf{Integridad:} corresponde a garantizar que la información transmitida entre dos 
entidades autorizadas no sea modificada por un tercero no autorizado.
Un mecanismo 
para lograrlo es la utilización de firmas electrónicas.
Mediante una firma electrónica se codifican los mensajes
a transferir, de forma que una 
función, denominada hash \cite{ACE:03}, calcula un resumen de
dicho mensaje y se 
le añade. La validación de la integridad del mensaje se realiza
aplicándole al original la 
misma función y comparando el resultado con el resumen que se
añadió al final cuando 
se calculó por primera vez antes de enviarlo.
Mantener la integridad es importante para verificar que en el tiempo de viaje por 
la red de la información entre el sitio emisor y receptor ningún agente externo o 
extra\~no ha modificado el mensaje.

\subsection{Criptografía}
La criptografía  es la ciencia o arte de ocultar información
utilizando técnicas matemáticas 
que hagan posible el intercambio de mensajes de manera que sólo puedan ser leídos 
por las personas o usuarios autorizados \cite{STAL:03}. La criptografía ha tomado 
gran importancia en los últimos años, ya que es posible transformar las 
``técnicas matemáticas'' en algoritmos que pueden ser
comprendidos por una computadora.  
Se puede clasificar la criptografía en dos tipos, según el tipo
de clave que se utilice:

\textbf{Criptografía Simétrica:} los sistemas de criptografía
simétrica son aquellos 
que utilizan una única clave para cifrar y descifrar un texto
claro. Este tipo de 
sistema conlleva una desventaja, que consiste en el conocimiento de las partes 
(emisor y receptor) de la  clave única que les permite intercambiar información 
por un canal seguro. Como respuesta a ello, se hace necesario
formalizar un procedimiento 
que muestre a las partes autorizadas la información sobre la clave, sin que sea 
develada a un tercero no autorizado.

\textbf{Criptografía Asimétrica:} también se conoce como  Sistema de Cifrado 
de Clave Pública \cite{STAL:03}. Usa dos claves diferentes, una de ellas es la 
Clave Pública que puede ser enviada a cualquier persona y otra que se 
denomina Clave Privada, que es secreta y no debe ser revelada. A diferencia del 
sistema de cifrado simétrico donde las partes deben concertar un procedimiento 
para conocer la clave única, en este tipo de sistema el remitente usa la clave 
pública del destinatario para cifrar el documento. Una vez que el documento o 
mensaje ha sido cifrado, solamente con la clave privada del destinatario el 
mensaje puede ser descifrado. 

\subsection{Certificados electrónicos}

Un certificado electrónico es un documento de
acreditación que permite a las partes 
tener confianza en las transacciones que realicen en internet. Por tanto, 
garantiza la identidad de su poseedor mediante un sistema de claves administrado 
por una tercera parte de confianza. Para validar un certificado basta con conocer 
la clave pública de la tercera parte conocida
como la Autoridad de Certificación (AC). 
Para cuidarnos de que piratas informáticos cambien su clave pública por la de la 
autoridad de confianza, la AC debe crear un certificado
con su propia información de 
identidad y a la vez su clave pública y firmar el certificado,
este certificado se le conoce como certificado autofirmado.
Dado que los certificados son información pública y lo que se desea es que todos 
tengan acceso a ellos, pueden hacerse copias del
certificado %de acuerdo sea necesario. 
para su distribución.
Los certificados electrónicos permiten varias cosas, entre ellas
se pueden citar que los 
usuarios pueden añadir firmas electrónicas a los formularios en línea; que los 
destinatarios pueden comprobar la autenticidad del
correo electrónico confidencial; 
que los compradores pueden estar seguros de que un sitio web
es legítimo; y por último, 
controla el acceso a bancos y comercios en línea, así como
las intranets y extranets.

\subsection{Estándar X.509}


X.509 y X.500 fueron originalmente dise\~nados a
mediados de los a\~nos 80, antes 
del enorme crecimiento de usuarios en la Internet.
Es por esto que se 
dise\~naron para operar en un ambiente donde sólo los
computadores se interconectaban 
intermitentemente entre ellos. En las versiones  1 y 2 de X.509 se utiliza una 
lista estandarizada denominada lista de revocación de certificados
(CRL por sus siglas en inglés) 
que contiene la información referente a certificados que han sido revocados. 

La versión 3 introduce cambios significativos en el estándar. El cambio fundamental 
es el hacer el formato de los certificados y las CRL extensible. Ahora los que 
implementen X.509 pueden definir el contenido de los certificados como crean 
conveniente. Además se han definido extensiones estándares para proveer una 
funcionalidad mejorada.


Con la utilización de la tecnología de certificados electrónicos se provee a los 
clientes (personas o programas) de un nivel más alto en los procesos de 
autenticación y autorización, ya que se le otorga al cliente
algo que puede poseer, 
incluso incluir dentro de un elemento físico, como una tarjeta inteligente. 
Los certificados en el formato X.509 v3 contienen datos del sujeto, 
como su nombre, dirección, correo electrónico, etc.
La figura \ref{fig:estandarx509}
muestra un bosquejo de la especificación del estándar X.509 versión 3.

En la versión 3 de X.509, no hace falta aplicar restricciones sobre la estructura 
del certificado, gracias a la definición de las extensiones de certificados. 
Se permite que una organización pueda definir sus propias extensiones para 
contener información específica dentro de su entorno de operación. 
%Este tipo de certificados es el que usa el protocolo de comercio electrónico 
%SET (del inglés Secure Electronic Transaction, Transacción Electrónica Segura) \cite{IBM:98}.

\begin{figure}[htb]
\centering
%\includegraphics[width=8cm]{imagenes/estandarX509.png}
\includegraphics[scale=1]{imagenes/estandarX509.JPEG}
\caption{Especificación del estandar X.509}
\label{fig:estandarx509}
\end{figure}


%Los certificados electrónicos tienen multitud de usos, entre los tipos de certificados 
%más utilizados están:

Entre los tipos de certificados más comunes están:


\begin{itemize}
 \item \textbf{Certificado de Servidor de Conexión Segura
(SSL por sus siglas en inglés):} 
 Permite incorporar el protocolo SSL a un servidor web con el objetivo que 
 toda la comunicación entre el cliente y el servidor permanezca segura, 
 cifrando la información que envía cada parte. El certificado
 del servidor posibilita 
 la autenticación fuerte, es decir, que el servidor puede exigir certificados 
 personales de navegación a los usuarios para acceder a determinadas carpetas, 
 lo que repercute en la seguridad y en la comodidad por la ausencia de cuentas 
 y contrase\~nas para la identificación de los usuarios.

 \item \textbf{Certificados personales (Correo electrónico y
navegación):} Un certificado electrónico 
 personal es la herramienta necesaria para navegar, comprar y
enviar o recibir correo  a través de la Internet, de una manera
segura. Con el uso de este certificado se pueden 
 firmar o cifrar los mensajes  de correo para tener la seguridad
que el receptor será 
 el único lector de nuestro mensaje. Se puede aumentar la
seguridad y confianza entre el 
 cliente y el servidor web, al autenticarse también al usuario,
esto también va a permitir 
 a las empresas la posibilidad de personalizar los contenidos
a un usuario concreto, 
 con la certeza que otros usuarios no podrán ver dicho contenido,
tales como información 
 confidencial, ofertas especiales, entre otros.

 \item \textbf{Certificado para firma de código:} El certificado para la firma de 
 código permite a un administrador, desarrollador o empresa de software firmar su 
 software y macros, y distribuirlo de una forma segura.
 Esta solución de Seguridad es el 
 requisito mínimo que necesitan los clientes o lista de correo, para confiar y 
 tener la seguridad de que el fichero que reciben o se descargan,
 proviene exclusivamente 
 de una empresa determinada. Con ello se evitan los problemas causados por la 
 suplantación de identidad y la distribución de objetos da\~ninos o perjudiciales 
 bajo esta supuesta identidad. Cualquier modificación (por ejemplo: inclusión de un 
 troyano o infección de un virus) sobre el software original
 lo invalidará, con lo que el 
 usuario tendrá la confirmación para rechazarlo al comprobar
que la firma electrónica 
 no corresponde con la del software modificado.    
\end{itemize}


\subsection{Lenguaje Unificado de Modelado}

%UML ( del inglés Unified Modeling Language,  Lenguaje de Modelado Unificado) es un lenguaje 
El Lenguaje de Modelado Unificado (UML por sus siglas en inglés) 
permite diseñar sistemas a través de  modelos, que se componen de un conjunto 
de símbolos y diagramas en donde se plasman las ideas de funcionalidad. 
El UML fue creado por Grady Booch, James Rumbaugh e Ivar Jacobson en el año 
1997\cite{SCHM:03},\cite{BOOC:99} y \cite{MULL:97}. Cada diagrama
tiene fines distintos 
dentro del proceso de desarrollo, su finalidad es presentar diversas perspectivas 
de un sistema. La clave está en organizar el proceso
de diseño de tal forma que los analistas, 
clientes, desarrolladores y otras personas involucradas
en el desarrollo del modelo 
lo comprendan y convengan con él. Los diagramas que componen el lenguaje son:

\begin{itemize}
\item Diagramas de clases
\item Diagramas de casos de uso
\item Diagramas de estados
\item Diagramas de secuencias
\item Diagramas de colaboraciones
\item Diagramas de distribución
\item Diagramas de actividades
\item Diagramas de componentes
\item Diagrama de despliegue
\end{itemize}

En este trabajo se utilizaron esencialmente los
diagramas de clases, los diagramas de
casos de uso y los diagramas de actividades, que se
describen brevemente a continuación:

\textbf{Diagramas de clases:} son representaciones gráficas
de las categorías en que 
pueden clasificarse los objetos del mundo real. En general,
se hace una descripción 
de las categorías que se utilizan en la aplicación a desarrollar. Las clases se 
dise\~nan en función de sus atributos y relaciones con otras clases.

\textbf{Diagramas de casos de uso:} son descripciones de las acciones que debe 
realizar el usuario en el sistema \cite{SCHM:03}.
Por ejemplo: Usuario que tiene la 
necesidad de expedir un certificado electrónico a una AC de confianza.


\textbf{Diagramas de actividades:}  muestran el flujo de actividades que ocurren 
dentro de un caso de uso o dentro de un comportamiento de un objeto\cite{SCHM:03}. 
Por ejemplo, las actividades que se realizan
para expedir un certificado electrónico.

\subsection{Software Libre}

\label{sec:softlibre}El software libre \cite{FSF:07} es un asunto de libertad, 
no de precio. Para que un programa, aplicación o conjunto concreto se 
considere ``software libre'' debe cumplir con las siguientes libertades: 
1) Libertad de ejecutar el programa en cualquier sitio, cualquier propósito, 
por siempre; 2) Libertad de estudiarlo y adaptarlo a nuestras necesidades; 
3) Libertad de redistribuirlo a cualquiera, logrando ayudar a un amigo o vecino; 
y por último 4) la Libertad de mejorar el programa y publicar las mejoras.

Las libertades antes expuestas, proveen  muchos beneficios 
a los usuarios finales. 
En particular, en el área de seguridad informática. Se pueden
nombrar  entre los 
beneficios más importantes: la no dependencia  de un único
fabricante, y la posibilidad 
de realizar auditorías y pruebas exhaustivas por parte de terceros, que pueden 
ser personas, empresas o instituciones diferentes responsables del proyecto 
de software. Los procesos de adaptación, mantenimiento, integración y auditorías 
son más transparentes y colaborativos.


\section{Infraestructura de Clave Pública}

Uno de los problemas del despliegue de la tecnologías basada en certificados y 
firmas electrónicas, es contar con un elemento que proporcione una relación 
fuerte de confianza entre dos o más sujetos que desean realizar una operación o 
transacción utilizando como medio la Internet. Es por ello,  que se recurre a 
establecer un tercero de confianza, que se define, como un actor encargado de 
brindar confianza basada en la disponibilidad de una infraestructura robusta que 
incluya el uso de tecnologías basadas en algoritmos criptográficos
estandarizados, 
y la aplicación estricta de políticas para los procesos de registro, publicación, 
firma, renovación y revocación de certificados. 
El tercero de confianza se denomina Infraestructura
de Clave Pública (ICP) \cite{NASH:02}, 
y consiste en la combinación de hardware y software, políticas y procedimientos 
que permiten asegurar la identidad de los participantes en un intercambio de datos 
usando criptografía de clave pública. Una ICP debe proporcionar
los tres conceptos de 
seguridad mencionados anteriormente.

\subsection{Componentes de la Infraestructura de Clave Pública (ICP)}
Los componentes habituales que conforman la infraestructura  son los siguientes 
(Ver Fig. \ref{fig:arquitecturapsc}):
\begin{itemize}
\item Autoridad de Registro (AR): es el nodo o conjunto de nodos responsables 
del registro y la autenticación inicial de los usuarios a quiénes 
se les expide un certificado, después de  aprobada una solicitud de registro.
\item  Autoridad de Certificación (AC): es el nodo central de la infraestructura, 
se encarga de los procedimientos  de firma, renovación  y revocación de 
certificados electrónicos. El procedimiento de firma  de certificados utiliza 
la clave privada de la AC.
\item Interfaz con los clientes (PUB): es el nodo  que brinda toda la información 
a las entidades finales (usuarios) sobre el estado de su certificado, además de 
ofrecer una información al público en general sobre los aspectos y servicios 
relevantes de la ICP.
\end{itemize}


Los nodos de una ICP pueden ordenarse según diversos modelos.  El más utilizado es 
el modelo jerárquico, que presenta una raíz y nodos hijos que distribuyen los 
certificados a los clientes o entidades finales. En la figura \ref{fig:jerarquia} 
se muestra un ejemplo de modelo de jerarquía de una ICP de cuatro niveles, 
que se encuentra en el tercer nivel del modelo, que certifica a los usuarios.

\begin{figure}[htb]
\centering
%\includegraphics[width=8cm]{imagenes/jerarquia.png}
\includegraphics[scale=1]{imagenes/jerarquia.JPEG}
\caption{Modelo jerárquico de una ICP}
\label{fig:jerarquia}
\end{figure}

Este modelo de establecimiento de relaciones de confianza, es necesario entre 
múltiples autoridades de certificación para garantizar que los usuarios 
(entidades finales) no tengan que depender y confiar
en una sola AC, algo que haría 
imposible el manejo de estabilidad, administración y protección. El objetivo 
es que las entidades finales que utilizan identidades creadas por una AC puedan 
confiar en ellas, aunque dichas partes tengan una autoridad expedidora
diferente.



\section{Desarrollo de la aplicación}

En los párrafos siguientes se discuten los aspectos, procesos y técnicas 
principales, que se siguen a lo largo del desarrollo de la aplicación (software) 
de gestión del componente Autoridad de Certificación Raíz.


\subsection{Conceptualización}


Uno de los objetivos de esta etapa es determinar el rol  del componente AC Raíz 
en la ICP, con la finalidad de obtener los requisitos, procesos y funciones que 
deben ser implementados por el software. Este rol tiene que ver con la definición 
de la AC Raíz como elemento central y de máximo resguardo de la infraestructura, 
ya que este nodo inicial o ``Raíz'' contiene la clave privada que valida todos los 
certificados de los otros nodos de la jerarquía. 

Se considera como punto importante en esta etapa, distinguir las diferencias entre 
una AC Raíz y una AC de un Proveedor de
Servicios de Certificación (PSC). La diferencia 
principal entre estos dos tipos de AC, es la cantidad
de certificados que deben gestionar 
(firmar, renovar, revocar, etc.) , en un determinado
periodo cada uno de ellos.
Esto es, una 
AC Raíz solo gestiona un número mínimo de certificados, 
los cuáles sirven para dar inicio a 
la jerarquía (certificados otorgados a los PSC), por el
contrario, una AC de un PSC debe 
gestionar un número mucho mayor de certificados, ya que
la función de este  nodo es 
entregar certificados  periódicamente a usuarios,
también llamados entidades finales.

La diferencia de escala de los dos tipos de AC conlleva a que la AC Raíz tenga 
características particulares, que tienen que ver con los niveles
y elementos de seguridad
tanto físicos como lógicos que deben considerarse en la gestión del componente. 
Por ejemplo, la desconexión de red del equipo  donde se ejecuta la aplicación de 
gestión hace que la recepción y entrega de certificados se realice a través de 
unidades de memoria externas y portátiles, debidamente validadas, con las cuáles 
el software debe mantener una comunicación segura.


La conexión de la aplicación con hardware especializado,
como el Módulo de Seguridad en Hardware 
(HSM por sus siglas en inglés) que permite generar y almacenar
claves o las tarjetas inteligentes, 
es un factor que debe considerarse en el momento de
enumerar las funciones iniciales del software de gestión.   

La selección del sistema operativo Linux \cite{SARW:03} para
desplegar la aplicación, 
ya que cumple con los principios del software libre, y cuenta
con gran número de 
herramientas en el área de programación \cite{KURT:01}, es
un requisito no funcional que se establece en esta etapa.

Considerando los aspectos nombrados anteriormente,
 en este punto se elabora una lista 
inicial de requisitos, con la cual debe cumplir
la aplicación. Como técnicas utilizadas 
en esta etapa están la realización de entrevistas
a clientes, a posibles administradores 
y operadores; así como la elaboración de tablas
comparativas entre diferentes aplicaciones que 
existen en las bibliotecas o portales de software libre, con
la finalidad de evaluar las herramientas a utilizar en la
elaboración de la aplicación. 


\subsection{Dise\~no}

La etapa de dise\~no consiste en elaborar diagramas
formales que permitan en la etapa 
de implementación la representación de requisitos y
procesos de la gestión del componente AC Raíz 
en un lenguaje de programación.  Para el dise\~no de
requisitos se utilizan los diagramas 
de casos de uso del lenguaje UML, que muestran una
primera aproximación de las operaciones 
que se deben realizar en relación con las entradas dadas
por los usuarios. Los actores 
(usuarios) del caso de uso principal que se muestra en la
figura \ref{fig:casodeusoprincipal} 
son: el Administrador del componente AC, el Administrador
del Componente AR, el Administrador 
del componente PUB, y el actor PSC, quiénes son los que
interactúan con la aplicación.

\begin{figure}[htb]
\centering
%\includegraphics[width=8cm]{imagenes/casodeusogeneral.png}
\includegraphics[scale=1]{imagenes/casodeUsoGeneral.JPEG}
\caption{Caso de uso principal}
\label{fig:casodeusoprincipal}
\end{figure}

Para el resto de la especificación de requisitos se elaboran casos de uso que modelan 
las funcionalidades con que debe contar la aplicación. Para cada actor, se especifican 
el correspondiente diagrama de caso de uso. En la figura \ref{fig:casodeusoac} se 
muestra el caso de uso para el actor del componente AC. Las acciones que realiza 
este actor son emisión, renovación y revocación de certificados, que conlleva procesos 
de firma con la clave privada, modificación de los periodos de vigencia del certificado 
y elaboración de listas de certificados revocados respectivamente para cada caso
de uso.

\begin{figure}[htb]
\centering
%\includegraphics[width=8cm]{imagenes/casodeusoac.png}
\includegraphics[scale=1]{imagenes/casodeUsoAc.JPEG}
\caption{Caso de uso para el actor Administrador Autoridad de Certificación}
\label{fig:casodeusoac}
\end{figure}


También en esta etapa se construye  el modelo de datos de la aplicación. 
La figura \ref{fig:diagramadeclases} muestra de forma parcial, ya que no se incluyen 
los atributos,  el diagrama de clases que explica el modelo de datos. Se consideran 
como objetos persistentes del sistema a elementos como usuarios, clientes, 
certificados, autoridades o proveedores de certificación, solicitudes de autoridad de 
certificación, solicitudes de entidad finales, y sus respectivas relaciones.

\begin{figure}[htb]
\centering
%\includegraphics[width=8cm]{imagenes/diagramadeclases.png}
\includegraphics[scale=1]{imagenes/diagramadeClases.JPEG}
\caption{Diagrama de clases}
\label{fig:diagramadeclases}
\end{figure}


Para modelar la secuencia de acciones que se realizan para cada caso de uso se 
utilizan los diagramas de actividades. La figura \ref{fig:diagramaactividades} 
muestra el diagrama de actividades generales para el caso de uso  ``Emisión de 
certificados''' del actor Administrador del componente AC. Para este conjunto de 
actividades participan cuatro (4) actores: Administrador del PSC, quien entrega los 
recaudos necesarios para que se le firme su solicitud, el Administrador de la AR, 
quién es el encargado de chequear los recaudos entregados por el PSC, el Administrador 
de la AC Raíz  y el Administrador PUB, este último encargado de publicar en
los 
diferentes repositorios los certificados (claves públicas) para que sean visibles por 
el mayor número de usuarios interesados.  


\begin{figure}[htb]
\centering
%\includegraphics[width=8cm]{imagenes/diagramaactividades.png}
\includegraphics[scale=1]{imagenes/diagramadeActividades.JPEG}
\caption{Diagrama de actividades para el caso de uso ``Emisión de Cerificados``}
\label{fig:diagramaactividades}
\end{figure}
 

\subsection{Implementación}


En esta etapa se utilizan como insumo los diagramas de casos de uso, diagrama 
de clases y actividades, generados en la etapa de  diseño. Se traduce  el 
diagrama de clases al que se hace referencia en la figura \ref{fig:diagramaactividades} 
en un modelo de datos relacional, y se genera un guión SQL que genera el mapa de 
tablas relacional, donde las tablas representan relaciones tales como usuarios, 
clientes, certificados, y las demás entidades que conforman el modelo de datos.

Se utilizan y validan los diagramas de casos de uso mediante la elaboración de 
interfaces gráficas de usuarios y funcionalidades de interacción con el usuario. 
Los diagramas de actividades ayudan en el planteamiento de  algoritmos que proveen 
funcionalidades o características con las cuáles debe contar la aplicación y 
que deben estar en coordinación con los respuestas y valores esperados.


Haciendo uso de las ventajas que trae el uso de software libre, descritos en \ref{sec:softlibre}, 
se implementa la aplicación utilizando la mayor cantidad de líneas de códigos 
disponibles en los repositorios y proyectos de la comunidad, de tal manera que 
satisfagan los requisitos y funcionalidades planteadas en la etapa de diseño. 
En este sentido, se utiliza el código fuente del  proyecto XCA \cite{XCA:03}, 
desarrollado por Christian Hohnst\"{a}dt, que tiene como objetivo proveer  una
aplicación escrita  en el lenguaje de programación C++\cite{STRO:02} y la 
biblioteca Trolltech Qt\cite{BLAN:06}, que cumpla con el estándar X.509. La aplicación 
satisface los requisitos básicos para la gestión del componente de gestión de AC Raíz, 
esto es, los diagramas UML de la etapa de diseño calzan con un gran conjunto de requisitos 
satisfechos en el proyecto XCA, esto ocurre debido a que este trabajo comparte 
objetivos con dicho proyecto; por ejemplo, para el caso de uso de la figura \ref{fig:casodeusoac}, 
donde el actor debe ejecutar tres acciones: emitir, renovar y revocar certificados, 
la aplicación XCA incorpora estas tres actividades, pero se hace necesario adaptar 
la interfaz de usuario y agregar características en función de los requisitos capturados.

Es importante recalcar, que XCA no sastiface todos los requisitos documentados en la 
etapa de diseño. En respuesta a este hecho, se realiza un proceso de incorporación de 
funcionalidades. En este sentido, se agregan características a la aplicación acorde 
con la especificaciones de diseño, entre las cuáles se enumeran:
\begin{itemize}
 \item La incorporación de un sub-sistema de seguridad para acceso a los activos de 
 información que gestiona la aplicación,  que incluya aspectos de autenticación y 
 autorización de usuarios,  como lo es  la validación de credenciales a través del 
 uso de tarjetas inteligentes, el registro y firma electrónica de las acciones realizadas 
 por los usuarios dentro de la aplicación. 
En la figura \ref{fig:registro} se muestra la característica de registro de acciones. 
La ventana a la derecha muestra los detalles de la acción seleccionada en la lista, 
se incluyen datos importantes como nombre de la cuenta de usuario, fecha, hora, y 
otros datos particulares relacionadas con la acción realizada por el correspondiente 
usuario.

\begin{figure}[htb]
\centering
%\includegraphics[width=8cm]{imagenes/registro.png}
\includegraphics[scale=1]{imagenes/registro.JPEG}
\caption{Sistema de registro de acciones}
\label{fig:registro}
\end{figure}

\item  Estandarización del sistema de gestión de documentos  como solicitudes, 
plantillas de certificados y certificados.

\item Conexión a través de una interfaz propia con el hardware donde se resguardan 
las claves privadas (HSM).

\end{itemize}

También en esta etapa se seleccionan e integran las tecnologías a utilizar para 
la codificación y creación de la aplicación de gestión del componente AC Raíz.  
Los tipos de tecnologías que deben seleccionarse son: bibliotecas para construir 
la interfaz hombre-máquina (HMI por sus siglas en inglés), motor criptográfico,  conexiones con hardware, 
interfaces con repositorio de datos y algoritmos de cálculo
criptográfico más utilizados.


Como criptosistema se utiliza OpenSSL version 0.9.8 \cite{VIEG:2002}, que provee 
un conjunto de funciones criptográficas apegadas al estándar X.509. Para la 
construcción de interfaces hombre-máquina y uso de algoritmos generales se 
selecciona la biblioteca Qt. Como interfaz para el uso de tarjetas 
inteligentes se utilizo el estándar PKCS\#11, también conocido como Cryptoki, que 
especifica una forma para interactuar con este hardware criptográfico\cite{NIC:03}.



\subsection{Pruebas}

Esta etapa tiene dos objetivos.  El  primero consiste en asegurar que la 
aplicación funcione correctamente, es decir, que se generen la menor cantidad 
de salidas inesperadas o fallas a entradas dadas. En relación al logro de  este 
objetivo  se utilizan un conjunto de técnicas aplicadas  a lo largo del proceso 
de desarrollo, entre las cuáles se pueden citar la revisión en parejas \cite{PRESS:05}, 
que consiste en la programación se realice en equipo de dos programadores por 
computador, uno de ellos se encarga de escribir los algoritmos en un lenguaje 
de programación, y el segundo de ellos de revisarlo inmediatamente; después de 
periodo de unas horas establecido previamente, se intercambian 
los roles. Otra de las técnicas utilizadas que es importante nombrar son las 
pruebas unitarias \cite{PRESS:05}, las cuáles consisten en aplicar un número
de casos de pruebas a métodos o módulos pequeños de la aplicación (unidades), 
de tal manera que se asegura que funcionan correctamente de forma independiente. 
Seguidamente, se realizan pruebas de integración, que consisten en probar módulos
más complejos formados por las unidades revisadas en las pruebas unitarias. 
Las pruebas unitarias y de integración  presentan las ventajas que son
automatizables, 
y por lo tanto, se cuenta con herramientas de software para llevarlas a cabo.


El segundo objetivo, es que se satisfagan los requisitos  plasmados en la etapa 
de diseño, y que se extraen  de los diagramas UML , es decir, la aplicación 
debe cumplir con las características necesarias para resolver el problema de 
gestión de una AC Raíz. En este sentido, se toma una estrategia basada en 
prototipos con liberaciones periódicas, que permite a los usuarios y desarrolladores
de la comunidad  chequear el progreso en el proyecto. Los prototipos son 
chequeados por los usuarios y  la modificación de requisitos y notificación de 
errores son notificados en un sistema web de chequeo y seguimiento \cite{TRAC:07}.

También se habilita un sistema de control de versiones de licencia libre 
llamado subversion \cite{PILA:04}, que permite a los programadores involucrados 
en el proyecto obtener en todo momento y de forma local o remota la última 
versión de los programas fuentes.

Debido a que la aplicación de gestión de AC Raíz debe ser parte de una 
infraestructura, es necesario realizar pruebas en condiciones similares a la 
configuración final de ésta; por ello que se simula la configuración de
producción que 
conlleva pruebas con el sistema operativo y el lugar donde se instala la
aplicación, 
conexión con tarjetas inteligentes y el módulo de seguridad en hardware, 
controles de acceso físico  y lógico, y desconexión de red, ya que la autoridad 
debe operar fuera de línea.
 

\subsection{Despliegue y configuración}
El despliegue consiste en la instalación en condiciones reales de la 
aplicación de gestión de AC Raíz dentro de la infraestructura. La figura \ref{fig:arquitecturapsc} 
muestra una propuesta para el despliegue de la infraestructura. La aplicación se 
instala en un computador desconectado de red  que debe estar ubicado dentro de un 
lugar físico seguro,  lo que significa que el acceso a personas deber estar 
restringido por llaves y controles biométricos, y el flujo de información digital 
hacia adentro y afuera de la bóveda debe ser realizado a través de dispositivos 
de memoria secundaria con seguridad incorporada, tal como una memoria usb (pendrive)
con bloqueo por contraseña, como se muestra en la figura \ref{fig:arquitecturapsc}. 
También es necesario la habilitación de servidores para la validación de los períodos de vigencia de 
los certificados a través del protocolo de estado de certificado en línea (OCSP por sus siglas en inglés), 
y para la generación de solicitudes de firma de certificados, 
donde las entidades finales o usuarios consignan los recaudos.

\begin{figure}[htb]
\centering
%\includegraphics[width=8cm]{imagenes/arquitecturapsc.png}
\includegraphics[scale=1]{imagenes/arquitectura.JPEG}
\caption{Configuración de los componentes del nodo raíz de una ICP}
\label{fig:arquitecturapsc}
\end{figure}

Por otro lado, la configuración  conlleva el establecimiento de parámetros para 
el funcionamiento de la aplicación, tales como métodos de control y restricción
de 
acceso,  ubicación de archivos y directorios, rutas para importación y
exportación
de datos, perfiles de usuario, generación y nombres de claves, inicialización 
de tarjetas inteligentes, inicialización  de HSM, y copias de seguridad.

\section{Conclusiones}

La puesta en marcha de una AC Raíz supone obligatoriamente contar con una 
aplicación  que gestione este componente de la infraestructura. En este sentido, 
este trabajo mostró el proceso de desarrollo de una aplicación que respondiera 
a los requisitos particulares de gestión, determinados por el rol de confianza 
raíz que debe representar la Autoridad de Certificación. En función de ello, la 
aplicación tiene un alto grado de especialización, ya que cuenta con un  
mercado relativo de pocos usuarios, si se compara con el mercado de los sistemas
de información o aplicaciones de ofimática, y su operación se realiza en 
condiciones estándares y específicas. A pesar de este hecho, para la 
construcción de la aplicación se integraron varios proyectos disponibles en los
repositorios de software libre, lo que permitió disponer de un criptosistema 
estándar y suficientemente completo para cumplir con los requisitos descritos 
en la etapa de diseño. La criptografía se utiliza como herramienta para 
otorgar las tres propiedades (confidencialidad, integridad y disponibilidad) 
de la seguridad informática a los datos que gestiona la aplicación, y en virtud 
de ello el hardware criptográfico utilizado como las tarjetas inteligentes y 
el módulo de seguridad en hardware configuran un ``mundo seguro'' que cumple 
con los estándares aceptados a nivel mundial.  

En la etapa de diseño, los diagramas de casos de uso y actividades sirvieron 
para obtener una visión formal de los requisitos y de los procesos con los que 
la aplicación debe cumplir. Estos documentos de diseño  en el lenguaje UML,
permitieron 
alcanzar de manera más rápida y certera los objetivos que son coincidentes con la 
gestión real de una AC Raíz. 

Al seguir el estándar X.509 se asegura que los certificados, solicitudes y claves 
gestionados por la aplicación sean compatibles con el esquema de seguridad basado 
en un tercero de confianza, y aceptado por gran cantidad de aplicaciones y sitios 
de comercio electrónico y transacciones seguras en la Internet. 

Para la tarea de eliminación de fallas las técnicas como la colaboración utilizando 
herramientas web, la programación en equipos y las pruebas unitarias y de integración
sirvieron para los procesos de prevención, notificación, búsqueda y arreglo de 
errores, permitiendo además guardar una bitácora del progreso a la solución de 
problemas. La implementación de características específicas en función de los 
requisitos cada vez más refinados y particulares que surgieron en las iteraciones 
de prototipos probados con usuarios y condiciones reales.

La combinación de diversos elementos como software, hardware y la configuración de 
un espacio físico adecuado, esto es, que cumpla determinadas reglas para el 
control de acceso, conforma la infraestructura necesaria para la operación de 
una AC, incluso que ésta no sea Raíz, y sea parte de otro nodo de la jerarquía. 
Las condiciones de seguridad lógica y física pueden reproducirse exactamente para 
los nodos intermedios y los nodos Proveedores de Servicios de Certificación de la 
ICP, tomando en cuenta el escalamiento.   
 
%\appendices
\section{Glosario}
\label{ap:glosario}


\emph{AC}: Autoridad de Certificación; componente de la PKI encargada de guardar, 
de firmar, renovar, revocar las claves de los usuarios o entidades finales.

\emph{AR}: Autoridad de Registro; componente de la PKI encargada de validar los 
recaudos de un PSC o Entidad Final, es decir, su identidad, y generar la solicitud para una firma de Certificados.

\emph{Entidad Final}: Persona natural o jurídica  a la que un PSC le expide un 
certificado digital. 

\emph{PSC}:  Proveedor de Servicios de Certificación Digital; Organización que
mantiene la infraestructura de  nodo de una ICP, y está autorizada a expedir 
certificados a las personas naturales y jurídicas que soliciten y reunan los 
recaudos necesarios para obtener un certificado digital. 

\emph{PUB}: Publicador; componente de la PKI encargada de mantener accesibles 
los certificados digitales emitidos por la PKI en medios como
portales Web o directorios. 
 
\emph{PKI}: Public Key Infrastructure, Infraestructura de clave pública; es el 
conjunto formado por software, hardware, y políticas que asegura
en la internet la 
propiedad de la claves públicas de los usuarios.

\emph{HSM}: Hardware Security Module; módulo de seguridad en hardware, equipo físico 
computacional que contiene funciones criptográficas, en específico funciona para 
almacenar con un alto nivel de seguridad claves privadas.

%\bibliography{referenciasCapitulo5}
%\bibliographystyle{plain}


% bibliografia
% \begin{thebibliography}{}
% 
% \bibitem{NIC:03}
% R. Nichols and P. C. Lekkas, "Seguridad para comunicaciones inal{\'a}mbricas". McGraw-Hill, Mexico, 2003.
% 
% \bibitem{STAL:03}
% William Stallings, "Fundamentos de Seguridad de Redes. Aplicaciones y Est{\'a}ndares", Prentice Hall, España, 2003. 
% 
% \bibitem{NASH:02}
% Nash Duane and Joseph Brink, "PKI: Infraestructura de clave p{\'u}blica", McGraw-Hill,. Mexico, 2002.
% 
% \bibitem{ACE:03}
% Vicente Aceituno Canal, "Seguridad de la información", Noriega Editores, Mexico, 2003.
% 
% \bibitem{SCHM:03}
% Joseph Schmuller, "Aprendiendo UML en 24 horas", Prentice Hall, Mexico, 2003.
% 
% \bibitem{BOOC:99}
% G., Booch, "UML Lenguaje Unificado de Modelado", Addison Wesley, 1999.
% 
% 
% \bibitem{MULL:97}
% Alain Pierre-Muller, "Modelado de objetos con UML", Eyrolles, Barcelona, España, 1997.
% 
% 
% \bibitem{FSF:07}
% Free Software Definition, http://www.fsf.org/licensing/essays/free-sw.html, 2007.
% 
% 
% \bibitem{SARW:03} 
% Sarwar, Koretsky, "El libro de Linux", Pearson, Prentice Hall, Madrid, España, 2003.
% 
% \bibitem{KURT:01}
% Kurt Wall et al, "Programación en Linux", Prentice Hall, Madrid, España, 2001.
% 
% 
% \bibitem{XCA:03}
% Christian Hohnst\"{a}dt, XCA, una interfaz gr\'afica para OpenSSL, Clave p\'ublicas y privadas,
% certificados, solicitudes y listas de revocación. http://sourceforge.net/projects/xca/.
% 
% \bibitem{STRO:02}
% Bjarne Stroustrup, "El lenguaje de programación C++", Addison Wesley, Madrid, España, 2002.
% 
% \bibitem{BLAN:06}
% James Blanchette and Mark Summerfield, "C++ GUI Programming with Qt 4", Prentice Hall, Massachusetts, USA, 2006.
% 
% \bibitem{VIEG:2002}
% John Viega and Matt Messier and Pravir Chandra, "Network Security with OpenSSL", O'Really, 2002.
% 
% \bibitem{PRESS:05}
% Roger S. Pressman, "Ingenier'ia del software. Un enfoque práctico", Mc Graw-Hill, Mexico 2005.
% 
% \bibitem{TRAC:07}
% TRAC web-based software project management, http://trac.edgewall.org/, 2007.
% 
% \bibitem{PILA:04}
% C. Michael Pilato and Ben Collins-Sussman and Brian W. Fitzpatrick, "Version Control with Subversion ", O'Really, 2004.
% 
% 
% \end{thebibliography}


% el siguiente comando establece la ubicación de las referencias
\putbib[bibliografia]

% el siguiente comando cierra el ambiente bibunit para la cual se generan las
% referencias.
\end{bibunit}



% *****************************************************************************
% *****************************************************************************
% a partir de aquí se encuentra el contenido original del artículo de ROOTVE

% A continuación el contenido del artículo de ROOTVE
% 
% 
% %\begin{abstract}
% Una Autoridad de Certificación Raíz (AC Raíz) es un componente que tiene el rol de ser el 
% punto más alto de confianza en  una estructura  jerárquica denominada Infraestructura de Clave 
% Pública (ICP). Una ICP  provee de certificados digitales bajo estándar X.509 a personas, 
% direcciones IP y direcciones en la Web;  proporcionando seguridad lógica, y vinculación
% legal a las transacciones  que realiza el propietario  del certificado  en 
% la Internet. La confianza reside en la protección a través de esquemas fuertes de 
% seguridad física y lógica de la clave privada que permite la emisión de estos certificados. 
% Este trabajo muestra el proceso de desarrollo de una aplicación para gestionar el 
% componente mencionado utilizando  bibliotecas, herramientas, compiladores, 
% sistemas operativos y licencias compatibles con los principios del  software libre. 
% En primer lugar, se determinan los requisitos a ser satisfechos en función de una 
% descripción general de las funciones y características de una Autoridad de 
% Certificación;  posteriormente, se dise~nan  funcionalidades y  se especifican 
% requisitos, con el objetivo de producir  una visión formal de los procesos a 
% automatizar. Se dedica una sección a la implementación que  consiste, en la 
% codificación en un lenguaje de programación,   de los procesos previstos  en las 
% etapas anteriores, como también, de la incorporación de mecanismos fuertes de 
% validación de identidad de usuarios, registro de eventos, firma de acciones por parte 
% de los administradores de la aplicación, y especificación de conexiones con hardware 
% especializado, como tarjetas inteligentes.  Finalmente, se muestra el despliegue y 
% configuración de la aplicación, que involucra la instalación en un ambiente seguro 
% (bóveda o centro de datos) y el enlace de la AC Raíz con los demás componentes de la infraestructura.  
% 
% 
% %\end{abstract}
% 
% %\begin{abstract}
% A Certification Authority Root (CA Root) is a component which role is to represent the 
% highest confidence point in a hierarchical structure denominated Public Key Infrastructure (PKI). 
% A PKI provides people, IP addresses and Web domains with digital certificates under X.509 
% standard, offering logic security and legal entailment to transactions performed on the 
% internet by the certificate’s owner. Confidence resides in private key protection through 
% strong physical and logical security schemes, so these schemes allow the certificate emission. 
% This work shows the development process of a CA root management application. For this development 
% it's used libraries, tools, compilers, operating systems and licenses compatible with the 
% principles of free software. In first place, the requirements to satisfy are determined based 
% on a general description of a CA's functions and characteristics; subsequently, functionalities 
% are designed and requirements are specified in order to produce a formal vision of the 
%processes 
% to automate. A section is dedicated to the implementation, this consists on codification in a 
% programming language of the processes forseen in the previous stages, like also, 
% of the incorporation of strong mechanisms of validation of identity of users, 
% registry of events, actions signature by application's administrators, and 
% connections specification with specialized hardware, like smart cards. 
% Finally, application display and configuration are shown, it involves its 
% installation in a safe environment (vault or data center) and CA Root connection 
% with other components of the infrastructure.
% %\end{abstract}
% 
% %\begin{keywords} Infraestructura de Clave Pública, Estándar X.509, Certificado Digital, Firma Electrónica, Autoridad de Certificación Raíz.
% %\end{keywords}
% 
% 
% \section{Introducción}
% 
% \label{sec:intro}La disponibilidad de Internet como medio digital seguro permite 
% que cualquier persona, empresa, institución, o administración realice transacciones 
% gubernamentales, comerciales o personales en la mayoría de los casos, tal cual, 
% como se realizarían en una oficina o espacio físico de forma presencial. Dado este 
% hecho, al utilizar Internet para establecer relaciones humanas, se está de acuerdo 
% que es necesario trasladar el concepto de ``identidad'' al medio digital\cite{NIC:03}. 
% La criptografía provee algoritmos y mecanismos para construir este concepto 
% en la red, ya que es  posible utilizar herramientas  que aporten elementos para 
% definir la identidad de un usuario, entidad  o institución, de la misma forma de 
% la que se está familiarizado en el mundo real.
% 
% En muchas ocasiones para realizar actividades cotidianas personales o de trabajo, 
% se debe establecer contacto con un individuo u organización que no se conoce o del 
% cuál no se tiene ninguna referencia. Mediante un contacto personal o directo, los 
% sentidos humanos permiten percibir un gran número de detalles que le caracterizan, y 
% cuya combinación muy probablemente le hace irrepetible. Esta combinación  permite 
% identificar al individuo  de forma única y certera.  Dicho esto, la identidad se 
% define como el reconocimiento que se hace de las credenciales físicas o informativas, 
% que ese individuo  ofrece para que se le acepte como poseedor de una determinada 
% individualidad \cite{STAL:03}. Las credenciales físicas pueden ser documentos como 
% la Cédula de Identidad, el Pasaporte, la Licencia de Conducir, entre otros. Todos los 
% documentos citados  generalmente incluyen una fotografía que permite la comparación 
% con la apariencia del interlocutor; también usualmente se agrega otra característica 
% informativa que puede ser un nombre, una  firma manuscrita y posiblemente un número 
% de referencia.
% 
% Cuando se traslada el concepto de identidad al medio informático, se habla de 
% identidad digital, y se hace necesario contar credenciales traducibles a 
% información binaria. Por otro lado, la criptografía, por sí misma no proporciona este 
% concepto: es el uso de una infraestructura computacional que utiliza algoritmos 
% criptográficos  para representar credenciales digitales,  como por ejemplo el certificado 
% digital,  y que son otorgados por terceros de confianza, denominados Autoridades 
% de Certificación (AC), y que se describen como Raíz cuando son el punto inicial de una 
% jerarquía, las que proveen a usuarios y organizaciones de identidad digital, y que 
% cuenta con las mismas connotaciones que tiene este concepto en el ámbito personal 
% y jurídico.
% \\
% Uno de los problemas que aparece en este punto, en la disponibilidad de la 
% infraestructura mencionada anteriormente, la cuál debe contar como un elemento 
% obligatorio una aplicación que gestione, bajo un estándar aceptado, como lo es el 
% estándar X.509\cite{NASH:02}, los certificados digitales que emite la AC. 
% La discusión de importantes aspectos que surgen en las diferentes etapas del 
% proceso desarrollo de la aplicación de gestión, y que están vinculados con los 
% principios del software libre y los requisitos muy particulares del ambiente 
% de despliegue, subrayan los objetivos de este trabajo.
% 
% \section{Marco Teórico}
% 
% Con el objetivo de contextualizar los términos   ``identidad'', ``confianza'', o 
% ``transacción segura'' y``AC Raíz'' en el medio digital, y específicamente en 
% relación con internet; es imprescindible en una primera aproximación,  discutir sobre 
% determinados temas y conceptos vinculados con la seguridad informática. En los párrafos 
% siguientes se abordan brevemente algunos de los puntos más importantes relacionados con el tema. 
%  
% \subsection{Seguridad Informática}
% 
% Se ha llegado a un consenso sobre lo que significa seguridad informática\cite{STAL:03}. 
% En general, se dice que un activo de información, (información digital con un valor 
% real para una empresa o persona) está asegurado si cumple con niveles  aceptables 
% relativos a su valor potencial en los siguientes aspectos:
% \\ \\
% \textbf{Disponibilidad:} es el grado en que un dato está en el lugar, momento y 
% forma en que es requerido por uno o un conjunto de usuarios autorizados. Como 
% premisa, un sistema seguro debe mantener la información disponible para los 
% usuarios autorizados. Disponibilidad también significa que el sistema, debe 
% mantenerse funcionando eficientemente y es capaz de recuperarse rápidamente 
% en caso de fallo.
% \\ \\
% \textbf{Confidencialidad:} es el aspecto de la seguridad que permite mantener en 
% secreto la información y solo los usuarios autorizados pueden manipularla. 
% Igual que para la disponiblidad, los usuarios pueden ser personas, procesos o 
% programas. Para evitar que nadie no autorizado pueda tener acceso a la información 
% transferida y que recorre la Red se utilizan técnicas de cifrado o codificación de 
% datos. Hay que mantener una cierta coherencia para determinar cuál es el grado de 
% confidencialidad de la información que se está manejando, para así evitar un esfuerzo 
% suplementario a la hora de decodificar una información previamente codificada.
% \\ \\
% \textbf{Integridad:} corresponde a garantizar que la información transmitida entre dos 
% entidades autorizadas no sea modificada por un tercero no autorizado. Un mecanismo 
% para lograrlo es la utilización de firmas digitales.
% Mediante una firma digital se codifican los mensajes a transferir, de forma que una 
% función, denominada hash \cite{ACE:03}, calcula un resumen de dicho mensaje y se 
% le a~nade. La validación de la integridad del mensaje se realiza aplicándole al original la 
% misma función y comparando el resultado con el resumen que se a~nadió al final cuando 
% se calculo por primera vez antes de enviarlo.
% Mantener la integridad es importante para verificar que en el tiempo de viaje por 
% la Red de la información entre el sitio emisor y receptor ningún agente externo o 
% extra\~no ha modificado el mensaje.
% 
% \subsection{Criptografía}
% La criptografía  es la ciencia o arte  información utilizando técnicas matemáticas 
% que hagan posible el intercambio de mensajes de manera que sólo puedan ser leídos 
% por las personas o usuarios autorizados \cite{STAL:03}. La criptografía ha tomado 
% gran importancia en los últimos a~nos, ya que es posible transformar las 
% ``técnicas matemáticas'' en algoritmos que pueden ser comprendidos por una computadora.  
% Se puede clasificar la criptografía en dos tipos, según el tipo de clave que se utilice:
% 
% \textbf{Criptografía Simétrica:} los sistemas de criptografía simétrica son aquellos 
% que utilizan una única clave para cifrar y descifrar un texto claro. Este tipo de 
% sistema conlleva una desventaja, que consiste en el conocimiento de las partes 
% (emisor y receptor) de la  clave única que les permite intercambiar información 
% por un canal seguro. Como respuesta a ello, se hace necesario formalizar un procedimiento 
% que muestre a las partes autorizadas la información sobre la clave, sin que sea 
% develada a un tercero no autorizado.
% 
% \textbf{Criptografía Asimétrica:} también se conoce como  Sistema de Cifrado 
% de Clave Pública\cite{STAL:03}. Usa dos claves diferentes, una de ellas es la 
% Clave Pública que puede ser enviada a cualquier persona y otra, que se 
% denomina Clave Privada que es secreta, y no debe ser revelada. A diferencia del 
% sistema de cifrado simétrico donde las partes deben concertar un procedimiento 
% para conocer la clave única, en este tipo de sistema el remitente usa la clave 
% pública del dest inatario para cifrar el documento. Una vez que el documento o 
% mensaje ha sido cifrado, solamente con la clave privada del destinatario el 
% mensaje puede ser descifrado. 
% 
% \subsection{Certificados digitales}
% 
% Un certificado digital es un documento de acreditación que permite a las partes 
% tener confianza en las transacciones que realicen en internet. Por tanto, 
% garantiza la identidad de su poseedor mediante un sistema de claves administrado 
% por una tercera parte de confianza. Para validar un certificado basta con conocer 
% la clave pública de la tercera parte conocida como la Autoridad de Confianza (AC). 
% Para cuidarnos de que piratas informáticos cambien su clave pública por la de la 
% autoridad de confianza, la AC debe crear un certificado con su propia información de 
% identidad y a la vez su clave pública y firmar el certificado, este certificado se le 
% conoce como certificado autofirmado.
% Dado que los certificados son información pública y lo que se desea es que todos 
% tengan acceso a ellos, pueden hacerse copias del certificado de acuerdo sea necesario. 
% Los certificados digitales permiten varias cosas, entre ellas se pueden citar que los 
% usuarios pueden a~nadir firmas electrónicas a los formularios en línea; que los 
% destinatarios pueden comprobar la autenticidad del correo electrónico confidencial; 
% que los compradores pueden estar seguros de que un website es legítimo; y por último, 
% controla el acceso a bancos y comercios online, así como los intranets y extranets.
% 
% \subsection{Estándar X.509}
% 
% 
% X.509 y X.500 fueron originalmente dise\~nados a mediados de los a\~nos 80, antes 
% del enorme crecimiento de usuarios en Internet. Es por esto por lo que se 
% dise\~naron para operar en un ambiente donde sólo los computadores se interconectaban 
% intermitentemente entre ellos. En las versiones  1 y 2 de X.509 se utiliza una 
% lista estandarizada denominada ``CRL'' (Certificate Revocation List) que contiene la 
% información referente a  clientes o certificados que han sido revocados. 
% 
% La versión 3 introduce cambios significativos en el estándar. El cambio fundamental 
% es el hacer el formato de los certificados y los CRLs extensible. Ahora los que 
% implementen X.509 pueden definir el contenido de los certificados como crean 
% conveniente. Además se han definido extensiones estándares para proveer una 
% funcionalidad mejorada.
% 
% 
% Con la utilización de la tecnología de certificados digitales se provee a los 
% clientes (personas o programas) de un nivel más alto en los procesos de 
% autenticación y autorización, ya que se le otorga al cliente algo que puede poseer, 
% incluso incluir dentro de elemento físico, como una tarjeta inteligente. 
% Los certificados en el formato X.509 v3 contienen datos del sujeto, 
% como su nombre, dirección, correo electrónico, etc. (Ver Fig. \ref{fig:estandarx509})
% 
% En la versión 3 de X.509, no hace falta aplicar restricciones sobre la estructura 
% del certificado, gracias a la definición de las extensiones de certificados. 
% Se permite que una organización pueda definir sus propias extensiones para 
% contener información específica dentro de su entorno de operación. 
% Este tipo de certificados es el que usa el protocolo de comercio electrónico 
% SET (del inglés Secure Electronic Transaction, Transacción Electrónica Segura) \cite{IBM:98}.
% 
% \begin{figure}[htb]
% \centering
% \includegraphics[width=8cm]{imagenes/estandarX509.png}
% \caption{Especificación del estandar X.509}
% \label{fig:estandarx509}
% \end{figure}
% 
% 
% Los certificados digitales tienen multitud de usos, entre los tipos de certificados 
% más utilizados están:
% 
% \begin{itemize}
%  \item \textbf{Certificado de Servidor SSL (del inglés Socket Secure Layer, Nivel de Conexión Segura):} 
%  Permite incorporar el protocolo SSL a un servidor web con el objetivo que 
%  toda la comunicación entre el cliente y el servidor permanezca segura, 
%  cifrando la información que envía cada parte. El certificado del servidor posibilita 
%  la autenticación fuerte, es decir, que el servidor puede exigir certificados 
%  personales de navegación a los usuarios para acceder a determinadas carpetas, 
%  lo que repercute en la seguridad y en la comodidad por la ausencia de cuentas 
%  y contrase\~nas para la identificación de los usuarios.
% 
%  \item \textbf{Certificados personales (Correo y navegación):} Un certificado digital 
%  personal es la herramienta necesaria para navegar, comprar y enviar/recibir correo 
%  a través de Internet, de una manera segura. Con el uso de este certificado se puede 
%  firmar o cifrar los mensajes  de correo para tener la seguridad que el receptor será 
%  el único lector de nuestro mensaje. Se puede aumentar la seguridad y confianza entre el 
%  cliente y el servidor web, al autenticarse también al usuario, esto también va a permitir 
%  a las empresas la posibilidad de personalizar los contenidos a un usuario concreto, 
%  con la certeza que otros usuarios no podrán ver dicho contenido, tales como información 
%  confidencial, ofertas especiales, entre otros.
% 
%  \item \textbf{Certificado para firma de código:} El certificado para la firma de 
%  código permite a un administrador, desarrollador o empresa de software firmar su 
%  software y macros, y distribuirlo de una forma segura. Esta solución de Seguridad es el 
%  requisito mínimo que necesitan nuestros clientes o lista de correo, para confiar y 
%  tener la seguridad de que el fichero que reciben o se descargan, proviene exclusivamente 
%  de una empresa determinada. Con ello se evitan los problemas causados por la 
%  suplantación de personalidad y la distribución de objetos da\~ninos o perjudiciales 
%  bajo esta supuesta identidad. Cualquier modificación (por ejemplo: inclusión de un 
%  troyano o infección de un virus) sobre el software original lo invalidará, con lo que el 
%  usuario tendrá la confirmación para rechazarlo al comprobar que la firma electrónica 
%  no corresponde con la del software modificado.    
% \end{itemize}
% \subsection{Lenguaje Unificado de Modelado}
% 
%  UML ( del inglés Unified Modeling Language,  Lenguaje de Modelado Unificado) es un lenguaje 
%  que permite diseñar sistemas a través de  modelos, que se componen de un conjunto 
%  de símbolos y diagramas en donde se plasma las ideas de funcionalidad. 
%  El UML fue creado por Grady Booch, James Rumbaugh e Ivar Jacobson en el a~no 
%  1997\cite{SCHM:03},\cite{BOOC:99} y \cite{MULL:97}. Cada diagrama tiene fines distintos 
%  dentro del proceso de desarrollo, su finalidad es presentar diversas perspectivas 
%  de un sistema. La clave está en organizar el proceso de dise~no de tal forma que los analistas, 
%  clientes, desarrolladores y otras personas involucradas en el desarrollo del modelo 
%  lo comprendan y convengan con él. Los diagramas que componen el lenguaje son:
% 
% \begin{itemize}
%  \item Diagramas de casos de uso
% \item Diagramas de estados
% \item Diagramas de secuencias
% \item Diagramas de colaboraciones
% \item Diagramas de distribución
% \item Diagramas de actividades
% \item Diagramas de componentes
% \item Diagrama de despliegue
% \end{itemize}
% 
% En este trabajo se utilizaron esencialmente los diagramas de clases, los diagramas de 
% casos de uso y los diagramas de actividades, que se describen brevemente a continuación:
% 
% \textbf{Diagramas de clases:} son representaciones gráficas de las categorías en que 
% pueden clasificarse los objetos del mundo real. En general, se hace una descripción 
% de las categorías que se utilizan en la aplicación a desarrollar. Los clases se 
% dise~nan  en funcion de sus atributos y relaciones con otras clases.
% 
% \textbf{Diagramas de casos de uso:}   son descripciones de las acciones que debe 
% realizar el usuario en el sistema \cite{SCHM:03}. Por ejemplo: Usuario que tiene la 
% necesidad de expedir un certificado digital a una AC de confianza.
% 
% 
% \textbf{Diagramas de actividades:}  muestran el flujo de actividades que ocurren 
% dentro de un caso de uso o dentro de un comportamiento de un objeto\cite{SCHM:03}. 
% Por ejemplo, las actividades que se realizan para expedir un certificado digital.
% 
% \subsection{Software Libre}
% 
% \label{sec:softlibre}El software libre \cite{FSF:07} es un asunto de libertad, 
% no de precio. Para que un programa, aplicación o conjunto concreto se 
% considere ``software libre'' debe cumplir con las siguientes libertades: 
% 1) Libertad de ejecutar el programa en cualquier sitio, cualquier propósito, 
% por siempre; 2) Libertad de estudiarlo y adaptarlo a nuestras necesidades; 
% 3) Libertad de redistribuirlo a cualquiera, logrando ayudar a un amigo o vecino; 
% y por último 4)la  Libertad de mejorar el programa y publicar las mejoras.
% 
% Las libertades antes expuestas, proveen  muchos beneficios  a los usuarios finales. 
% En particular, en el área de seguridad informática. Se pueden nombrar  entre los 
% beneficios más importantes: la no dependencia  de un único fabricante, y la posibilidad 
% de realizar auditorías y pruebas exhaustivas por parte de terceros, que pueden 
% ser personas, empresas o instituciones diferentes responsables del proyecto 
% de software. Los procesos de adaptación, mantenimiento, integración y auditorías 
% son más transparentes y colaborativos.
% 
% 
% \section{Infraestructura de Clave Pública}
% 
% Uno de los problemas del despliegue de la tecnologías basada en certificados y 
% firmas digitales, es contar con un elemento que proporcione una relación 
% fuerte de confianza entre dos o más sujetos que desean realizar una operación o 
% transacción utilizando como medio Internet. Es por ello,  que se recurre a 
% establecer un tercero de confianza, que se define, como un actor encargado de 
% brindar confianza basada en la disponibilidad de una infraestructura robusta que 
% incluya el uso tecnologías basadas en algoritmos criptográficos estandarizados, 
% y la aplicación estricta de políticas para los procesos de registro, publicación, 
% firma, renovación y revocación de certificados. 
% El tercero de confianza se denomina Infraestructura de Clave Pública (ICP)\cite{NASH:02}, 
% y consiste en la combinación de hardware y software, políticas y procedimientos 
% que permiten asegurar la identidad de los participantes en un intercambio de datos 
% usando criptografía pública. Una ICP debe proporcionar los tres conceptos de 
% seguridad mencionados anteriormente.
% 
% \subsection{Componentes de la Infraestructura de Claves Pública (ICP)}
% Los componentes habituales que conforman la infraestructura  son los siguientes 
% (Ver Fig. \ref{fig:arquitecturapsc}):
% \begin{itemize}
% \item Autoridad de Registro (AR): es el nodo o conjunto de nodos responsables 
% del registro y la autenticación inicial de los usuarios a quiénes 
% se les expide un certificado, después de  aprobada una solicitud de registro.
% \item  Autoridad de Certificación (AC): es el nodo central de la infraestructura, 
% se encarga de los procedimientos  de firma, renovación  y revocación de 
% certificados digitales. El procedimiento de firma  de certificados utiliza 
% la clave privada de la AC.
% \item Interfaz con los clientes (PUB): es el nodo  que brinda toda la información 
% a las entidades finales (usuarios) sobre el estado de su certificado, además de 
% ofrecer una información general al público en general sobre los aspectos y servicios 
% relevantes de la ICP.
% \end{itemize}
% 
% 
% Los nodos de una ICP pueden ordenarse según diversos modelos.  El más utilizado es 
% el modelo jerárquico, que presenta una raíz y nodos hijos que distribuyen los 
% certificados a los clientes o entidades finales (Ver Fig. \ref{fig:jerarquia}). 
% Se muestra un ejemplo de modelo de jerarquía de una ICP de cuatro niveles, 
% que se encuentra en el tercer nivel del modelo, que certifica a los usuarios.
% 
% \begin{figure}[htb]
% \centering
% \includegraphics[width=8cm]{imagenes/jerarquia.png}
% \caption{Modelo jerárquico de una ICP}
% \label{fig:jerarquia}
% \end{figure}
% 
% Este modelo de establecimiento de relaciones de confianza, es necesaria entre 
% múltiples autoridades de certificación para garantizar que los usuarios 
% (entidades finales) no tengan que depender y confiar en una sola AC, algo que haría 
% imposible el manejo de estabilidad, administración y protección. El objetivo 
% es que las entidades finales que utilizan identidades creadas por una AC puedan 
% confiar en ellas, aunque dichas partes tenga una autoridad expedidora diferente.   
% 
% 
% 
% \section{Desarrollo de la aplicación}
% 
% En los párrafos siguientes se discute  los aspectos, procesos y  técnicas 
% principales, que se siguen a lo largo del desarrollo de la aplicación (software) 
% de gestión del componente Autoridad Certificadora Raíz.
% 
% 
% \subsection{Conceptualización}
% 
% 
% Uno de los objetivos de esta etapa es determinar el rol  del componente AC Raíz 
% en la ICP, con la finalidad de obtener los requisitos, procesos y funciones que 
% deben ser implementados por el software. Este rol tiene que ver con la definición 
% de la AC Raíz como elemento central y de máximo resguardo de la infraestructura, 
% ya que este nodo inicial o ``Raíz'' contiene la clave privada que valida todos los 
% certificados de los otros nodos de la jerarquía. 
% 
% Se considera como punto importante en esta etapa, distinguir las diferencias entre 
% una AC Raíz y una AC de un Proveedor de Servicios de Certificación (PSC). La diferencia 
% principal entre estos dos tipos de AC, es la cantidad de certificados que deben gestionar 
% (firmar, renovar, revocar, etc) , en un determinado periodo cada uno de ellos. Esto es, una 
% AC Raíz solo gestiona un número mínimo de certificados,  los cuáles sirven para dar inicio a 
% la jerarquía (certificados otorgados a los PSC), por el contrario, una AC de un PSC debe 
% gestionar un número mucho mayor de certificados, ya que la función de este  nodo es 
% entregar certificados  periódicamente a usuarios, también llamados entidades finales.
% 
% La diferencia de  escala de los dos tipos de AC conlleva a que la AC Raíz tenga 
% características particulares, que tienen que ver los niveles y elementos de seguridad
% tanto físicos como lógicos que deben considerarse en la gestión del componente. 
% Por ejemplo, la desconexión de red del equipo  donde se ejecuta la aplicación de 
% gestión hace que la recepción y entrega de certificados se realice a través de 
% unidades de memoria externas y portátiles, debidamente validadas, con las cuáles 
% el software debe mantener una comunicación segura.
% 
% La conexión  de la aplicación con  hardware especializado, como el almacenador 
% y generador de claves públicas/privadas (Hardware Security Module: HSM) o las 
% tarjetas inteligentes, es un factor que debe considerarse en el momento de enumerar 
% las funciones iniciales del software de gestión.   
% 
% La selección del sistema operativo Linux\cite{SARW:03}  para desplegar la aplicación, 
% ya que cumple con los principios del software libre, y cuenta con gran número de 
% herramientas en el área de programación \cite{KURT:01}, es un requisito no funcional 
% que se establece en esta etapa.
% 
% Considerando los aspectos nombrados anteriormente, en este punto se elabora una lista 
% inicial de requisitos, con la cual debe cumplir la aplicación.  Como técnicas utilizadas 
% en ésta etapa  están la realización de entrevistas a clientes, a posibles administradores 
% y operadores; la elaboración de tablas comparativas entre diferentes aplicaciones que 
% existen en las bibliotecas o portales de software libre, con la finalidad de evaluar las 
% herramientas a utilizar en la elaboración de la aplicación. 
% 
% 
% \subsection{Dise\~no}
% 
% La etapa de dise\~no consiste en elaborar diagramas formales que permitan en la etapa 
% de implementación representar requisitos y procesos de la gestión del componente AC Raíz 
% en un lenguaje de programación.  Para el dise\~no de requisitos se utilizan los diagramas 
% de casos de uso del lenguaje UML, que muestran una primera aproximación las operaciones 
% que se deben realizar en relación con las entradas dadas por los usuarios. Los actores 
% (usuarios) del caso de uso principal que se muestra en la Fig. \ref{fig:casodeusoprincipal} 
% son: el Administrador del componente AC, el Administrador del Componente AR, el Administrador 
% del componente PUB, y el actor PSC, quiénes son los que interactúan con la aplicación.
% 
% \begin{figure}[htb]
% \centering
% \includegraphics[width=8cm]{imagenes/casodeusogeneral.png}
% \caption{Caso de uso principal}
% \label{fig:casodeusoprincipal}
% \end{figure}
% 
% Para el resto de la especificación de requisitos se elaboran casos de uso que modelan 
% las funcionalidades con que debe contar la aplicación. Para cada actor, se especifican 
% el correspondiente diagrama de caso de uso. En la Fig. \ref{fig:casodeusoac} se 
% muestra el caso de uso para el actor del componente AC. Las acciones que realiza 
% este actor son emisión, renovación y revocación de certificados, que conlleva procesos 
% de firma con la clave privada, modificación de los periodos de vigencia del certificado 
% y elaboración de listas de certificados revocados respectivamente para casa caso de uso.
% 
% \begin{figure}[htb]
% \centering
% \includegraphics[width=8cm]{imagenes/casodeusoac.png}
% \caption{Caso de uso para el actor Administrador Autoridad de Certificación}
% \label{fig:casodeusoac}
% \end{figure}
% 
% 
% También en esta etapa se construye  el modelo de datos de la aplicación. 
% La Fig. \ref{fig:diagramadeclases} muestra de forma parcial, ya que no se incluyen 
% los atributos,  el diagrama de clases que explica el modelo de datos. Se consideran 
% como objetos persistentes del sistema a elementos como usuarios, clientes, 
% certificados, autoridades o proveedores de certificación, solicitudes de autoridad de 
% certificación, solicitudes de entidad finales, y sus respectivas relaciones.
% 
% \begin{figure}[htb]
% \centering
% \includegraphics[width=8cm]{imagenes/diagramadeclases.png}
% \caption{Diagrama de clases}
% \label{fig:diagramadeclases}
% \end{figure}
% 
% 
% Para modelar la secuencia de acciones que se realizan para cada caso de uso se 
% utilizan los diagramas de actividades. La Fig. \ref{fig:diagramaactividades} 
% muestra el diagrama de actividades general para el caso de uso  ``Emisión de 
% certificados''' del actor Administrador del componente AC. Para este conjunto de 
% actividades participan cuatro (4) actores: Administrador del PSC, quién entrega los 
% recaudos necesarios para que se le firme su solicitud, el Administrador de la AR, 
% quién es el encargado de chequear los recaudos entregados por el PSC, el Administrador 
% de la AC Raíz  y el Administrador PUB, este último encargado de de publicar en los 
% diferentes repositorios los certificados (claves públicas) para que sean visibles por 
% el mayor número de usuarios interesados.  
% 
% 
% \begin{figure}[htb]
% \centering
% \includegraphics[width=8cm]{imagenes/diagramaactividades.png}
% \caption{Diagrama de actividades}
% \label{fig:diagramaactividades}
% \end{figure}
%  
% 
% \subsection{Implementación}
% 
% 
% En esta etapa se utiliza como insumo  los diagramas de casos de uso, diagrama 
% de clases y actividades,  generados en la etapa de  dise~no. Se traduce  el 
% diagrama de clases al que se hace referencia en la Fig. \ref{fig:diagramaactividades} 
% en un modelo de datos relacional, y se genera un script SQL que genera el mapa de 
% tablas relacional, donde las tablas representan relaciones tales como usuarios, 
% clientes, certificados, y las demás entidades que conforman el modelo de datos.
% 
% Se  utilizan y validan los diagramas de casos de uso mediante la elaboración de 
% interfaces gráficas de usuarios y funcionalidades de interacción con el usuario. 
% Los diagramas de actividades ayudan en el planteamiento de  algoritmos que proveen 
% funcionalidades o características con las cuáles debe contar la aplicación y 
% que deben estar en coordinación con los respuestas y valores esperados.
% 
% 
% Haciendo uso de las ventajas que trae el uso de software libre (Sección \ref{sec:softlibre}), 
% se implementa la aplicación utilizando la mayor cantidad de líneas de códigos 
% disponibles en los repositorios y proyectos de la comunidad, de tal manera que 
% satisfagan los requisitos y funcionalidades planteadas en la etapa de dise~no. 
% En este sentido, se utiliza el código fuente del  proyecto XCA \cite{XCA:03}, 
% desarrollado por Christian Hohnst\"{a}dt,  que tiene como objetivo proveer  una
% aplicación escrita  en el lenguaje de programación C++\cite{STRO:02} y la 
% biblioteca Trolltech Qt\cite{BLAN:06}, que cumpla con el estándar X.509. La aplicación 
% satisface los requisitos básicos para la gestión del componente de gestión de AC Raíz, 
% esto es, los diagramas UML de la etapa de dise~no calzan con un gran conjunto de requisitos 
% satisfechos en el proyecto XCA, esto ocurre debido a que este trabajo comparte 
% objetivos con dicho proyecto; por ejemplo, para el caso de uso de la Fig. \ref{fig:casodeusoac}, 
% donde el actor debe ejecutar tres acciones: emitir, renovar y revocar certificados, 
% la aplicación XCA incorpora estas tres actividades, pero se hace necesario adaptar 
% la interfaz de usuario y agregar características en función de los requisitos capturados.
% 
% Es importante recalcar, que XCA no sastiface todos los requisitos documentados en la 
% etapa de dise~no. En respuesta a este hecho, se realiza un proceso de completación de 
% funcionalidades. En este sentido, se incorporan características a la aplicación acorde 
% con la especificaciones de dise~no,  entre las cuáles se enumeran:
% \begin{itemize}
%  \item La incorporación de un sub-sistema de seguridad para acceso a los activos de 
%  información que gestiona la aplicación,  que incluya aspectos de autenticación y 
%  autorización de usuarios,  como lo es  la validación de credenciales a través del 
%  uso de tarjetas inteligentes, el registro y firma digital  de las acciones realizadas 
%  por los usuarios dentro de la aplicación. 
% En La fig \ref{fig:registro} se muestra la característica de registro de acciones. 
% La ventana a la derecha muestra los detalles de la acción seleccionada en la lista, 
% se incluyen datos importantes como nombre de la cuenta de usuario, fecha, hora, y 
% otros datos particulares relacionadas con la acción realizada por el correspondiente 
% usuario.
% 
% \begin{figure}[htb]
% \centering
% \includegraphics[width=8cm]{imagenes/registro.png}
% \caption{Sistema de registro de acciones}
% \label{fig:registro}
% \end{figure}
% 
% \item  Estandarización del sistema de gestión de documentos  como solicitudes, 
% plantillas de certificados y certificados.
% 
% \item Conexión a través de una interfaz propia con el hardware donde se resguardan 
% las claves privadas (HSM).
% 
% \end{itemize}
% 
% También en esta etapa se seleccionan e integran las tecnologías a utilizar para 
% la codificación y creación de la aplicación de gestión del componente AC Raíz.  
% Los tipos de tecnologías que deben seleccionarse son: bibliotecas para construir 
% la interfaz hombre-máquina (HMI), motor criptográfico,  conexiones con hardware, 
% interfaces con repositorio de datos y algoritmos de cálculo criptográfico más utilizados.
% 
% 
% Como criptosistema se utiliza OpenSSL version 0.9.8 \cite{VIEG:2002}, que provee 
% de un conjunto de  funciones criptográficas apegadas al estándar X.509. . Para la 
% construcción de interfaces hombre-máquina y  uso de algoritmos generales se 
% selecciona la biblioteca Trolltech Qt. Como  interfaz para el uso de tarjetas 
% inteligentes se utilizo el estándar PKCS11, también conocido como Cryptoki, que 
% especifica una forma para interactuar con este hardware criptográfico\cite{NIC:03}.
% 
% 
% 
% \subsection{Pruebas}
% 
% Esta etapa tiene dos objetivos.  El  primero de consiste en asegurar que la 
% aplicación funcione correctamente, es decir, que se generen la menor cantidad 
% de salidas inesperadas o fallas a entradas dadas. En relación al logro de  este 
% objetivo  se utilizan un conjunto de técnicas aplicadas  a lo largo del proceso 
% de desarrollo, entre las cuáles se pueden citar la revisión en parejas\cite{PRESS:05}, 
% que consiste que la programación se realice en equipo de dos programadores por 
% computador, uno de ellos se encarga de escribir los algoritmos en un lenguaje 
% de programación, y el segundo de ellos de revisarlo inmediatamente, después de 
% periodo de unas horas, que debe ser definido con anticipación, se intercambian 
% los roles. Otra de las técnicas utilizadas que es importante nombrar son las 
% pruebas unitarias\cite{PRESS:05}, las cuáles consisten en aplicar un número 
% casos de pruebas a métodos o módulos peque~nos   de la aplicación (unidades), 
% de tal manera que se asegura que funcionan correctamente de forma independiente. 
% Seguidamente, se realizan pruebas de integración, que consisten en probar módulos
% más complejos formados por las unidades revisadas en las pruebas unitarias. 
% Las pruebas unitarias y de integración  presentan la ventajas que son automatizables, 
% y por lo tanto, se cuenta como herramientas de software para llevarlas a cabo.
% 
% 
% El segundo objetivo, es que se satisfagan los requisitos  plasmados en la etapa 
% de dise~no, y que se extraen  de los diagramas UML , es decir, la aplicación 
% debe cumplir con las características necesarias para resolver el problema de 
% gestión de una AC Raíz. En este sentido, se toma una estrategia basada en 
% prototipos con liberaciones periódicas, que permite a los usuarios y desarrolladores
% de la comunidad  chequear el progreso en el proyecto. Los prototipos son 
% chequeados por los usuarios y  la modificación de requisitos y notificación de 
% errores son notificados en un sistema web de chequeo y seguimiento \cite{TRAC:07}.
% 
% También se habilita un sistema de control de versiones de licencia libre 
% llamado subversion \cite{PILA:04}, que permite a los programadores involucrados 
% en el proyecto obtener en todo momento y de forma local o remota la última 
% versión de los programas fuentes.
% 
% Debido a que la aplicación de gestión de AC Raiz debe ser parte de una 
% infraestructura, es necesario realizar pruebas en condiciones similares a la 
% configuración final de ésta; por ello se simula la configuración de producción que 
% conlleva pruebas con el sistema operativo y el donde se instala la aplicación, 
% conexión con tarjetas inteligentes y el módulo de seguridad en hardware, 
% controles de acceso físico  y lógico, y desconexión de red, ya que la autoridad 
% debe operar fuera de línea.
%  
% 
% \subsection{Despliegue y configuración}
% El despliegue consiste en la instalación en condiciones reales de la 
% aplicación de gestión de AC Raíz dentro de la infraestructura. La figura \ref{fig:arquitecturapsc} 
% muestra una propuesta para el despliegue de la infraestructura. La aplicación se 
% instala en un computador desconectado de red  que debe estar ubicado dentro de un 
% lugar físico seguro,  lo que significa que el acceso a personas deber estar 
% restringido por llaves y controles biométricos, y el flujo de información digital 
% hacia adentro y afuera de la bóveda debe ser realizado a través de dispositivos 
% de memoria secundaria con seguridad incorporada, tal como un lapiz usb (pendrive)
% con bloqueo por contrase~na, como se muestra en la figura.  También es necesario 
% la habilitación de servidores para la validación de los periodos de vigencia de 
% los certificados (OSCP), y para la generación de solicitudes de firma de certificados, 
% donde las entidades finales o usuarios consignan los recaudos.
% 
% \begin{figure}[htb]
% \centering
% \includegraphics[width=8cm]{imagenes/arquitecturapsc.png}
% \caption{Configuración de los componentes del nodo raíz de una ICP}
% \label{fig:arquitecturapsc}
% \end{figure}
% 
% Por otro lado, la configuración  conlleva el establecimiento de parámetros para 
% el funcionamiento la aplicación, tales como métodos de control y restricción de 
% acceso,  ubicación de archivos y directorios, rutas para importación e exportación
% de datos, perfiles de usuario, generación y nombres de claves, inicialización 
% de tarjetas inteligentes, inicialización  de HSM, y copias de seguridad.
% 
% \section{Conclusiones}
% 
% La puesta en marcha de una AC Raíz supone obligatoriamente contar con una 
% aplicación  que gestione este componente de la infraestructura. En este sentido, 
% éste trabajo mostró el proceso de desarrollo de una aplicación que respondiera 
% a los requisitos particulares de gestión, determinados por el rol de  confianza 
% raíz y última que debe representar la Autoridad.  En función de ello, la 
% aplicación tiene  un alto grado de especialización, ya que   cuenta con un  
% mercado relativo de pocos usuarios, si se compara con el mercado de los sistemas
% de información o aplicaciones de ofimática, y su operación se realiza en 
% condiciones estandándares y específicas.  A pesar de este hecho, para la 
% construcción de la aplicación se integraron varios proyectos disponibles en los
% repositorios de software libre, que permitió disponer de un criptosistema 
% estándar y suficientemente completo para cumplir con los requisitos descritos 
% en la etapa de dise~no.  La criptografía se utiliza como herramienta para 
% otorgar las tres propiedades (Confidencialidad, Integridad y Disponibilidad) 
% de la seguridad informática a los datos que gestiona la aplicación, y en virtud 
% de ello el hardware criptográfico utilizado como las  tarjetas inteligentes y 
% el módulo de seguridad en hardware configuran un ``mundo seguro'' que cumple 
% con los estándares aceptados a nivel mundial.  
% 
% En la etapa de dise~no, los diagramas de casos de uso y actividades sirvieron 
% para obtener una visión formal de los requisitos y de los procesos con los que 
% cumplir la aplicación. Estos documentos de dise~no  en el lenguaje UML, permitieron 
% alcanzar de manera más rápida y certera los objetivos que son coincidentes con la 
% gestión real de una AC Raíz. 
% 
% Al seguir el estándar X.509 se asegura que los certificados, solicitudes y claves 
% gestionados por la aplicación sean compatibles con el esquema de seguridad basado 
% en un tercero de confianza, y aceptado por gran cantidad de aplicaciones y sitios 
% de comercio y transacciones seguras en internet. 
% 
% Para la tarea de  eliminación de fallas las técnicas como la colaboración utilizando 
% herramientas web, la programación en equipos y  las pruebas unitarias y de integración
% sirvieron  para los procesos de prevención, notificación, búsqueda y arreglo de 
% errores, permitiendo además guardar una bitácora del progreso a la solución a 
% problemas. La implementación de características específicas en función de los 
% requisitos cada vez más refinados y particulares que surgieron  en las iteraciones 
% de prototipos probados con usuarios y condiciones reales.
% 
% La combinación de diversos elementos como software, hardware y la configuración de 
% un espacio físico adecuado, esto es, que cumpla determinadas reglas para el 
% control de acceso, conforma la infraestructura necesaria para la operación de 
% una AC, incluso que ésta no sea Raíz,  y sea parte de otro nodo de la jerarquía. 
% Las condiciones de seguridad lógica y física pueden reproducirse exactamente para 
% los nodos intermedios y los nodos Proveedores de Servicios de Certificación de la 
% ICP, tomando en cuenta el escalamiento.   
%  
% %\appendices
% \section{Glosario}
% \label{ap:glosario}
% 
% 
% \emph{AC}: Autoridad de Certificación; componente de la PKI encargada de guardar 
% de firmar, renovar, revocar las claves de los usuarios o entidades finales.
% 
% \emph{AR}: Autoridad de Registro; componente de la PKI encargada de validar los 
% recaudos de un PSC o Entidad Final, es decir, su identidad, y generar la solicitud para una firma de Certificados.
% 
% \emph{Entidad Final}: Persona natural o jurídica  a la que un PSC le expide un 
% certificado digital. 
% 
% \emph{PSC}:  Proveedor de Servicios de Certificación Digital; Organización que
% mantiene la infraestructura de  nodo de una ICP, y está autorizada a expedir 
% certificados a las personas naturales y jurídicas que soliciten y reunan los 
% recaudos necesarios para obtener un certificado digital. 
% 
% \emph{PUB}: Publicador; componente de la PKI encargada de mantener accesibles 
% los certificados digitales emitidos por la PKI en medios como portales Web o directorios. 
%  
% \emph{PKI}: Public Key Infrastructure, Infraestructura de clave pública; es el 
% conjunto formado por software, hardware, y políticas que asegura en la internet la 
% propiedad de la claves públicas de los usuarios.
% 
% \emph{HSM}: Hardware Security Module; módulo de seguridad en hardware, equipo físico 
% computacional que contiene funciones criptográficas, en específico funciona para 
% almacenar con un alto nivel de seguridad claves privadas.
% 
% %\bibliography{BibACRaizArticulo}
% %\bibliographystyle{plain}
%