Ignore:
Timestamp:
Oct 16, 2014, 8:55:14 AM (10 years ago)
Author:
aaraujo <aaraujo@…>
Branches:
revisionfinal
Children:
22dcb0c
Parents:
772329b
git-author:
Dhionel Díaz <ddiaz@…> (14/10/14 11:55:35)
git-committer:
aaraujo <aaraujo@…> (16/10/14 08:55:14)
Message:

Estandarización de formato.

Signed-off-by: Dhionel Díaz <ddiaz@…>
Signed-off-by: aaraujo <aaraujo@moe>

File:
1 edited

Legend:

Unmodified
Added
Removed

  • maquetacion/capitulo6/capitulo6.tex

    r8a02fde r969cb45  
    33
    44
    5 \chapterauthors{Víctor Bravo y Antonio Araujo
    6 \chapteraffil{Fundación Centro Nacional de Desarrollo e Investigación en Tecnologías Libres}
    7 }
     5\chapterauthors{Víctor Bravo y Antonio Araujo \chapteraffil{Fundación Centro Nacional de Desarrollo e Investigación en Tecnologías Libres} }
    86\label{capitulo6}
    97
    108% Se crea un ambiente bibunit para el cual se creará la bibliografía
    119\begin{bibunit}[unsrt]
    12  
     10
    1311
    1412
    … …  
    1715\begin{comment}
    1816%\begin{abstract}
    19 Automation is use the information technologies as a direct method for improvement. However, there are elements such as handwritten signature that
    20 have been taken of all the digital area, but which, when recurrent events in organizational processes
    21 stand as a critical factor in the flow of operations.
    22 In response to this situation have developed numerous standards and technologies grouped by
    23 Electronic Signature concepts and PKI, but that in turn have discovered new questions in this field, among them,
    24 those that have to do with the integration processes.
    25 In this paper we propose a software component and a method for connecting
    26 computer systems as essential technology using the Advanced Electronic Signature. In this sense
    27 addresses the document formats, validation infrastructure,
    28 and safety conditions that ensure legal support. The work has
    29 center, the details and problems of integration, and that have been grouped under ``coupling joint`` concept.
     17  Automation is use the information technologies as a direct method for improvement.
     18  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.
     19  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.
     20  In this paper we propose a software component and a method for connecting computer systems as essential technology using the Advanced Electronic Signature.
     21  In this sense addresses the document formats, validation infrastructure, and safety conditions that ensure legal support.
     22  The work has center, the details and problems of integration, and that have been grouped under ``coupling joint`` concept.
    3023%\end{abstract}
    3124%\begin{keywords} Advanced Electronic Signatures, Component, XAdES, PKI, workflow.
    … …  
    3326\end{comment}
    3427\begin{comment}
    35 Es necesario que se redacte el resumen en castellano, o suprimirlo por completo.
     28  Es necesario que se redacte el resumen en castellano, o suprimirlo por completo.
    3629\end{comment}
    3730
    … …  
    3932
    4033
    41 \section{Introducción}
    42 \label{sec:intro}
    43 La adopción de la tecnología de firma electrónica aún no está suficientemente extendida. Ésta
    44 se utiliza en distintas áreas y en muchas  instituciones o empresas alrededor del mundo pero no ha llegado a ser
    45 equivalente a la firma autógrafa en un sentido amplio. Vinculado a este hecho, surge la pregunta ¿Pueden converger
    46 estas dos tecnologías en un futuro próximo? Con la finalidad de responder esta interrogante,
    47 se puede decir que la firma electrónica  debe tener  por lo menos tres  características comunes
    48 a la autógrafa: identificar a la persona que la realiza; declarar la asunción u obligatoriedad de cumplimiento (contrato)
    49 del contenido de lo que se firma y por último, servir  como prueba de autenticidad o no repudio del firmante.
    50 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,
    51 lo que equivale a decir que en estos casos se cumple con las características antes mencionadas.
    52 
    53 
    54 La firma manuscrita se percibe como un elemento tecnológico desacoplado, esto es, no dependiente de otra tecnología o factor (solo
    55 se necesita papel y lápiz)  que
    56 puede usarse casi en cualquier lugar y con aceptación universal. En cambio la firma electrónica requiere de elementos de software
    57 (manejadores de dispositivos, clientes de firma, etc.) y hardware (lector de
    58 tarjetas, tarjeta inteligente, computador, tableta o móvil),
    59 adicionalmente  y por lo general se debe contar con una conexión a la Internet para la validación. Otra ventaja importante
    60 de la firma manuscrita es la permanencia de factores biométricos que son fundamentales en la realización
    61 de auditorías confiables. A pesar de todas  estas ventajas, en los últimos años ha crecido el uso de la firma electrónica,
    62 gobiernos nacionales y locales de España \cite{IEEEhowto:espana}, Alemania
    63 \cite{IEEEhowto:eID} y Estonia \cite{IEEEhowto:estonia} tienen disponibles
    64 plataformas para sus ciudadanos, y la popularización de la tarjeta
    65 inteligente (smartcard) como elemento de identificación personal ha apoyado este crecimiento.
    66 
    67 En este punto se plantean nuevos  problemas vinculados al hecho de introducir o  sustituir el elemento físico o autógrafo
    68 por el elemento electrónico,
    69 entre estos podemos señalar:  elección del formato
    70 o formatos de archivo de los documentos firmados; ubicuidad y ergonomía de la acción de firma; verificación de los documentos
    71 firmados; histórico o archivo de documentos firmados y finalmente la  integración de la firma con sistemas de base de datos relacionales, mapeos
    72 objetos-relacionales, servicios web, entre otros elementos utilizados en sistemas informáticos actuales.
    73 
    74 En este sentido, este trabajo  plantea un método para integrar un componente \cite{IEEEhowto:software}  de Firma Electrónica Avanzada   denominado
    75 ComponenteFEA a procesos de negocio, teniendo presente parámetros de seguridad, rapidez y auditabilidad.
    76 
    77 
    78 
    79 \section{El modelo actual de firma electrónica}
    80 \label{sec:modelo}
    81 
    82 Una de las acciones  para dar soporte jurídico a la firma electrónica y lograr su equivalencia con la firma manuscrita es
    83 fijar unas condiciones iniciales que garanticen integridad y auditabilidad de los documentos firmados, y que
    84 puedan ser validadados a través de un estándar. Bajo este enfoque, se ha creado el concepto de firma electrónica avanzada,
    85 que por definición debe contar con las siguientes propiedades:  a) estar
    86 vinculada al firmante de  manera única; b) permitir la identificación del
    87 firmante;
    88 c) haber sido creada
    89 utilizando medios que el firmante puede mantener bajo su exclusivo control y d) estar vinculada a los datos a que se refiere
    90 de modo que cualquier cambio ulterior de los mismos sea detectable.  La
    91 formalización de esta idea ha sido llevada a cabo principalmente
    92 por el Parlamento Europeo,
    93 y se describe en la directiva  1999/93/EC \cite{IEEEhowto:directiva}.
    94 
    95 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
    96 identificación, registro, emisión  y validación de certificados electrónicos. De este dominio se ocupan 
    97 las organizaciones que están bajo el esquema PKI, que funcionan como terceros de confianza. Cada certificado brinda identidad
    98 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
    99 es un documento -un archivo-
    100 que autentifica la clave vinculada al ente. La clave secreta/privada se distribuye en una tarjeta inteligente
    101 o ficha criptográfica que funciona como un elemento de control de
    102 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
    103 incluye campos como  fecha de expedición y vencimiento del certificado, Nombre único del propietario (conocido como Nombre Común),
    104 datos del Proveedor del certificado, datos criptográficos del certificado y datos del servidor de validación
    105 que utiliza el protocolo de estado de certificados en línea (OCSP por sus siglas en inglés).
    106 
    107 
    108 El segundo dominio corresponde a las  aplicaciones que usa el propietario del certificado para aplicar
    109 la firma electrónica, y que generan valor agregado. Las aplicaciones de este tipo más utilizadas  cuentan con
    110 una interfaz basada en bibliotecas dinámicas (.dll o .so) para este fin, así como también tienen un archivo de certificados
    111 de autoridades de certificación para validar la vigencia y correcta conformación
    112 del certificado del firmante. Esta interfaz
    113 es básica, solo permite generar un archivo de firma en formato PKCS\#7 \cite{IEEEhowto:pkcs7} separado del documento firmado, lo que conlleva
    114 a que las tareas de almacenamiento, validación y auditoría  deben ser provistas  adicionalmente a través de un programa
    115 o complemento de software. Las aplicaciones de este tipo más utilizadas son navegadores web y clientes de correo electrónico.
    116 
    117 Por otro lado, se han especificado diferentes formatos estándares de archivo con firma autocontenida. Por ejemplo el formato PDF
    118 dada sus características de solo lectura y visualización en pantalla como documento impreso es uno de los más utilizados
    119 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
    120 verificable por los visores más populares como el de \textit{Adobe Reader}\copyright.
    121 
    122 También existen estándares para archivos con firma electrónica basados en XML. La ventaja de estos
    123 formatos es que pueden integrar  metadatos como la fecha y lugar de la(s) firma(s), y permiten
    124 incluir diferentes tipos de archivos  como fotos, videos, documentos de texto u ofimáticos. Entre los estándares XML más conocidos está el
    125 XMLDsig \cite{IEEEhowto:xmldsig}.
    126 Este estándar cuenta con diferentes implementaciones y extensiones, entre ellas el formato creado por las repúblicas bálticas
    127 llamado BDOC \cite{IEEEhowto:bdoc}, que sigue a su vez el popular estándar OpenDocument, utilizado por el paquete ofimático OpenOffice como formato
    128 principal para sus archivos.
    129 
    130 
    131 
    132 
    133 
    134 \section{Antecedentes}
    135 
    136 La inclusión de la firma electrónica en un proceso de negocio tiene varios aspectos asociados. Se
    137 pueden señalar como los más relevantes la ergonomía
    138 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.
    139 
    140 
    141 En relación con el tema de la ergonomía Xyzmo SIGNificant\footnote{Para ver información completa
    142 sobre Xyzmo Significant visitar la dirección web: http://www.xyzmo.com} es una novedosa propuesta. Xyzmo es una aplicación comercial
    143 de código fuente propietario, que introduce elementos innovadores en el área de ergonomía y adaptación al cambio:
    144 no obliga a aprender una nueva técnica de firma sino que ofrece a los usuarios
    145 de esta tecnología el uso de la firma
    146 manuscrita a través de una tableta electrónica o teléfono con interfaz multitoque (multitouch) bajo sistemas operativos
    147 Android\copyright \hspace{0.2cm}y iOS\copyright, esto sin desvincularse del esquema PKI. Este modelo proporciona al usuario la metáfora de
    148 la firma manuscrita mostrando el documento tal cual como si fuese impreso, habilitando la firma electrónica avanzada  a través del
    149 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
    150 como ritmo, velocidad o características del trazo, y  también técnicas criptográficas estandarizas vinculadas
    151 al esquema PKI.
    152 
    153 Existen diferentes implementaciones  de software para las  gestión y visualización de los
    154 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
    155 para este tipo de archivo, por ejemplo, el Adobe Reader\copyright \hspace{0.2cm}
    156 que visualiza la firma electrónica o digital como un sello (imagen) dentro del
    157 documento,
    158  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,
    159 pero que en muchos casos son necesarias para la elaboración de documentos formales o legales.
    160 En el caso de los formatos XML la visualización no es automática, por lo tanto si se requiere visualizar
    161 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
    162 para documentos XML que necesitan por disposiciones legales o formales de gobierno aplicar forma a documentos
    163 firmados electrónicamente.
    164 
    165 Una de las potencialidades de la firma electrónica es su integración con sistemas informáticos para la
    166 mejora de procesos mediante la eliminación de puntos lentos. Es por ello que los temas
    167 de integración y arquitectura juegan un papel preponderante. En esta tendencia se inscribe el proyecto \textit{@firma}:
    168 una solución desarrollada por el Ministerio de Hacienda y Administraciones Públicas de España,
    169  que se plantea como una plataforma de firma electrónica orientada a brindar servicios de gobierno electrónico, y que está integrada
    170 con el sistema de identificación Español. Cuenta con
    171 una aplicación de escritorio que puede usarse en diversos sistemas operativos, y un \textit{applet} \cite{IEEEhowto:java}  para usar la firma
    172 a través de la web. Estas características habilitan a \textit{@firma} para el desarrollo de aplicaciones de gobierno
    173 electrónico, así como también para la integración con sistemas empresariales.
    174 
    175 
    176 
    177 \section{Acoplamiento de la firma electrónica avanzada}
    178 
    179 
    180 
    181 La conexión entre un  componente (software) y el sistema informático se denomina acoplamiento. Este procedimiento debe cumplir con un
    182 conjunto de requisitos que tienen que ver con  características
    183 tales como reutilización, cohesión y la exportación de una interfaz definida.
    184 A continuación se describen los elementos desarrollados en este trabajo.
    185 
    186 
    187 \subsection{Componente de firma electrónica avanzada}
    188 
    189 Se desarrolló un componente que permite realizar diferentes operaciones
    190 asociadas con la firma electrónica: subir un documento desde el computador cliente;
    191 realizar la firma utilizando una tarjeta inteligente con PIN (contraseña) desde el computador cliente y
    192 entregar un archivo firmado en formato XAdES\cite{IEEEhowto:xades}  al programa servidor. El componente se ha denominado
    193 de firma electrónica avanzada (ComponenteFEA), ya que cumple con las condiciones citadas  en la sección \ref{sec:modelo}  sobre este tipo
    194 de firma.
    195 
    196 
    197 Las funcionalidades que implementa el ComponenteFEA son las siguientes:
    198 \begin{enumerate}
    199  \item Firmar electrónicamente (para este caso se asume que lo electrónico está
    200 asociado a un dispositivo en hardware como una tarjeta inteligente, y
    201  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}.
    202 \item Firmar digitalmente 
    203 (usando un archivo PKCS\#12 \cite{IEEEhowto:pkcs12}) un documento de tipo de
    204 archivo definido por especificación MIME .
    205 \item Verificar un archivo firmado electrónicamente  usando o no validación OCSP.
    206 \item  Verificar un archivo firmado digitalmente  usando o no validación OCSP.
    207 \item Mostrar propiedades como algoritmos utilizados, fecha y lugar de la firma de un archivo firmado
    208  \item Firmar electrónicamente utilizando un componente para el navegador  un documento de tipo de archivo definido por
    209 especificación MIME.
    210 \end{enumerate}
    211  
    212 
    213 \begin{verbatim}
     34 \section{Introducción}
     35 \label{sec:intro}
     36 La adopción de la tecnología de firma electrónica aún no está suficientemente extendida.
     37 É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.
     38 Vinculado a este hecho, surge la pregunta ¿Pueden converger estas dos tecnologías en un futuro próximo?
     39 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.
     40 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.
     41
     42
     43 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.
     44 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.
     45 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.
     46 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.
     47
     48 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.
     49
     50 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.
     51
     52
     53
     54 \section{El modelo actual de firma electrónica}
     55 \label{sec:modelo}
     56
     57 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.
     58 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.
     59 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}.
     60
     61 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.
     62 De este dominio se ocupan las organizaciones que están bajo el esquema PKI, que funcionan como terceros de confianza.
     63 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.
     64 El certificado es un documento -un archivo- que autentifica la clave vinculada al ente.
     65 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.
     66 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).
     67
     68
     69 El segundo dominio corresponde a las aplicaciones que usa el propietario del certificado para aplicar la firma electrónica, y que generan valor agregado.
     70 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.
     71 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.
     72 Las aplicaciones de este tipo más utilizadas son navegadores web y clientes de correo electrónico.
     73
     74 Por otro lado, se han especificado diferentes formatos estándares de archivo con firma autocontenida.
     75 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.
     76 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.
     77
     78 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.
     79 Entre los estándares XML más conocidos está el XMLDsig \cite{IEEEhowto:xmldsig}.
     80 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.
     81
     82
     83
     84
     85
     86 \section{Antecedentes}
     87
     88 La inclusión de la firma electrónica en un proceso de negocio tiene varios aspectos asociados.
     89 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.
     90
     91
     92 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.
     93 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.
     94 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.
     95
     96 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.
     97 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.
     98 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.
     99
     100 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.
     101 Es por ello que los temas de integración y arquitectura juegan un papel preponderante.
     102 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.
     103 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.
     104 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.
     105
     106
     107
     108 \section{Acoplamiento de la firma electrónica avanzada}
     109
     110
     111
     112 La conexión entre un componente (software) y el sistema informático se denomina acoplamiento.
     113 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.
     114 A continuación se describen los elementos desarrollados en este trabajo.
     115
     116
     117 \subsection{Componente de firma electrónica avanzada}
     118
     119 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.
     120 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.
     121
     122
     123 Las funcionalidades que implementa el ComponenteFEA son las siguientes:
     124 \begin{enumerate}
     125 \item
     126  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}.
     127 \item
     128  Firmar digitalmente (usando un archivo PKCS\#12 \cite{IEEEhowto:pkcs12}) un documento de tipo de archivo definido por especificación MIME .
     129 \item
     130  Verificar un archivo firmado electrónicamente usando o no validación OCSP.
     131 \item
     132  Verificar un archivo firmado digitalmente usando o no validación OCSP.
     133 \item
     134  Mostrar propiedades como algoritmos utilizados, fecha y lugar de la firma de un archivo firmado
     135 \item
     136  Firmar electrónicamente utilizando un componente para el navegador un documento de tipo de archivo definido por especificación MIME.
     137 \end{enumerate}
     138
     139
     140 \begin{verbatim}
    214141
    215142class BDocDocument : QObject {
    … …  
    244171    void saveDocument(int docId...);
    245172
    246 
    247 }
    248 \end{verbatim}
    249 \begin{center} \textbf{Listado 1.} API del ComponenteFEA en C++ accesible desde \textit{python}
    250 \end{center}
    251 
    252 Bajo esta perspectiva  se propone tratar las funcionalidades
    253 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)
    254 que puede ser utilizada de forma  encapsulada y separada por una aplicación anfitrión,
    255 escrita teóricamente en cualquier lenguaje de programación.
    256 Una de las aplicaciones que trabaja bajo este esquema de complementos o
    257 componentes es el navegador web, este  diseño ha permitido
    258 contar con grandes repositorios que extienden las funcionalidades del navegador casi para cualquier uso.
    259 
    260 \begin{figure}[htb]
    261 \centering
     173  }
     174 \end{verbatim}
     175 \begin{center}
     176  \textbf{Listado 1.} API del ComponenteFEA en C++ accesible desde \textit{python}
     177 \end{center}
     178
     179 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.
     180 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.
     181
     182 \begin{figure}[htb]
     183  \centering
    262184%\includegraphics[width=8cm]{imagenes/uml.png}
    263 \includegraphics[scale=1]{imagenes/uml.jpeg}
    264 \caption{Diagrama UML de acoplamiento}
    265 \label{fig:uml}
    266 \end{figure}
    267 
    268 La figura \ref{fig:uml} muestra un diagrama en lenguaje UML del componente y su conexión con un sistema
    269 informático. Existen tres tipos de funcionalidades que exporta el ComponenteFEA:
    270 ``Firmar'', interfaces para firma electrónica y digital;
    271 ``Validar'', interfaces para validación fuera de línea y en línea de
    272 certificados electrónicos; y ``Gestionar'', interfaces para el almacenamiento
    273 y búsqueda de archivos firmados.
    274 
    275 
    276 A nivel de lenguaje de programación se provee un paquete o \textit{package} para \textit{python} que está construido envolviendo
    277  una librería de firma electrónica avanzada escrita en lenguaje \textit{C/C++}.
    278 El listado \textbf{1}  muestra los métodos que son accesibles desde \textit{python}.
    279 
    280 
    281 
    282 \subsection{Método de conexíón}
    283 
    284 
    285 El diagrama de flujo de la figura \ref{fig:acoplamiento} muestra los pasos a seguir para incorporar el ComponenteFEA
    286  dentro de un proceso de una organización.  Los primeros dos pasos de este diagrama  corresponden a la 
    287 identificación de  los puntos de firma y validación dentro del proceso de negocio,
    288 para luego conectar los métodos (mensajes)  correspondientes del ComponenteFEA  en dichos puntos.
    289 
    290 
    291 
    292 \begin{figure}[htb]
    293 \centering
     185  \includegraphics[scale=1]{imagenes/uml.jpeg}
     186  \caption{Diagrama UML de acoplamiento}
     187  \label{fig:uml}
     188 \end{figure}
     189
     190 La figura \ref{fig:uml} muestra un diagrama en lenguaje UML del componente y su conexión con un sistema informático.
     191 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.
     192
     193
     194 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++}.
     195 El listado \textbf{1} muestra los métodos que son accesibles desde \textit{python}.
     196
     197
     198
     199 \subsection{Método de conexíón}
     200
     201
     202 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.
     203 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.
     204
     205
     206
     207 \begin{figure}[htb]
     208  \centering
    294209%\includegraphics[width=8cm]{imagenes/flujoComponenteFE.jpg}
    295 \includegraphics[scale=1]{imagenes/flujoComponente.jpeg}
    296 \caption{Diagrama de flujo para el acoplamiento del ComponenteFEA}
    297 \label{fig:acoplamiento}
    298 \end{figure}
    299 
    300 
    301 En un siguiente paso y dependiendo del tipo de proceso a automatizar se adoptará un esquema de conexión para el
    302 servidor.  En esta fase se establecen algunos aspectos importantes relativos al sistema
    303 informático a colocar en funcionamiento, entre estos están la existencia de un sistema automatizado,
    304 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.
    305 
    306 
    307 En este punto el desarrollador tiene la libertad
    308 de utilizar el componente de firma
    309 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
    310 seleccionar para el desarrollo de software el lenguaje
    311 \textit{Python}.  Para el caso anterior o si el sistema se implementó utilizando
    312 este lenguaje se sigue el paso 7.1 de la figura \ref{fig:acoplamiento} que
    313 corresponde
    314 con la instalación del componente ''servidor`` para la firma electrónica avanzada.
    315 
    316 
    317 En el caso de que los procesos de negocio se encuentren automatizados bajo un lenguaje
    318 diferente a \textit{Python}, se utiliza la interfaz de  servicios
    319 web\footnote{La interfaz de servicios web
    320 está disponible en:
    321 http://bazaar.launchpad.net/\~esignature/esignature/bdoc/files/head:/server/}
    322 que provee el ComponenteFEA (Paso 8.1 de la figura \ref{fig:acoplamiento}).
    323 
    324 
    325 
    326 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
    327 \textit{.bdoc}. Para este fin puede utilizarse un directorio en el sistema de archivos o un gestor de  base de datos relacional. En este
    328 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
    329 metadatos en los registros de las tablas de la base de datos relacional, o simplemente
    330 asignar un nombre como clave única a los archivos firmados.
    331 
    332 
    333 
    334 
    335 Como último paso se debe habilitar un módulo para gestionar los archivos firmados (paso 9 de la figura \ref{fig:acoplamiento}), es decir,
    336 proveer una interfaz de usuario para las acciones
    337  de visualización de propiedades de  archivos, validación
    338 de firmas electrónica, búsqueda, entre otras. Estas funcionalidades las provee el ComponenteFEA
    339 mediante los métodos que se nombran en la sección
    340 ``Métodos para Gestión de archivos'' del Listado \textbf{1},
    341 y pueden ser extendidas utilizando algunas de las funcionalidades del gestor de datos que se utilice.
    342 
    343 
    344 \section{Casos de estudio}
    345 
    346 A continuación se muestran tres casos de integración utilizando un mismo proceso con diversos sistemas informáticos.
    347 El proceso tratado es el conocido como ``Orden de compra'', el cual está presente en muchas organizaciones.
    348 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
    349 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
    350 se puede describir así:
    351 \begin{enumerate}
    352  \item Generar una requisición o documento de solicitud para el conjunto de productos o servicios
    353 \begin{itemize}
    354  \item Firma del solicitante
    355 \end{itemize}
    356  \item Obtener por los menos n  $(n\geq2)$  cotizaciones para el conjunto de productos o servicios
    357 \item Seleccionar una cotización y generar un acta
    358 \begin{itemize}
    359  \item Firma del analista de compras
    360 \end{itemize}
    361 \item Generar una orden de compra
    362 \begin{itemize}
    363  \item Firma del gerente del departamento
    364 \end{itemize}
    365 \end{enumerate}
    366 
    367 Generalmente este proceso se lleva a cabo utilizando firmas manuscritas en coordinación con un sistema informático:
    368 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.
    369 
    370 Para el caso de estudio planteado se  puede sustituir  la primera, la segunda  o las tres  firmas manuscritas por sus respectivas firmas electrónicas.
    371 También es posible agregar firmas electrónicas en puntos donde no existen firmas manuscritas.
    372 
    373 La segunda funcionalidad a conectar del ComponenteFEA es la validación de los documentos firmados electrónicamente.
    374  Para ello se identifican los puntos donde se actualiza la información
    375 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.
    376 
    377 Después del proceso de identificación, para  cada punto que se determinó en la fase anterior,  se incorporan  los métodos
    378 del ComponenteFEA con llamadas locales o remotas  según sea el caso. A
    379 continuación se presentas tres implementaciones del proceso
    380 ``Orden de compra'' para tres sistemas informáticos diferentes.
    381 
    382 
    383 \subsection{Caso OpenERP }
    384 
    385 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,
    386 que tiene un gran número de instalaciones. En su base incluye el proceso de  ``Orden de compra''. Para realizar el acoplamiento se creó
    387 un nuevo módulo
    388 de OpenERP. Se identificaron los puntos de firma y validación y se sustituyeron por las llamadas
    389 respectivas al ComponenteFEA. Como elemento agregado se creó un nuevo módulo
    390 basado en bandejas de documentos -archivos generados por OpenERP-
    391 (similar a las usadas en los clientes de correo electrónico)
    392 asociadas a los documentos a ser firmados electrónicamente.
    393 
    394 
    395 La figura \ref{fig:openerp} muestra la interfaz de usuario para gestionar los archivos firmados electrónicamente. Los usuarios autorizados pueden utilizar una
    396 tarjeta inteligente para firmar los documentos correspondientes al proceso de
    397 ``Orden de compra'', teniendo la misma validez legal (especificado por
    398 las políticas de la PKI y la legislación del país) que la firma manuscrita.
    399  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
    400   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
    401 lo firma  para aprobar la compra del conjunto de productos o servicios seleccionados.
    402 
    403 
    404 OpenERP provee al desarrollador patrones Modelo-Vista-Controlador (MVC) y un motor de flujo de trabajos o \textit{Workflow} para implementar nuevas funcionalidades.
    405 Usando estas herramientas los documentos firmados se vinculan al modelo de datos y las validaciones de firma electrónica se realizan
    406 extendiendo el flujo de trabajo relacionado con el proceso ``Orden de compra'' base de OpenERP.
    407 
    408 
    409 \begin{figure}[htb]
    410 \centering
    411 \includegraphics[scale=1]{imagenes/openerp.jpeg}
    412 \caption{Interfaz de usuario OpenERP para el ComponenteFEA}
    413 \label{fig:openerp}
    414 \end{figure}
    415 
    416 
    417 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
    418 parte del complemento Web que debe ser instalado en el cliente (navegador) y que tiene interacción con el certificado firmante contenido en una
    419 tarjeta inteligente.
    420 
    421 
    422 
    423 \subsection{Caso SAID}
    424 
    425 
    426 SAID\footnote{Ver la dirección web: http://said.cenditel.gob.ve/wiki } es un sistema administrativo que incluye procesos contables
    427 y administrativos para instituciones que operen en el sector público venezolano.
    428 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.
    429 
    430 El sistema fue escrito en PHP Versión 4.X, y
    431 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,
    432 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
    433  \textbf{2} muestra
    434 las llamadas que se insertaron en el código fuente para extender el sistema de tal manera que funcione con firmas electrónicas avanzadas.
    435  El repositorio de archivos firmados a utilizar es
    436 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
    437 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
    438 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
    439 la firma, y finalmente se listan todos los firmantes  utilizando el método  ``subjectCertificateCommonName''.
    440 
    441 \begin{verbatim}
     210  \includegraphics[scale=1]{imagenes/flujoComponente.jpeg}
     211  \caption{Diagrama de flujo para el acoplamiento del ComponenteFEA}
     212  \label{fig:acoplamiento}
     213 \end{figure}
     214
     215
     216 En un siguiente paso y dependiendo del tipo de proceso a automatizar se adoptará un esquema de conexión para el servidor.
     217 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.
     218
     219
     220 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.
     221 Si el proceso no se encuentra automatizado se recomienda seleccionar para el desarrollo de software el lenguaje \textit{Python}.
     222 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.
     223
     224
     225 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}).
     226
     227
     228
     229 Un tema a tomar en cuenta es el relativo al tipo de repositorio donde se almacenan los archivos firmados.
     230 El ComponenteFEA genera archivos tipo XAdES con extensión \textit{.bdoc}.
     231 Para este fin puede utilizarse un directorio en el sistema de archivos o un gestor de base de datos relacional.
     232 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.
     233 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.
     234
     235
     236
     237
     238 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.
     239 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.
     240
     241
     242 \section{Casos de estudio}
     243
     244 A continuación se muestran tres casos de integración utilizando un mismo proceso con diversos sistemas informáticos.
     245 El proceso tratado es el conocido como ``Orden de compra'', el cual está presente en muchas organizaciones.
     246 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.
     247 El proceso en pasos se puede describir así:
     248 \begin{enumerate}
     249 \item
     250  Generar una requisición o documento de solicitud para el conjunto de productos o servicios
     251  \begin{itemize}
     252  \item
     253   Firma del solicitante
     254  \end{itemize}
     255 \item
     256  Obtener por los menos n
     257  $(n\geq2)$ cotizaciones para el conjunto de productos o servicios
     258 \item
     259  Seleccionar una cotización y generar un acta
     260  \begin{itemize}
     261  \item
     262   Firma del analista de compras
     263  \end{itemize}
     264 \item
     265  Generar una orden de compra
     266  \begin{itemize}
     267  \item
     268   Firma del gerente del departamento
     269  \end{itemize}
     270 \end{enumerate}
     271
     272 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.
     273
     274 Para el caso de estudio planteado se puede sustituir la primera, la segunda o las tres firmas manuscritas por sus respectivas firmas electrónicas.
     275 También es posible agregar firmas electrónicas en puntos donde no existen firmas manuscritas.
     276
     277 La segunda funcionalidad a conectar del ComponenteFEA es la validación de los documentos firmados electrónicamente.
     278 Para ello se identifican los puntos donde se actualiza la información sobre la firma manuscrita.
     279 Una tercera funcionalidad es la que tiene que ver con la visualización de los atributos de los documentos firmados electrónicamente.
     280
     281 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.
     282 A continuación se presentas tres implementaciones del proceso ``Orden de compra'' para tres sistemas informáticos diferentes.
     283
     284
     285 \subsection{Caso OpenERP }
     286
     287 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.
     288 En su base incluye el proceso de ``Orden de compra''.
     289 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.
     290
     291
     292 La figura \ref{fig:openerp} muestra la interfaz de usuario para gestionar los archivos firmados electrónicamente.
     293 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.
     294 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.
     295 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.
     296
     297
     298 OpenERP provee al desarrollador patrones Modelo-Vista-Controlador (MVC) y un motor de flujo de trabajos o \textit{Workflow} para implementar nuevas funcionalidades.
     299 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.
     300
     301
     302 \begin{figure}[htb]
     303  \centering \includegraphics[scale=1]{imagenes/openerp.jpeg}
     304  \caption{Interfaz de usuario OpenERP para el ComponenteFEA}
     305  \label{fig:openerp}
     306 \end{figure}
     307
     308
     309 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.
     310 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.
     311
     312
     313
     314 \subsection{Caso SAID}
     315
     316
     317 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.
     318 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.
     319
     320 El sistema fue escrito en PHP Versión 4.X, y es de código libre.
     321 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.
     322 El repositorio de archivos firmados a utilizar es PostgreSQL Version 8.4 (El mismo que utiliza SAID).
     323 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.
     324 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''.
     325
     326 \begin{verbatim}
    442327 <?php
    443328
    … …  
    476361}
    477362?>
    478 \end{verbatim} \begin{center} \textbf{Listado 2.} Conexión mediante servicios web-rpc desde SAID al ComponenteFEA
    479 \end{center}
    480 
    481 
    482 De forma similar al caso OpenERP, se provee un complemento para el navegador de tal manera que los usuarios puedan
    483 realizar la firma de forma remota, utilizando una tarjeta inteligente desde su estación de trabajo. Luego el documento
    484 se procesa por el sistema SAID, y se almacena en la base de datos del servidor.
    485 
    486 \subsection{Caso Flujos de Trabajo}
    487 
    488 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
    489 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
    490 SAFET \cite{IEEEhowto:safet}, ya que incorpora
    491 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
    492 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
    493 código fuente, solo se especifica en el archivo de definición de flujo.
    494 
    495 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
    496 el \textit{NombreComunUsuario} debe firmar electrónicamente el documento de requisición para pasar a la siguiente actividad
    497 que en este caso se denominada \textit{Cotización}.
    498 La sentencia \textit{vRequisicion \textbf{SIGN} NombreComunUsuario} indica al motor de flujo de trabajo lo descrito anteriormente.
    499 
    500 
    501 \begin{verbatim}
    502 <task id="Requisicion"
    503  title="Acción de solicitud de bien o servicio" >
    504 <port side="forward" type="split" >
    505 <connection source="Cotización"
    506 query="vRequisicion SIGN NombreComunUsuario"
    507 options="" >
    508 </connection>
    509 </port>
    510 <variable id="vRequisicion" scope="task"
    511 tokenlink=""
    512 documentsource="select  id,
    513 nombre,descripcion,
    514 fechageneracion
    515 from requisiciones" >
    516 </variable>
    517 </task>
    518 \end{verbatim}  \begin{center} \textbf{Listado 3.} Tarea de firma de requisición usando SAFET (XML)
    519 \end{center}
    520 
    521 
    522 
    523 
    524 \section{Conclusiones}
    525 
    526 En un mediano plazo la firma electrónica avanzada  puede consolidarse como una tecnología fundamental en los procesos
    527 de negocio ya que propone la digitalización de un elemento  imprescindible en este contexto como lo es la firma manuscrita.
    528 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
    529 de archivo de firma electrónica y la ergonomía para el uso de esta tecnología.
    530 
    531 En este trabajo se detalla un método para la integración de un componente de software con sistemas informáticos
    532 que automatizan procesos de negocio. En la fase de  acoplamiento se define la identificación
    533 de puntos de firma electrónica, se especifica la  validación de los certificados firmantes por una PKI,
    534 se muestra la habilitación del navegador web para la firma electrónica (basada en tarjetas inteligentes)
    535 a través de un complemento y se discute sobre los parámetros de seguridad de los formatos de firma electrónica.
    536 Las tareas como la construcción de un gestor de archivos firmados se proponen como una actividad  complementaria.
    537 
    538 
    539 Con la finalidad de mostrar la aplicación del método  propuesto en sistemas en situaciones reales se mostraron tres casos de estudio,
    540 cada uno con sus particularidades.
    541  El acoplamiento del ComponenteFEA con los sistemas
    542 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
    543 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.
    544 
    545 
    546 El análisis de vulnerabilidades  es un tema omnipresente en el área
    547 de seguridad informática, y está relacionado con este trabajo a través del análisis de los formatos, protocolos y
    548 tecnologías utilizados en el proceso de integración.
    549 
    550 Existen otros aspectos que no se discuten en este trabajo pero que se consideran importantes para la  aprehensión de la
    551 tecnología de firma electrónica. Entre ellos se pueden señalar la mejora de  la experiencia del usuario 
    552 y la visualización de  los archivos de formato XML firmados electrónicamente.
    553 
    554 En el tema específico de integración, en \cite{IEEEhowto:eID} se discute sobre la necesidad de
    555 abrir el compás de aplicaciones
    556 compatibles con la tecnología de Firma Electrónica Avanzada, y en general, sobre la asunción de un nuevo paradigma en el despliegue
    557 de procesos de negocio.
     363 \end{verbatim}
     364 \begin{center}
     365  \textbf{Listado 2.} Conexión mediante servicios web-rpc desde SAID al ComponenteFEA
     366 \end{center}
     367
     368
     369 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.
     370 Luego el documento se procesa por el sistema SAID, y se almacena en la base de datos del servidor.
     371
     372 \subsection{Caso Flujos de Trabajo}
     373
     374 El proceso especificado en esta sección puede modelarse usando un motor de flujo de trabajo.
     375 Los flujos de trabajo son ampliamente utilizados para modelar procesos a través de un lenguaje descriptivo como BPM o BPEL \cite{IEEEhowto:bpel}.
     376 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.
     377 La validación la realiza el motor de forma automática.
     378 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.
     379
     380 El listado \textbf{3} muestra la definición de la acción de firma electrónica en un flujo de trabajo (SAFET).
     381 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}.
     382 La sentencia \textit{vRequisicion \textbf{SIGN} NombreComunUsuario} indica al motor de flujo de trabajo lo descrito anteriormente.
     383
     384
     385 \begin{verbatim}
     386  <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>
     387 \end{verbatim}
     388 \begin{center}
     389  \textbf{Listado 3.} Tarea de firma de requisición usando SAFET (XML)
     390 \end{center}
     391
     392
     393
     394
     395 \section{Conclusiones}
     396
     397 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.
     398 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.
     399
     400 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.
     401 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.
     402 Las tareas como la construcción de un gestor de archivos firmados se proponen como una actividad complementaria.
     403
     404
     405 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.
     406 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.
     407
     408
     409 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.
     410
     411 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.
     412 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.
     413
     414 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.
    558415
    559416
    … …  
    563420
    564421% el siguiente comando establece la ubicación de las referencias
    565 \putbib[bibliografia]
     422 \putbib[bibliografia]
    566423
    567424% el siguiente comando cierra el ambiente bibunit para la cual se generan las
    … …  
    571428
    572429
    573  
     430
    574431
    575432
Note: See TracChangeset for help on using the changeset viewer.