source: libros/maquetacion/capitulo6/capitulo6.tex

%\chapter{Firmas Electr\'onicas}
\chapter{Propuesta de acoplamiento de la firma electr\'onica avanzada en procesos de negocio}


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

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




%A continuación el contenido del artículo de componente de firmas electrónicas
\begin{comment}
%\begin{abstract}
  Automation is use the information technologies as a direct method for improvement.
  However, there are elements such as handwritten signature that have been taken of all the digital area, but which, when recurrent events in organizational processes stand as a critical factor in the flow of operations.
  In response to this situation have developed numerous standards and technologies grouped by Electronic Signature concepts and PKI, but that in turn have discovered new questions in this field, among them, those that have to do with the integration processes.
  In this paper we propose a software component and a method for connecting computer systems as essential technology using the Advanced Electronic Signature.
  In this sense addresses the document formats, validation infrastructure, and safety conditions that ensure legal support.
  The work has center, the details and problems of integration, and that have been grouped under ``coupling joint`` concept.
%\end{abstract}
%\begin{keywords} Advanced Electronic Signatures, Component, XAdES, PKI, workflow. 
%\end{keywords}
\end{comment}
\begin{comment}
  Es necesario que se redacte el resumen en castellano, o suprimirlo por completo.
\end{comment}




 \section{Introducción}
 \label{sec:intro}
 La adopción de la tecnología de firma electrónica aún no está suficientemente extendida.
 Ésta se utiliza en distintas áreas y en muchas instituciones o empresas alrededor del mundo pero no ha llegado a ser equivalente a la firma autógrafa en un sentido amplio.
 Vinculado a este hecho, surge la pregunta ¿Pueden converger estas dos tecnologías en un futuro próximo?
 Con la finalidad de responder esta interrogante, se puede decir que la firma electrónica debe tener por lo menos tres características comunes a la autógrafa: identificar a la persona que la realiza; declarar la asunción u obligatoriedad de cumplimiento (contrato) del contenido de lo que se firma y por último, servir como prueba de autenticidad o no repudio del firmante.
 El modelo de firma electrónica basado en una infraestructura de clave pública (PKI por sus siglas en inglés), ha sido jurídicamente aceptado en muchos países, lo que equivale a decir que en estos casos se cumple con las características antes mencionadas.


 La firma manuscrita se percibe como un elemento tecnológico desacoplado, esto es, no dependiente de otra tecnología o factor (solo se necesita papel y lápiz) que puede usarse casi en cualquier lugar y con aceptación universal.
 En cambio la firma electrónica requiere de elementos de software (manejadores de dispositivos, clientes de firma, etc.) y hardware (lector de tarjetas, tarjeta inteligente, computador, tableta o móvil), adicionalmente y por lo general se debe contar con una conexión a la Internet para la validación.
 Otra ventaja importante de la firma manuscrita es la permanencia de factores biométricos que son fundamentales en la realización de auditorías confiables.
 A pesar de todas estas ventajas, en los últimos años ha crecido el uso de la firma electrónica, gobiernos nacionales y locales de España \cite{IEEEhowto:espana}, Alemania \cite{IEEEhowto:eID} y Estonia \cite{IEEEhowto:estonia} tienen disponibles plataformas para sus ciudadanos, y la popularización de la tarjeta inteligente (smartcard) como elemento de identificación personal ha apoyado este crecimiento.

 En este punto se plantean nuevos problemas vinculados al hecho de introducir o sustituir el elemento físico o autógrafo por el elemento electrónico, entre estos podemos señalar: elección del formato o formatos de archivo de los documentos firmados; ubicuidad y ergonomía de la acción de firma; verificación de los documentos firmados; histórico o archivo de documentos firmados y finalmente la integración de la firma con sistemas de base de datos relacionales, mapeos objetos-relacionales, servicios web, entre otros elementos utilizados en sistemas informáticos actuales.

 En este sentido, este trabajo plantea un método para integrar un componente \cite{IEEEhowto:software} de Firma Electrónica Avanzada denominado ComponenteFEA a procesos de negocio, teniendo presente parámetros de seguridad, rapidez y auditabilidad.



 \section{El modelo actual de firma electrónica}
 \label{sec:modelo}

 Una de las acciones para dar soporte jurídico a la firma electrónica y lograr su equivalencia con la firma manuscrita es fijar unas condiciones iniciales que garanticen integridad y auditabilidad de los documentos firmados, y que puedan ser validadados a través de un estándar.
 Bajo este enfoque, se ha creado el concepto de firma electrónica avanzada, que por definición debe contar con las siguientes propiedades: a) estar vinculada al firmante de manera única; b) permitir la identificación del firmante; c) haber sido creada utilizando medios que el firmante puede mantener bajo su exclusivo control y d) estar vinculada a los datos a que se refiere de modo que cualquier cambio ulterior de los mismos sea detectable.
 La formalización de esta idea ha sido llevada a cabo principalmente por el Parlamento Europeo, y se describe en la directiva 1999/93/EC \cite{IEEEhowto:directiva}.

 Existen dos grandes dominios tecnológicos para el uso de la Firma Electrónica Avanzada: uno es el que tiene que ver con los procesos de identificación, registro, emisión y validación de certificados electrónicos.
 De este dominio se ocupan las organizaciones que están bajo el esquema PKI, que funcionan como terceros de confianza.
 Cada certificado brinda identidad a una persona o empresa en la Internet, y se le otorga al ente bajo la aceptación de un contrato que especifica condiciones de uso.
 El certificado es un documento -un archivo- que autentifica la clave vinculada al ente.
 La clave secreta/privada se distribuye en una tarjeta inteligente o ficha criptográfica que funciona como un elemento de control de acceso de nivel 2.
 Los certificados electrónicos contienen información especificada bajo el formato X.509 versión 3 \cite{IEEEhowto:x509}, el cual incluye campos como fecha de expedición y vencimiento del certificado, Nombre único del propietario (conocido como Nombre Común), datos del Proveedor del certificado, datos criptográficos del certificado y datos del servidor de validación que utiliza el protocolo de estado de certificados en línea (OCSP por sus siglas en inglés).


 El segundo dominio corresponde a las aplicaciones que usa el propietario del certificado para aplicar la firma electrónica, y que generan valor agregado.
 Las aplicaciones de este tipo más utilizadas cuentan con una interfaz basada en bibliotecas dinámicas (.dll o .so) para este fin, así como también tienen un archivo de certificados de autoridades de certificación para validar la vigencia y correcta conformación del certificado del firmante.
 Esta interfaz es básica, solo permite generar un archivo de firma en formato PKCS\#7 \cite{IEEEhowto:pkcs7} separado del documento firmado, lo que conlleva a que las tareas de almacenamiento, validación y auditoría deben ser provistas adicionalmente a través de un programa o complemento de software.
 Las aplicaciones de este tipo más utilizadas son navegadores web y clientes de correo electrónico.

 Por otro lado, se han especificado diferentes formatos estándares de archivo con firma autocontenida.
 Por ejemplo el formato PDF dada sus características de solo lectura y visualización en pantalla como documento impreso es uno de los más utilizados para este fin.
 El estándar PADES \cite{IEEEhowto:pades} basado en PDF es un ejemplo de ello, también existe el formato PDF nativo, y que es verificable por los visores más populares como el de \textit{Adobe Reader}\copyright.

 También existen estándares para archivos con firma electrónica basados en XML. La ventaja de estos formatos es que pueden integrar metadatos como la fecha y lugar de la(s) firma(s), y permiten incluir diferentes tipos de archivos como fotos, videos, documentos de texto u ofimáticos.
 Entre los estándares XML más conocidos está el XMLDsig \cite{IEEEhowto:xmldsig}.
 Este estándar cuenta con diferentes implementaciones y extensiones, entre ellas el formato creado por las repúblicas bálticas llamado BDOC \cite{IEEEhowto:bdoc}, que sigue a su vez el popular estándar OpenDocument, utilizado por el paquete ofimático OpenOffice como formato principal para sus archivos.





 \section{Antecedentes}

 La inclusión de la firma electrónica en un proceso de negocio tiene varios aspectos asociados.
 Se pueden señalar como los más relevantes la ergonomía de la firma (facilidad de uso), los formatos y visualización de documentos, la integración con plataformas de software y la arquitectura de la solución.


 En relación con el tema de la ergonomía Xyzmo SIGNificant\footnote{Para ver información completa sobre Xyzmo Significant visitar la dirección web: http://www.xyzmo.com} es una novedosa propuesta.
 Xyzmo es una aplicación comercial de código fuente propietario, que introduce elementos innovadores en el área de ergonomía y adaptación al cambio: no obliga a aprender una nueva técnica de firma sino que ofrece a los usuarios de esta tecnología el uso de la firma manuscrita a través de una tableta electrónica o teléfono con interfaz multitoque (multitouch) bajo sistemas operativos Android\copyright \hspace{0.2cm}y iOS\copyright, esto sin desvincularse del esquema PKI. Este modelo proporciona al usuario la metáfora de la firma manuscrita mostrando el documento tal cual como si fuese impreso, habilitando la firma electrónica avanzada a través del uso de los dedos o de un lápiz para pantalla táctiles.
 Para el proceso de validación se utilizan parámetros biométricos tales como ritmo, velocidad o características del trazo, y también técnicas criptográficas estandarizas vinculadas al esquema PKI.

 Existen diferentes implementaciones de software para las gestión y visualización de los dos tipos de formatos principales: PDF y XML. Para el caso del formato PDF la visualización está automáticamente disponible ya que existen numerosos lectores para este tipo de archivo, por ejemplo, el Adobe Reader\copyright \hspace{0.2cm} que visualiza la firma electrónica o digital como un sello (imagen) dentro del documento, y muestra también su contenido con características de forma (encabezado, líneas, tablas, logos, etc.) que pueden ser parte o no del documento firmado, pero que en muchos casos son necesarias para la elaboración de documentos formales o legales.
 En el caso de los formatos XML la visualización no es automática, por lo tanto si se requiere visualizar el contenido con elementos de forma se debe disponer de un software visualizador que formatee el contenido.
 En \cite{IEEEhowto:neubauer} se muestra una propuesta para documentos XML que necesitan por disposiciones legales o formales de gobierno aplicar forma a documentos firmados electrónicamente.

 Una de las potencialidades de la firma electrónica es su integración con sistemas informáticos para la mejora de procesos mediante la eliminación de puntos lentos.
 Es por ello que los temas de integración y arquitectura juegan un papel preponderante.
 En esta tendencia se inscribe el proyecto \textit{@firma}: una solución desarrollada por el Ministerio de Hacienda y Administraciones Públicas de España, que se plantea como una plataforma de firma electrónica orientada a brindar servicios de gobierno electrónico, y que está integrada con el sistema de identificación Español.
 Cuenta con una aplicación de escritorio que puede usarse en diversos sistemas operativos, y un \textit{applet} \cite{IEEEhowto:java} para usar la firma a través de la web.
 Estas características habilitan a \textit{@firma} para el desarrollo de aplicaciones de gobierno electrónico, así como también para la integración con sistemas empresariales.



 \section{Acoplamiento de la firma electrónica avanzada}



 La conexión entre un componente (software) y el sistema informático se denomina acoplamiento.
 Este procedimiento debe cumplir con un conjunto de requisitos que tienen que ver con características tales como reutilización, cohesión y la exportación de una interfaz definida.
 A continuación se describen los elementos desarrollados en este trabajo.


 \subsection{Componente de firma electrónica avanzada}

 Se desarrolló un componente que permite realizar diferentes operaciones asociadas con la firma electrónica: subir un documento desde el computador cliente; realizar la firma utilizando una tarjeta inteligente con PIN (contraseña) desde el computador cliente y entregar un archivo firmado en formato XAdES\cite{IEEEhowto:xades} al programa servidor.
 El componente se ha denominado de firma electrónica avanzada (ComponenteFEA), ya que cumple con las condiciones citadas en la sección \ref{sec:modelo} sobre este tipo de firma.


 Las funcionalidades que implementa el ComponenteFEA son las siguientes:
 \begin{enumerate}
 \item
  Firmar electrónicamente (para este caso se asume que lo electrónico está asociado a un dispositivo en hardware como una tarjeta inteligente, y en relación a ello debe connotar vinculación jurídica, lo digital sólo a una clave en software) un documento de tipo de archivo definido por especificación MIME \cite{IEEEhowto:mime}.
 \item
  Firmar digitalmente (usando un archivo PKCS\#12 \cite{IEEEhowto:pkcs12}) un documento de tipo de archivo definido por especificación MIME .
 \item
  Verificar un archivo firmado electrónicamente usando o no validación OCSP.
 \item
  Verificar un archivo firmado digitalmente usando o no validación OCSP.
 \item
  Mostrar propiedades como algoritmos utilizados, fecha y lugar de la firma de un archivo firmado 
 \item
  Firmar electrónicamente utilizando un componente para el navegador un documento de tipo de archivo definido por especificación MIME.
 \end{enumerate}


 \begin{verbatim}

class BDocDocument : QObject {
// *** Métodos para firma electrónica
    BDocDocument();
    void init();
    void create( const QString file );
    bool openBDocContainer(const QString path);
    void saveBDocContainer(const QString path);      
    bool signWithP12(const QString  profile,...);
    void addDocument(const QString path);

// ** Mètodos de firma por navegador web
    bool presignWeb(const QString  profile, ...);
    bool postsignWeb(const QString  profile, ...);


// ** Métodos para validación
    QString signatureAlgorithm(int index );
    bool validateOffline() const ;

// ** Métodos para Gestión de archivos
    QString signatureFormat(int index );
    QString signatureDateTime(int index );
    QStringList signatureLocation(int index );
    QString signatureRol(int index );
    QString signatureDigestMethod(index )
    QString subjectCertificateCommonName(int i);
    QString documentName(int docId);
    int documentCount();
    int signatureCount();
    void saveDocument(int docId...);

  }
 \end{verbatim}
 \begin{center}
  \textbf{Listado 1.} API del ComponenteFEA en C++ accesible desde \textit{python}
 \end{center}

 Bajo esta perspectiva se propone tratar las funcionalidades asociadas a la firma electrónica avanzada, es decir, empaquetar las funcionalidades exportando una interfaz de programación de aplicaciones (API por su siglas en inglés) que puede ser utilizada de forma encapsulada y separada por una aplicación anfitrión, escrita teóricamente en cualquier lenguaje de programación.
 Una de las aplicaciones que trabaja bajo este esquema de complementos o componentes es el navegador web, este diseño ha permitido contar con grandes repositorios que extienden las funcionalidades del navegador casi para cualquier uso.

 \begin{figure}[htb]
  \centering
%\includegraphics[width=8cm]{imagenes/uml.png}
  \includegraphics[scale=1]{imagenes/uml.jpeg}
  \caption{Diagrama UML de acoplamiento}
  \label{fig:uml}
 \end{figure}

 La figura \ref{fig:uml} muestra un diagrama en lenguaje UML del componente y su conexión con un sistema informático.
 Existen tres tipos de funcionalidades que exporta el ComponenteFEA: ``Firmar'', interfaces para firma electrónica y digital; ``Validar'', interfaces para validación fuera de línea y en línea de certificados electrónicos; y ``Gestionar'', interfaces para el almacenamiento y búsqueda de archivos firmados.


 A nivel de lenguaje de programación se provee un paquete o \textit{package} para \textit{python} que está construido envolviendo una librería de firma electrónica avanzada escrita en lenguaje \textit{C/C++}.
 El listado \textbf{1} muestra los métodos que son accesibles desde \textit{python}.



 \subsection{Método de conexíón}


 El diagrama de flujo de la figura \ref{fig:acoplamiento} muestra los pasos a seguir para incorporar el ComponenteFEA dentro de un proceso de una organización.
 Los primeros dos pasos de este diagrama corresponden a la identificación de los puntos de firma y validación dentro del proceso de negocio, para luego conectar los métodos (mensajes) correspondientes del ComponenteFEA en dichos puntos.



 \begin{figure}[htb]
  \centering
%\includegraphics[width=8cm]{imagenes/flujoComponenteFE.jpg}
  \includegraphics[scale=1]{imagenes/flujoComponente.jpeg}
  \caption{Diagrama de flujo para el acoplamiento del ComponenteFEA}
  \label{fig:acoplamiento}
 \end{figure}


 En un siguiente paso y dependiendo del tipo de proceso a automatizar se adoptará un esquema de conexión para el servidor.
 En esta fase se establecen algunos aspectos importantes relativos al sistema informático a colocar en funcionamiento, entre estos están la existencia de un sistema automatizado, el tipo de lenguaje de programación y sistemas operativos a utilizar, el soporte de la PKI, la asignación de las tarjetas inteligentes, entre otros.


 En este punto el desarrollador tiene la libertad de utilizar el componente de firma según su criterio, sin embargo, puede seguir algunas pautas relacionadas con el proceso a automatizar.
 Si el proceso no se encuentra automatizado se recomienda seleccionar para el desarrollo de software el lenguaje \textit{Python}.
 Para el caso anterior o si el sistema se implementó utilizando este lenguaje se sigue el paso 7.1 de la figura \ref{fig:acoplamiento} que corresponde con la instalación del componente ''servidor`` para la firma electrónica avanzada.


 En el caso de que los procesos de negocio se encuentren automatizados bajo un lenguaje diferente a \textit{Python}, se utiliza la interfaz de servicios web\footnote{La interfaz de servicios web está disponible en: http://bazaar.launchpad.net/\~esignature/esignature/bdoc/files/head:/server/} que provee el ComponenteFEA (Paso 8.1 de la figura \ref{fig:acoplamiento}).



 Un tema a tomar en cuenta es el relativo al tipo de repositorio donde se almacenan los archivos firmados.
 El ComponenteFEA genera archivos tipo XAdES con extensión \textit{.bdoc}.
 Para este fin puede utilizarse un directorio en el sistema de archivos o un gestor de base de datos relacional.
 En este punto también hay que trabajar sobre el esquema de nombres, es decir la forma como se identifican unívocamente los archivos para que puedan ser encontrados.
 Para ello se puede utilizar la vinculación de metadatos en los registros de las tablas de la base de datos relacional, o simplemente asignar un nombre como clave única a los archivos firmados.




 Como último paso se debe habilitar un módulo para gestionar los archivos firmados (paso 9 de la figura \ref{fig:acoplamiento}), es decir, proveer una interfaz de usuario para las acciones de visualización de propiedades de archivos, validación de firmas electrónica, búsqueda, entre otras.
 Estas funcionalidades las provee el ComponenteFEA mediante los métodos que se nombran en la sección ``Métodos para Gestión de archivos'' del Listado \textbf{1}, y pueden ser extendidas utilizando algunas de las funcionalidades del gestor de datos que se utilice.


 \section{Casos de estudio}

 A continuación se muestran tres casos de integración utilizando un mismo proceso con diversos sistemas informáticos.
 El proceso tratado es el conocido como ``Orden de compra'', el cual está presente en muchas organizaciones.
 Consiste en realizar un proceso de negocio con la finalidad de obtener un conjunto de productos o servicios necesarios para la organización a través de una búsqueda y evaluación de un cierto número de cotizaciones y que siguen una serie de criterios, como por ejemplo, las características de calidad y precio.
 El proceso en pasos se puede describir así:
 \begin{enumerate}
 \item
  Generar una requisición o documento de solicitud para el conjunto de productos o servicios
  \begin{itemize}
  \item
   Firma del solicitante
  \end{itemize}
 \item
  Obtener por los menos n
  $(n\geq2)$ cotizaciones para el conjunto de productos o servicios
 \item
  Seleccionar una cotización y generar un acta 
  \begin{itemize}
  \item
   Firma del analista de compras
  \end{itemize}
 \item
  Generar una orden de compra 
  \begin{itemize}
  \item
   Firma del gerente del departamento
  \end{itemize}
 \end{enumerate}

 Generalmente este proceso se lleva a cabo utilizando firmas manuscritas en coordinación con un sistema informático: se imprime desde el sistema el documento (requisición, acta u orden de compra), se firma, y luego se actualiza la información en el sistema informático.

 Para el caso de estudio planteado se puede sustituir la primera, la segunda o las tres firmas manuscritas por sus respectivas firmas electrónicas.
 También es posible agregar firmas electrónicas en puntos donde no existen firmas manuscritas.

 La segunda funcionalidad a conectar del ComponenteFEA es la validación de los documentos firmados electrónicamente.
 Para ello se identifican los puntos donde se actualiza la información sobre la firma manuscrita.
 Una tercera funcionalidad es la que tiene que ver con la visualización de los atributos de los documentos firmados electrónicamente.

 Después del proceso de identificación, para cada punto que se determinó en la fase anterior, se incorporan los métodos del ComponenteFEA con llamadas locales o remotas según sea el caso.
 A continuación se presentas tres implementaciones del proceso ``Orden de compra'' para tres sistemas informáticos diferentes.


 \subsection{Caso OpenERP }

 OpenERP\footnote{Ver la dirección web: http://www.openerp.com} es un software de Planificación de Recursos Empresariales (ERP, por sus siglas en inglés), software libre, que tiene un gran número de instalaciones.
 En su base incluye el proceso de ``Orden de compra''.
 Para realizar el acoplamiento se creó un nuevo módulo de OpenERP. Se identificaron los puntos de firma y validación y se sustituyeron por las llamadas respectivas al ComponenteFEA. Como elemento agregado se creó un nuevo módulo basado en bandejas de documentos -archivos generados por OpenERP- (similar a las usadas en los clientes de correo electrónico) asociadas a los documentos a ser firmados electrónicamente.


 La figura \ref{fig:openerp} muestra la interfaz de usuario para gestionar los archivos firmados electrónicamente.
 Los usuarios autorizados pueden utilizar una tarjeta inteligente para firmar los documentos correspondientes al proceso de ``Orden de compra'', teniendo la misma validez legal (especificado por las políticas de la PKI y la legislación del país) que la firma manuscrita.
 Primero el solicitante firma la requisición, y este documento se envía a la bandeja del analista de compra, quién busca las cotizaciones correspondientes y selecciona el conjunto de productos a comprar.
 Se generan los documentos ``Acta'' y ``Orden de compra'', este último es enviado a la bandeja del gerente quién lo firma para aprobar la compra del conjunto de productos o servicios seleccionados.


 OpenERP provee al desarrollador patrones Modelo-Vista-Controlador (MVC) y un motor de flujo de trabajos o \textit{Workflow} para implementar nuevas funcionalidades.
 Usando estas herramientas los documentos firmados se vinculan al modelo de datos y las validaciones de firma electrónica se realizan extendiendo el flujo de trabajo relacionado con el proceso ``Orden de compra'' base de OpenERP.


 \begin{figure}[htb]
  \centering \includegraphics[scale=1]{imagenes/openerp.jpeg}
  \caption{Interfaz de usuario OpenERP para el ComponenteFEA}
  \label{fig:openerp}
 \end{figure}


 La última captura de pantalla de la figura \ref{fig:openerp} muestra un cuadro de diálogo que pide un PIN o contraseña al usuario.
 Esta interfaz forma parte del complemento Web que debe ser instalado en el cliente (navegador) y que tiene interacción con el certificado firmante contenido en una tarjeta inteligente.



 \subsection{Caso SAID}


 SAID\footnote{Ver la dirección web: http://said.cenditel.gob.ve/wiki } es un sistema administrativo que incluye procesos contables y administrativos para instituciones que operen en el sector público venezolano.
 Entre los procesos que implementa SAID está el de ``Orden de compra'', que incluye entre sus capacidades la posibilidad de utilizar firmas electrónicas basadas en el formato PKCS\#7.

 El sistema fue escrito en PHP Versión 4.X, y es de código libre.
 Los puntos de firma y validación están claramente identificados, ya que son los indicados por las firmas electrónicas, en este caso solo se sustituyen las llamadas a la API del motor criptográfico local, por llamados a los servicios web del ComponenteFEA. El listado \textbf{2} muestra las llamadas que se insertaron en el código fuente para extender el sistema de tal manera que funcione con firmas electrónicas avanzadas.
 El repositorio de archivos firmados a utilizar es PostgreSQL Version 8.4 (El mismo que utiliza SAID).
 El listado \textbf{2} muestra el código en PHP para validar una firma electrónica y mostrar los firmantes de un documento del proceso de Orden de compra: requisición, acta u orden.
 Después de realizar la conexión al servidor \textit{localhost} por el puerto 4242, se procede a abrir un archivo firmado con el método ``openBDocContainer'' a través de una llamada remota, luego se utiliza el método ``validateSignature'' para validar la firma, y finalmente se listan todos los firmantes utilizando el método ``subjectCertificateCommonName''.

 \begin{verbatim}
 <?php

include('xmlrpc.php');

$connec = new XMLRPCClient('localhost:4242');
$identificador = 'prueba1';
$connec->__call('init', array($identificador));
$connec->__call('openBDocContainer', 
array($identificador,
'detalle_curso.odt.bdoc'));
$resp = $connec->__call('signatureCount', 
array($identificador));
$firmantes = Array();
for($pos=0; $pos<$resp; $pos++)
{       
        $datos = Array();
        $valida = 'No válido';
        if($connec->__call('validateSignature', 
array($identificador,$pos)))
        {
           $valida = 'Válido';
           $nombre = 
 $connec->
   __call('subjectCertificateCommonName',
array($identificador,$pos));
           $firmantes[] = array('nombre'=> $nombre,
'valida'=>$valida);
        }
}

for($i=0;$i<count($firmantes);$i++)
{
        echo "{$firmantes[$i]['nombre']} 
{$firmantes[$i]['valida']}\n";
}
?> 
 \end{verbatim}
 \begin{center}
  \textbf{Listado 2.} Conexión mediante servicios web-rpc desde SAID al ComponenteFEA
 \end{center}


 De forma similar al caso OpenERP, se provee un complemento para el navegador de tal manera que los usuarios puedan realizar la firma de forma remota, utilizando una tarjeta inteligente desde su estación de trabajo.
 Luego el documento se procesa por el sistema SAID, y se almacena en la base de datos del servidor.

 \subsection{Caso Flujos de Trabajo}

 El proceso especificado en esta sección puede modelarse usando un motor de flujo de trabajo.
 Los flujos de trabajo son ampliamente utilizados para modelar procesos a través de un lenguaje descriptivo como BPM o BPEL \cite{IEEEhowto:bpel}.
 Para implementar el proceso de ``Orden de compra'' se utilizó el motor SAFET \cite{IEEEhowto:safet}, ya que incorpora el ComponenteFEA nativamente, solo se necesitan especificar los puntos en el proceso donde se requiere la firma electrónica.
 La validación la realiza el motor de forma automática.
 Para este caso los pasos 1 y 2 del Diagrama de flujo para el acoplamiento del ComponenteFEA, se realizan sin la necesidad de agregar o modificar código fuente, solo se especifica en el archivo de definición de flujo.

 El listado \textbf{3} muestra la definición de la acción de firma electrónica en un flujo de trabajo (SAFET).
 El usuario definido por el \textit{NombreComunUsuario} debe firmar electrónicamente el documento de requisición para pasar a la siguiente actividad que en este caso se denominada \textit{Cotización}.
 La sentencia \textit{vRequisicion \textbf{SIGN} NombreComunUsuario} indica al motor de flujo de trabajo lo descrito anteriormente.


 \begin{verbatim}
  <task id="Requisicion" title="Acción de solicitud de bien o servicio" > <port side="forward" type="split" > <connection source="Cotización" query="vRequisicion SIGN NombreComunUsuario" options="" > </connection> </port> <variable id="vRequisicion" scope="task" tokenlink="" documentsource="select id, nombre,descripcion, fechageneracion from requisiciones" > </variable> </task>
 \end{verbatim}
 \begin{center}
  \textbf{Listado 3.} Tarea de firma de requisición usando SAFET (XML)
 \end{center}




 \section{Conclusiones}

 En un mediano plazo la firma electrónica avanzada puede consolidarse como una tecnología fundamental en los procesos de negocio ya que propone la digitalización de un elemento imprescindible en este contexto como lo es la firma manuscrita.
 Los retos de la digitalización son diversos y complejos, y tienen que ver con aspectos disímiles como lo son por ejemplo los formatos de archivo de firma electrónica y la ergonomía para el uso de esta tecnología.

 En este trabajo se detalla un método para la integración de un componente de software con sistemas informáticos que automatizan procesos de negocio.
 En la fase de acoplamiento se define la identificación de puntos de firma electrónica, se especifica la validación de los certificados firmantes por una PKI, se muestra la habilitación del navegador web para la firma electrónica (basada en tarjetas inteligentes) a través de un complemento y se discute sobre los parámetros de seguridad de los formatos de firma electrónica.
 Las tareas como la construcción de un gestor de archivos firmados se proponen como una actividad complementaria.


 Con la finalidad de mostrar la aplicación del método propuesto en sistemas en situaciones reales se mostraron tres casos de estudio, cada uno con sus particularidades.
 El acoplamiento del ComponenteFEA con los sistemas informáticos OpenERP, SAID y SAFET siguen el método descrito en el trabajo, evaluando para todos los casos especialmente el tipo de conexión a utilizar (local o remota), el tipo de almacenamiento y el procedimiento para la conexión en los puntos de firma electrónica y validación.


 El análisis de vulnerabilidades es un tema omnipresente en el área de seguridad informática, y está relacionado con este trabajo a través del análisis de los formatos, protocolos y tecnologías utilizados en el proceso de integración.

 Existen otros aspectos que no se discuten en este trabajo pero que se consideran importantes para la aprehensión de la tecnología de firma electrónica.
 Entre ellos se pueden señalar la mejora de la experiencia del usuario y la visualización de los archivos de formato XML firmados electrónicamente.

 En el tema específico de integración, en \cite{IEEEhowto:eID} se discute sobre la necesidad de abrir el compás de aplicaciones compatibles con la tecnología de Firma Electrónica Avanzada, y en general, sobre la asunción de un nuevo paradigma en el despliegue de procesos de negocio.






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






% \begin{thebibliography}{1}
% 
% \bibitem{IEEEhowto:espana}
% Portal del DNI Electrónico Español. Disponible en: http://www.dnielectronico.es/. Febrero 2013.
% 
% \bibitem{IEEEhowto:eID}
% Andreas Poller, Ulrich Waldmann, Sven Vowe, Sven Turpe, Electronic Identity Cards for User Authentication
% Promise and Practice, IEEE Security \& Privacy10, vol. 10, no. 1, pp. 46-54, January/February, 2012
% 
% 
% \bibitem{IEEEhowto:estonia}
% Oficial Gateway to Estonia. Disponible en: http://estonia.eu/about-estonia/economy-a-it/e-estonia.html. Febrero 2013.
% 
% 
% \bibitem{IEEEhowto:software}
% Campderrich Falgueras, Benet. Ingeniería del Software. Editorial UOC. Barcelona, España. 2003.
% 
% 
% \bibitem{IEEEhowto:directiva}
% DIRECTIVA 1999/93/CE DEL PARLAMENTO EUROPEO Y DEL CONSEJO. Diciembre 1999. Disponible en: http://www.cert.fnmt.es/legsoporte/D\_1999\_93\_CE.pdf
% 
% \bibitem{IEEEhowto:x509}
% Cooper D.,  Santesson S., y otros. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. Request for Comments (RFC) 5280. May 2008.
% Disponible en: http://www.ietf.org/rfc/rfc5280.txt. Febrero 2013.
% 
% \bibitem{IEEEhowto:pkcs7}
% PKCS\#7.Cryptographic Message Syntax. Disponible en: https://tools.ietf.org/html/rfc2315. Febrero 2013.
% 
% \bibitem{IEEEhowto:pades}
% PAdES. PDF Advance Electronic Signatures. Disponible en: http://www.etsi.org/deliver/etsi\_ts/
% 102700\_102799/10277801/01.01.01\_60/ts\_10277801v010101p.pdf. Febrero 2013.
% 
% \bibitem{IEEEhowto:xmldsig}
% Bartel M., Boyer J., y otros. XML Signature Syntax and Processing (Second Edition). W3C Recommendation 10 June 2008.
% Disponible en: http://www.w3.org/TR/xmldsig-core/. Febrero 2013.
% 
% \bibitem{IEEEhowto:bdoc}
% Formato para firmas electrónicas. Disponible en: http://www.signature.it/-TOOLS/Bdoc-1.0.pdf. Febrero 2013.
% 
% \bibitem{IEEEhowto:neubauer}
% Neubauer, T.; Weippl, E.; Biffl, S., "Digital signatures with familiar appearance for e-government documents: authentic PDF," Availability, 
% Reliability and Security, 2006. ARES 2006. The First International Conference on , vol., no., pp.8 pp.,, 20-22 April 2006
% 
% \bibitem{IEEEhowto:java}
% Richardson Clay, Avondolio Donald, others. Professional Java, JDK. 5th Edition. Wrox. February. 2005.
% 
% \bibitem{IEEEhowto:xades}
% Cruellas, J. Karlinger G., y otros. XML Advanced Electronic Signatures (XAdES). W3C Note 20 February 2003.
% 
% \bibitem{IEEEhowto:mime}
% Security Multiparts for MIME. Multipart/Signed and Multipart/Encrypted. Disponible en: http://tools.ietf.org/html/rfc1847. Febrero 2013.
% 
% \bibitem{IEEEhowto:pkcs12}
% PKCS\#12.Personal Information Exchange Syntax Standard. RSA Laboratories. Disponible en: https://www.rsa.com/rsalabs/node.asp?id=2138. Febrero 2013.
% 
% \bibitem{IEEEhowto:bpel}
% Matjaz Juric, Mathew Benny. Business Process Execution for Web Services BPEL and BPEL4WS. 2 Ed. Packt Publishing. 2006.
% 
% \bibitem{IEEEhowto:safet}
% Bravo, V. Araujo A., SAFET: Sistema para la generación de aplicaciones de firma electrónica. Revista Puente. Vol 6. Número 1. Bucaramanga, Colombia. 2011.
% 
% 
% % el siguiente item no se está utilizando
% \bibitem{IEEEhowto:pki}
% Duane. N. Brink, J. PKI: Infraestructura de Clave Pública. McGrawHill 2002.
% 
% \end{thebibliography}

%\begin{IEEEbiography}[{\includegraphics[width=1in,height=1.25in,clip,keepaspectratio]{victor.png}}]{Víctor Bravo}
% Víctor Bravo nació en Maracaibo, Venezuela. Es Ingeniero de Sistemas y tiene una maestría en Computación de la Universidad de los Andes (ULA),Venezuela. 
% Ha trabajado como director en importantes
% proyectos vinculados a procesos de Certificación Electrónica masiva tal como ''Software de Gestión Autoridad Raíz de la
% PKI Pública Nacional``. Ha dictado conferencias sobre temas de certificación electrónica en varios países. Actualmente está 
% adscrito como Investigador a la Fundación CENDITEL, y ha sido profesor desde el año 2005 de la cátedra de Matemáticas Discretas del
% Departamento de Computación de la ULA.
%\end{IEEEbiography}


%\begin{IEEEbiography}[{\includegraphics[width=1in,height=1.25in,clip,keepaspectratio]{antonioaraujo.jpg}}]{Antonio Gregorio Araujo Brett}
% Antonio Araujo es Ingeniero de Sistemas, egresado de la Universidad de Los Andes, en
% Mérida, Venezuela. Actualmente
% cursa estudios de Maestría en Computación de la Facultad de Ingeniería
% de la Universidad de Los
% Andes. Ha asesorado
% proyectos de certificación
% electrónica y participado como ponente en varias jornadas y congresos de
% certificación electrónica y
% firmas electrónicas en el país.
% Se desempeña desde el año 2007 como Analista de la gestión de
% desarrollado en Tecnologías Libres de
% la Fundación Centro Nacional de Desarrollo e Investigación en
% Tecnologías Libres – CENDITEL Nodo
% Mérida.
%\end{IEEEbiography}

%\begin{IEEEbiography}[{\includegraphics[width=1in,height=1.25in,clip,keepaspectratio]{jogerquintero.jpg}}]{Joger André Quintero Escalante}

% Joger Quintero es Técnico Superior en Informática, egresado del Instituto Universitario Tecnológico de Ejido, en
% Ejido, Venezuela.  Se desempeña como Analista Desarrollador en CENDITEL(Nodo Mérida) desde el año 2011. 
%\end{IEEEbiography}