source: libros/maquetacion/capitulo6/capitulo6.tex @ c0dca75

revisionfinal
Last change on this file since c0dca75 was 147fb25, checked in by Antonio Araujo Brett <aaraujo@…>, 10 years ago

En el directorio maquetacion del control de versiones se agregaron todos los archivos fuentes con la nueva plantilla LaTeX del formato del libro.

  • Property mode set to 100644
File size: 36.2 KB
Line 
1\chapter{Firmas Electr\'onicas}
2\chapterauthors{V. Bravo y A. Araujo
3\chapteraffil{Fundación Centro Nacional de Desarrollo e Investigación en Tecnologías Libres}
4}
5
6
7A continuación el contenido del artículo de componente de firmas electrónicas
8
9
10
11
12
13%\begin{abstract}
14Automation is use the information technologies as a direct method for improvement. However, there are elements such as handwritten signature that
15have been taken of all the digital area, but which, when recurrent events in organizational processes
16stand as a critical factor in the flow of operations.
17In response to this situation have developed numerous standards and technologies grouped by
18Electronic Signature concepts and PKI, but that in turn have discovered new questions in this field, among them,
19those that have to do with the integration processes.
20In this paper we propose a software component and a method for connecting
21computer systems as essential technology using the Advanced Electronic Signature. In this sense
22addresses the document formats, validation infrastructure,
23and safety conditions that ensure legal support. The work has
24center, the details and problems of integration, and that have been grouped under ``coupling joint`` concept.
25%\end{abstract}
26%\begin{keywords} Advanced Electronic Signatures, Component, XAdES, PKI, workflow.
27%\end{keywords}
28
29
30
31
32\section{Introducción}
33\label{sec:intro}
34  La adopción de la tecnología de firma electrónica  aún no está suficientemente extendida. Esta
35se utiliza en distintas áreas y en muchas  instituciones o empresas alrededor del mundo pero no ha llegado a ser
36equivalente a la firma autógrafa en un sentido amplio. Vinculado a este hecho, surge la pregunta ¿Pueden converger
37estas dos tecnologías en un futuro próximo?. Con la finalidad de responder esta interrogante,
38se puede decir que la herramienta electrónica  debe tener  por lo menos tres  características comunes
39a la autógrafa: identificar a la persona que la realiza; declarar la asunción u obligatoriedad de cumplimiento (contrato)
40del contenido de lo que se firma y por último, servir  como prueba de autenticidad o no repudio del firmante.
41El modelo de firma electrónica basado en una infraestructura PKI (siglas en inglés de
42Infraestructura de Clave Pública), ha sido jurídicamente aceptado en muchos países,
43lo que equivale a decir que en estos casos se cumple con las características antes mencionadas.
44
45
46La firma manuscrita se percibe como un elemento tecnológico desacoplado, esto es, no dependiente de otra tecnología o factor (solo
47se necesita papel y lápiz)  que
48puede usarse casi en cualquier lugar y con aceptación universal. En cambio la firma electrónica requiere de elementos de software
49(manejadores de dispositivos, clientes de firma, etc) y hardware (lector de tarjetas, tarjeta inteligente, computador, tableta o móvil),
50adicionalmente  y por lo general se debe contar con una conexión a internet para la validación. Otra ventaja importante
51de la firma manuscrita es la permanencia de factores biométricos que son fundamentales en la realización
52de auditorías confiables. A pesar de todas  estas ventajas, en los últimos años ha crecido el uso de la firma electrónica,
53Gobiernos 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
54inteligente (smartcard) como elemento de identificación personal ha apoyado este crecimiento.
55
56En este punto se plantean nuevos  problemas vinculados al hecho de introducir o  sustituir el elemento físico o autógrafo
57por el elemento electrónico,
58entre estos podemos señalar:  elección del formato
59o formatos de archivo de los documentos firmados; ubicuidad y ergonomía de la acción de firma; verificación de los documentos
60firmados; histórico o archivo de documentos firmados y finalmente la  integración de la firma con sistemas de base de datos relacionales, mapeos
61objetos-relacionales, servicios web, entre otros elementos utilizados en sistemas informáticos actuales.
62
63En este sentido, este trabajo  plantea un método para integrar un componente\cite{IEEEhowto:software}  de Firma Electrónica Avanzada   denominado
64ComponenteFEA a procesos de negocio, teniendo presente parámetros de seguridad, rapidez y auditabilidad.
65
66
67
68\section{El modelo actual de Firma Electrónica}
69\label{sec:modelo}
70
71Una de las acciones  para dar soporte jurídico a la firma electrónica y lograr su equivalencia con la firma manuscrita es
72fijar unas condiciones iniciales que garanticen integridad y auditabilidad de los documentos firmados, y que
73puedan ser validadados a través de un estándar. Bajo este enfoque, se ha creado el concepto de Firma Electrónica Avanzada,
74que por definición debe contar con las siguientes propiedades  a) estar vinculada al firmante de  manera única; b) permitir la identificación del firmante;
75c) haber sido creada
76utilizando medios que el firmante puede mantener bajo su exclusivo control y d) estar vinculada a los datos a que se refiere
77de modo que cualquier cambio ulterior de los mismos sea detectable.  La formalización de esta idea  ha sido llevado a cabo principalmente
78por el Parlamento Europeo,
79y se describe en la directiva  1999/93/EC \cite{IEEEhowto:directiva}. .
80
81Existen 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
82identificación, registro, emisión  y validación de certificados electrónicos. De este dominio se ocupan 
83las organizaciones que están bajo el esquema PKI, que funcionan como terceros de confianza. Cada certificado brinda identidad
84a 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
85es un documento -un archivo-
86que autentifica la clave vinculada al ente. La clave secreta/privada se distribuye en una tarjeta inteligente
87o token criptográfico que funciona como un elemento de control de
88acceso de nivel 2. Los certificados electrónicos contienen información especificada  bajo el formato X.509v3 \cite{IEEEhowto:x509}, el cual
89incluye campos como  fecha de expedición y vencimiento del certificado, Nombre único del propietario (conocido como Nombre Común),
90datos del Proveedor del certificado, datos criptográficos del certificado y datos del servidor de validación, conocido como OCSP
91(Online Certificate Status Protocol, por sus siglas en inglés).
92
93
94El segundo dominio corresponde a las  aplicaciones que usa el propietario del certificado para aplicar
95la firma electrónica, y que generan valor agregado. Las aplicaciones de este tipo más utilizadas  cuentan con
96una interfaz basada en bibliotecas dinámicas (.dll o .so) para este fin, así como también tienen un archivo de certificados
97de autoridades de certificación para validar la vigencia y correctitud del certificado del firmante. Esta interfaz
98es básica, solo permite generar un archivo de firma en formato PKCS\#7\cite{IEEEhowto:pkcs7} separado del documento firmado, lo que conlleva
99a que las tareas de almacenamiento, validación y auditoría  deben ser provistas  adicionalmente a través de un programa
100o complemento de software. Las aplicaciones de este tipo más utilizadas son navegadores web y clientes de correo electrónico.
101
102Por otro lado, se han especificados diferentes formatos estándares de archivo con firma autocontenida. Por ejemplo el formato PDF
103dada sus características de solo lectura y visualización en pantalla como documento impreso es uno de los más utilizados
104para 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
105verificable por los visores más populares como el de \textit{Adobe Reader}\copyright.
106
107También existen estándares para archivos con firma electrónica basados en XML. La ventaja de estos
108formatos es que pueden integrar  metadatos como la fecha y lugar de la(s) firma(s), y permiten
109incluir diferentes tipos de archivos  como fotos, videos, documentos de texto u ofimáticos. Entre los estándares XML más conocidos está el
110XMLDsig \cite{IEEEhowto:xmldsig}.
111Esta estándar cuenta con diferentes implementaciones y extensiones, entre ellas el formato creado por las repúblicas bálticas
112llamado BDOC\cite{IEEEhowto:bdoc}, que sigue a su vez el popular estándar OpenDocument, utilizado por el paquete ofimático OpenOffice como formato
113principal para sus archivos.
114
115
116
117
118
119\section{Antecedentes}
120
121La inclusión de la firma electrónica en un proceso de negocio tiene varios aspectos asociados. Se
122pueden señalar como los más relevantes la ergonomía
123de 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.
124
125
126En relación con el  tema de la ergonomía   Xyzmo SIGNificant\footnote{Para ver información completa
127sobre Xyzmo Significant visitar la dirección web: http://www.xyzmo.com} es una novedosa propuesta. Xyzmo es una una aplicación comercial
128de código fuente propietario, que introduce elementos innovadores en el área de ergonomía y adaptación al cambio:
129no obliga a aprender una nueva técnica de firma sino que ofrece a los usuarios de esta tecnología el uso la firma
130manuscrita a través de una tableta electrónica o teléfono con interfaz multitoque (multitouch) bajo sistemas operativos
131Android\copyright \hspace{0.2cm}y iOS\copyright, esto sin desvincularse del esquema PKI. Este modelo proporciona al usuario la metáfora de
132la firma manuscrita mostrando el documento tal cual como si fuese impreso, habilitando la firma electrónica avanzada  a través del
133uso  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
134como ritmo, velocidad o características del trazo, y  también técnicas criptográficas estandarizas vinculadas
135al esquema PKI.
136
137Existen diferentes implementaciones  de software para las  gestión y visualización de los
138dos 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
139para este tipo de archivo, por ejemplo, el Adobe Reader\copyright \hspace{0.2cm} visualiza la firma electrónica o digital como un sello (imagen) dentro del documento,
140 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,
141pero que en muchos casos son necesarias para la elaboración de documentos formales o legales.
142En el caso de los formatos XML la visualización no es automática, por lo tanto si se requiere visualizar
143el contenido con elementos de forma se debe disponer de un software visualizador que formatee el contenido. En \cite{IEEEhowto:neubauer} se muestra una propuesta
144para documentos XML que necesitan por disposiciones legales o formales de gobierno aplicar forma a documentos
145firmados electrónicamente.
146
147Una de las potencialidades de la firma electrónica es su integración con sistemas informáticos para la
148mejora de procesos mediante la eliminación de puntos lentos. Es por ello que los temas
149de integración y arquitectura juegan un papel preponderante. En esta tendencia se inscribe el proyecto \textit{@firma}:
150una solución desarrollada por el Ministerio de Hacienda y Administraciones Públicas de España,
151 que se plantea como una plataforma de firma electrónica orientada a brindar servicios de gobierno electrónico, y que está integrada
152con el sistema de identificación Español. Cuenta con
153una aplicación de escritorio que puede usarse en diversos sistemas operativos, y un \textit{applet}\cite{IEEEhowto:java}  para usar la firma
154a través de la web. Estas características habilitan a \textit{@firma} para el desarrollo de aplicaciones de gobierno
155electrónico, así como también para la integración con sistemas empresariales.
156
157
158
159\section{Acoplamiento de la Firma Electrónica Avanzada}
160
161
162
163La conexión entre un  componente (software) y el sistema informático se denomina acoplamiento. Este procedimiento debe cumplir con un
164conjunto de requisitos que tienen que ver con  características
165tales como reutilización, cohesión y la exportación de una interfaz definida.
166A continuación se describen los elementos desarrollados en este trabajo.
167
168
169\subsection{Componente de Firma Electrónica Avanzada}
170
171Se desarrolló un componente que permite realizar diferentes operaciones
172asociadas con la firma electrónica: subir un documento desde el computador cliente;
173realizar la firma utilizando una tarjeta inteligente con PIN (contraseña) desde el computador cliente y
174entregar un archivo firmado en formato XAdES\cite{IEEEhowto:xades}  al programa servidor. El componente se ha denominado
175de Firma Electrónica Avanzada (ComponenteFEA), ya que cumple con las condiciones citadas  en la sección \ref{sec:modelo}  sobre este tipo
176de firma.
177
178
179Las funcionalidades que implementa el ComponenteFEA son las siguientes:
180\begin{enumerate}
181 \item Firmar electrónicamente (para este caso se asume que lo electrónico está asociado un dispositivo en hardware como una tarjeta inteligente. y
182 en relación a ello debe connotar vinculación jurídica, lo digital solo a una clave en software) un documento de tipo de archivo definido por especificación MIME\cite{IEEEhowto:mime}.
183\item Firmar digitalmente 
184(usando un archivo PKCS\#12\cite{IEEEhowto:pkcs12}) un documento de tipo de archivo definido por especificación MIME .
185\item Verificar un archivo firmado electrónicamente  usando o no validación OCSP.
186\item  Verificar un archivo firmado digitalmente  usando o no validación OCSP.
187\item Mostrar propiedades como algoritmos utilizados, fecha y lugar de la firma de un archivo firmado
188 \item Firmar electrónicamente utilizando un componente para el navegador  un documento de tipo de archivo definido por
189especificación MIME.
190\end{enumerate}
191 
192
193\begin{verbatim}
194
195class BDocDocument : QObject {
196// *** Métodos para firma electrónica
197    BDocDocument();
198    void init();
199    void create( const QString file );
200    bool openBDocContainer(const QString path);
201    void saveBDocContainer(const QString path);     
202    bool signWithP12(const QString  profile,...);
203    void addDocument(const QString path);
204
205// ** Mètodos de firma por navegador web
206    bool presignWeb(const QString  profile, ...);
207    bool postsignWeb(const QString  profile, ...);
208
209
210// ** Métodos para validación
211    QString signatureAlgorithm(int index );
212    bool validateOffline() const ;
213
214// ** Métodos para Gestión de archivos
215    QString signatureFormat(int index );
216    QString signatureDateTime(int index );
217    QStringList signatureLocation(int index );
218    QString signatureRol(int index );
219    QString signatureDigestMethod(index )
220    QString subjectCertificateCommonName(int i);
221    QString documentName(int docId);
222    int documentCount();
223    int signatureCount();
224    void saveDocument(int docId...);
225
226
227}
228\end{verbatim}
229\begin{center} \textbf{Listado 1.} API del ComponenteFEA en C++ accesible desde \textit{python}
230\end{center}
231
232Bajo esta perspectiva  se propone tratar las funcionalidades
233 asociadas a la Firma Electrónica Avanzada, es decir, empaquetar las funcionalidades  exportando una API (por su siglas en inglés Interfaz
234de Programación de Aplicaciones) que puede ser utilizada de forma  encapsulada y separada por una aplicación anfitrión,
235escrita teóricamente en cualquier lenguaje de programación.
236Uno de las aplicaciones que trabaja bajo este esquema de complementos o componentes es el navegador web, este  diseño ha permitido
237contar con grandes repositorios que extienden las funcionalidades del navegador casi para cualquier uso.
238
239\begin{figure}[htb]
240\centering
241\includegraphics[width=8cm]{imagenes/uml.png}
242\caption{Diagrama UML de acoplamiento}
243\label{fig:uml}
244\end{figure}
245
246La figura \ref{fig:uml} muestra un diagrama en lenguaje UML del componente y su conexión con un sistema
247informático. Existen tres tipos de funcionalidades que exporta el ComponenteFEA: ''Firmar'', interfaces para firma electrónica y digital,
248''Validar``, interfaces para validación fuera de línea y en línea de certificados electrónicos, y ''Gestionar``, interfaces para la almacenamiento
249y búsqueda de archivos firmados.
250
251
252A nivel de lenguaje de programación se provee un paquete o \textit{package} para \textit{python} que está construido envolviendo
253 una librería de firma electrónica avanzada escrita en lenguaje \textit{C/C++}.
254El listado \textbf{1}  muestra los métodos que son accesibles desde \textit{python}.
255
256
257
258\subsection{Método de conexíón}
259
260
261El diagrama de flujo de la figura \ref{fig:acoplamiento} muestra los pasos a seguir para incorporar el ComponenteFEA
262 dentro de un proceso de una organización.  Los primeros dos pasos de este diagrama  corresponden a la 
263identificación de  los puntos de firma y validación dentro del proceso de negocio,
264para luego conectar los métodos (mensajes)  correspondientes del ComponenteFEA  en dichos puntos.
265
266
267
268\begin{figure}[htb]
269\centering
270\includegraphics[width=8cm]{imagenes/flujoComponenteFE.jpg}
271\caption{Diagrama de flujo para el acoplamiento del ComponenteFEA}
272\label{fig:acoplamiento}
273\end{figure}
274
275
276En un siguiente paso y dependiendo del tipo de proceso a automatizar se adoptará un esquema de conexión para el
277servidor.  En esta fase se establecen algunos aspectos importantes relativos al sistema
278informático a colocar en funcionamiento, entre estos están la existencia de un sistema automatizado,
279el 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.
280
281
282En este punto el desarrollador tiene la libertad
283de utilizar el componente de firma
284según su criterio, sin embargo, puede seguir algunas pautas  relacionadas con el  proceso a automatizar.  Si el proceso no se encuentra automatizado se recomienda
285seleccionar para el desarrollo de software el lenguaje
286\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
287corresponde
288con la instalación del componente ''servidor`` para la Firma Electrónica Avanzada.
289
290
291En el caso de que los procesos de negocio se encuentren automatizados bajo un lenguaje
292diferente a \textit{python}, se utilizan la interfaz de  servicios web\footnote{La interfaz de servicios web
293está disponible en: http://bazaar.launchpad.net/\~esignature/esignature/bdoc/files/head:/server/} que provee del ComponenteFEA (Paso 8.1 de la figura \ref{fig:acoplamiento}).
294
295
296
297Un 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
298\textit{.bdoc}. Para este fin puede utilizarse un directorio en el sistema de archivos o un gestor de  base de datos relacional. En este
299punto también hay que trabajar sobre el nombramiento, 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
300metadatos en los registros de las tablas de la base de datos relacional, o simplemente
301asignar un nombre como clave única a los archivos firmados.
302
303
304
305
306Como último paso se debe habilitar un módulo para gestionar los archivos firmados (paso 9 de la figura \ref{fig:acoplamiento}), es decir,
307proveer una interfaz de usuario para las acciones
308 de visualización de propiedades de  archivos, validación
309de firmas electrónica, búsqueda, entre otras. Estas funcionalidades las provee el ComponenteFEA
310mediante los métodos que se nombran en la sección
311''Métodos para Gestión de archivos`` del Listado \textbf{1},
312y pueden ser extendidas utilizando algunas de las funcionalidades del gestor de datos que se utilice.
313
314
315\section{Casos de estudio}
316
317A continuación se muestran tres casos de integración utilizando un mismo proceso con diversos sistemas informáticos.
318El proceso tratado es el conocido como ''Orden de compra``, el cuál está presente en muchas organizaciones.
319Consiste 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
320un 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
321se puede describir así:
322\begin{enumerate}
323 \item Generar una requisición o documento de solicitud para el conjunto de productos o servicios
324\begin{itemize}
325 \item Firma del solicitante
326\end{itemize}
327 \item Obtener por los menos n  $(n\geq2)$  cotizaciones para el conjunto de productos o servicios
328\item Seleccionar una cotización y generar un acta
329\begin{itemize}
330 \item Firma del analista de compras
331\end{itemize}
332\item Generar una orden de compra
333\begin{itemize}
334 \item Firma del gerente del departamento
335\end{itemize}
336\end{enumerate}
337
338Generalmente este proceso se lleva a cabo utilizando firmas manuscritas en coordinación con un sistema informático:
339se 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.
340
341Para el caso de estudio planteado se  puede sustituir  la primera, la segunda  o las tres  firmas manuscritas por sus respectivas firmas electrónicas.
342También es posible agregar firmas electrónicas en puntos donde no existen firmas manuscritas.
343
344La segunda funcionalidad a conectar del ComponenteFEA es la validación de los documentos firmados electrónicamente.
345 Para ello se identifican los puntos donde se actualiza la información
346sobre 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.
347
348Después del proceso de identificación, para  cada punto que se determinó en la fase anterior,  se incorporan  los métodos
349del ComponenteFEA con llamadas locales o remotas  según sea el caso. A continuación se presenta tres  implementaciones del proceso
350''Orden de compra`` para tres sistemas informáticos diferentes.
351
352
353\subsection{Caso OpenERP }
354
355OpenERP\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,
356que tiene un gran número de instalaciones. En su base incluye el proceso de  ''Orden de compra``. Para realizar el acoplamiento se creó
357un nuevo módulo
358de OpenERP. Se identificaron los puntos de firma y validación y se sustituyeron por las llamadas
359respectivas al ComponenteFEA. Como elemento agregado, se creó un nuevo módulo basado en bandejas de documentos -archivos generados por OpenERP-
360(similar a las usadas en los clientes de correo electrónico)
361asociadas a los documentos a ser firmados electrónicamente.
362
363
364La figura \ref{fig:openerp} muestra la interfaz de usuario para gestionar los archivos firmados electrónicamente. Los usuarios autorizados pueden utilizar una
365tarjeta inteligente para firmar los documentos correspondientes al proceso de ''Orden de compra``, teniendo la misma validez legal (especificado por
366las políticas de la PKI y la legislación del país) que la firma manuscrita.
367 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
368  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
369lo firma  para aprobar la compra del conjunto de productos o servicios seleccionados.
370
371
372OpenERP provee al desarrollador patrones Modelo-Vista-Controlador (MVC) y un motor de flujo de trabajos o \textit{Workflow} para implementar nuevas funcionalidades.
373Usando estas herramientas los documentos firmados se vinculan al modelo de datos y las validaciones de firma electrónica se realizan
374extendiendo el flujo de trabajo relacionado con el proceso ``Orden de compra'' base de OpenERP.
375
376
377\begin{figure}[htb]
378\centering
379\includegraphics[width=8cm]{imagenes/openerp.png}
380\caption{Interfaz de usuario OpenERP para el ComponenteFEA}
381\label{fig:openerp}
382\end{figure}
383
384
385La ú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
386parte del complemento Web que debe ser instalado en el cliente (navegador) y que tiene interacción con el certificado firmante contenido en una
387tarjeta inteligente.
388
389
390
391\subsection{Caso SAID}
392
393
394SAID\footnote{Ver la dirección web: http://said.cenditel.gob.ve/wiki } es un sistema administrativo que incluye procesos contables
395y administrativos para instituciones que operen en el sector público venezolano.
396Entre los procesos que implementa SAID está el de `Orden de compra``, que incluye entre sus capacidades la posibilidad de utilizar firmas digitales basadas en el formato  PKCS\#7.
397
398El sistema fue escrito en PHP Versión 4.X, y
399es de código libre. Los puntos de firma y validación están claramente identificados, ya que son los indicados por las firmas digitales,
400en 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
401 \textbf{2} muestra
402las llamadas que se insertaron en el código fuente para extender el sistema de tal manera que funcione con firmas electrónicas avanzadas.
403 El repositorio de archivos firmados a utilizar es
404PostgreSql 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
405documento 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
406a abrir un archivo firmado el método ''openBDocContainer`` a través de una llamada remota, luego se utiliza el método ''validateSignature`` para validar
407la firma, y finalmente se listan todos los firmantes  utilizando el método  ''subjectCertificateCommonName``.
408
409\begin{verbatim}
410 <?php
411
412include('xmlrpc.php');
413
414$connec = new XMLRPCClient('localhost:4242');
415$identificador = 'prueba1';
416$connec->__call('init', array($identificador));
417$connec->__call('openBDocContainer',
418array($identificador,
419'detalle_curso.odt.bdoc'));
420$resp = $connec->__call('signatureCount',
421array($identificador));
422$firmantes = Array();
423for($pos=0; $pos<$resp; $pos++)
424{       
425        $datos = Array();
426        $valida = 'No válido';
427        if($connec->__call('validateSignature',
428array($identificador,$pos)))
429        {
430           $valida = 'Válido';
431           $nombre = 
432 $connec->
433   __call('subjectCertificateCommonName',
434array($identificador,$pos));
435           $firmantes[] = array('nombre'=> $nombre,
436'valida'=>$valida);
437        }
438}
439
440for($i=0;$i<count($firmantes);$i++)
441{
442        echo "{$firmantes[$i]['nombre']}
443{$firmantes[$i]['valida']}\n";
444}
445?>
446\end{verbatim} \begin{center} \textbf{Listado 2.} Conexión mediante servicios web-rpc desde SAID al ComponenteFEA
447\end{center}
448
449
450De forma similar al caso OpenERP, se provee un complemento para el navegador de tal manera que los usuarios puedan
451realizar la firma de forma remota, utilizando una tarjeta inteligente desde su estación de trabajo. Luego el documento
452se procesa por el sistema SAID, y se almacena en la base de datos del servidor.
453
454\subsection{Caso Flujos de Trabajo}
455
456El 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
457a 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
458SAFET\cite{IEEEhowto:safet}, ya que incorpora
459el 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
460automá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
461código fuente, solo se especifica en el archivo de definición de flujo.
462
463\begin{verbatim}
464<task id="Requisicion"
465 title="Acción de solicitud de bien o servicio" >
466<port side="forward" type="split" >
467<connection source="Cotización"
468query="vRequisicion SIGN NombreComunUsuario"
469options="" >
470</connection>
471</port>
472<variable id="vRequisicion" scope="task"
473tokenlink=""
474documentsource="select  id,
475nombre,descripcion,
476fechageneracion
477from requisiciones" >
478</variable>
479</task>
480\end{verbatim}  \begin{center} \textbf{Listado 3.} Tarea de firma de requisición usando SAFET (XML)
481\end{center}
482
483El 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
484el \textit{NombreComunUsuario} debe firmar electrónicamente el documento de requisición para pasar a la siguiente actividad
485que en este caso se denominada \textit{Cotización}.
486La sentencia \textit{vRequisicion \textbf{SIGN} NombreComunUsuario} indica al motor de flujo de trabajo lo descrito anteriormente.
487
488
489\section{Conclusiones}
490
491En un mediano plazo la Firma Electrónica Avanzada  puede consolidarse como una tecnología fundamental en los procesos
492de negocio ya que propone la digitalización de un elemento  imprescindible en este contexto como lo es la firma manuscrita.
493Los retos de la digitalización son diversos y complejos, y tienen que ver con aspectos disímiles como lo son por ejemplo los formatos
494de archivo de firma electrónica y la ergonomía para el uso de esta tecnología.
495
496En este trabajo se detalla un método para la integración de un componente de software con sistemas informáticos
497que automatizan procesos de negocio. En la fase de  acoplamiento se define la identificación
498de puntos de firma electrónica, se especifica la  validación de los certificados firmantes por una PKI,
499se muestra la habilitación del navegador web para la firma electrónica (basada en tarjetas inteligentes) 
500a través de un complemento y se discute sobre los parámetros de seguridad de los formatos de firma electrónica.
501Las tareas como la construcción de un gestor de archivos firmados se proponen como una actividad  complementaria.
502
503
504Con la finalidad de mostrar la aplicación del método  propuesto en sistemas en situaciones reales se mostraron tres casos de estudio,
505cada uno con sus particularidades.
506 El acoplamiento del ComponenteFEA con los sistemas
507informáticos OpenERP, SAID y SAFET siguen el método descrito en el trabajo, evaluando para todos los casos especialmente el tipo de conexión
508a 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.
509
510
511El análisis de vulnerabilidades  es un tema omnipresente en el área
512de seguridad informática, y está relacionado con este trabajo a través del análisis de los formatos, protocolos y
513tecnologías utilizados en el proceso de integración.
514
515Existen otros aspectos que no se discuten en este trabajo pero que se consideran importantes para la  aprehensión de la
516tecnología de firma electrónica. Entre ellos se pueden señalar la mejora de  la experiencia del usuario 
517y la visualización de  los archivos de formato XML firmados electrónicamente.
518
519En el tema específico de integración, en \cite{IEEEhowto:eID} se discute sobre la necesidad de
520abrir el compás de aplicaciones
521compatibles con la tecnología de Firma Electrónica Avanzada, y en general, sobre la asunción de un nuevo paradigma en el despliegue
522de procesos de negocio.
523
524
525
526
527
528
529 
530
531
532\begin{thebibliography}{1}
533
534
535\bibitem{IEEEhowto:neubauer}
536Neubauer, T.; Weippl, E.; Biffl, S., "Digital signatures with familiar appearance for e-government documents: authentic PDF," Availability,
537Reliability and Security, 2006. ARES 2006. The First International Conference on , vol., no., pp.8 pp.,, 20-22 April 2006
538
539\bibitem{IEEEhowto:software}
540Campderrich Falgueras, Benet. Ingeniería del Software. Editorial UOC. Barcelona, España. 2003.
541
542
543\bibitem{IEEEhowto:directiva}
544DIRECTIVA 1999/93/CE DEL PARLAMENTO EUROPEO Y DEL CONSEJO. Diciembre 1999. Disponible en: http://www.cert.fnmt.es/legsoporte/D\_1999\_93\_CE.pdf
545
546\bibitem{IEEEhowto:x509}
547Cooper 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.
548Disponible en: http://www.ietf.org/rfc/rfc5280.txt. Febrero 2013.
549
550\bibitem{IEEEhowto:xades}
551Cruellas, J. Karlinger G., y otros. XML Advanced Electronic Signatures (XAdES). W3C Note 20 February 2003.
552
553\bibitem{IEEEhowto:xmldsig}
554Bartel M., Boyer J., y otros. XML Signature Syntax and Processing (Second Edition). W3C Recommendation 10 June 2008.
555Disponible en: http://www.w3.org/TR/xmldsig-core/. Febrero 2013.
556
557
558\bibitem{IEEEhowto:pki}
559Duane. N. Brink, J. PKI: Infraestructura de Clave Pública. McGrawHill 2002.
560
561\bibitem{IEEEhowto:bpel}
562Matjaz Juric, Mathew Benny. Business Process Execution for Web Services BPEL and BPEL4WS. 2 Ed. Packt Publishing. 2006.
563
564
565\bibitem{IEEEhowto:safet}
566Bravo, 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.
567
568\bibitem{IEEEhowto:pkcs7}
569PKCS\#7.Cryptographic Message Syntax. Disponible en: https://tools.ietf.org/html/rfc2315. Febrero 2013.
570
571\bibitem{IEEEhowto:mime}
572Security Multiparts for MIME. Multipart/Signed and Multipart/Encrypted. Disponible en: http://tools.ietf.org/html/rfc1847. Febrero 2013.
573
574\bibitem{IEEEhowto:pkcs12}
575PKCS\#12.Personal Information Exchange Syntax Standard. RSA Laboratories. Disponible en: https://www.rsa.com/rsalabs/node.asp?id=2138. Febrero 2013.
576
577
578\bibitem{IEEEhowto:pades}
579PAdES. PDF Advance Electronic Signatures. Disponible en: http://www.etsi.org/deliver/etsi\_ts/
580102700\_102799/10277801/01.01.01\_60/ts\_10277801v010101p.pdf. Febrero 2013.
581
582\bibitem{IEEEhowto:java}
583Richardson Clay, Avondolio Donald, others. Professional Java, JDK. 5th Edition. Wrox. February. 2005.
584
585
586\bibitem{IEEEhowto:bdoc}
587Formato para firmas electrónicas. Disponible en: http://www.signature.it/-TOOLS/Bdoc-1.0.pdf. Febrero 2013.
588
589
590\bibitem{IEEEhowto:eID}
591Andreas Poller, Ulrich Waldmann, Sven Vowe, Sven Turpe, Electronic Identity Cards for User Authentication
592Promise and Practice, IEEE Security \& Privacy, vol. 10, no. 1, pp. 46-54, January/February, 2012
593
594\bibitem{IEEEhowto:espana}
595Portal del DNI Electrónico Español. Disponible en: http://www.dnielectronico.es/. Febrero 2013.
596
597\bibitem{IEEEhowto:estonia}
598Oficial Gateway to Estonia. Disponible en: http://estonia.eu/about-estonia/economy-a-it/e-estonia.html. Febrero 2013.
599
600\end{thebibliography}
601
602%\begin{IEEEbiography}[{\includegraphics[width=1in,height=1.25in,clip,keepaspectratio]{victor.png}}]{Víctor Bravo}
603Ví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.
604Ha trabajado como director en importantes
605proyectos vinculados a procesos de Certificación Electrónica masiva tal como ''Software de Gestión Autoridad Raíz de la
606PKI Pública Nacional``. Ha dictado conferencias sobre temas de certificación electrónica en varios países. Actualmente está
607adscrito 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
608Departamento de Computación de la ULA.
609%\end{IEEEbiography}
610
611
612%\begin{IEEEbiography}[{\includegraphics[width=1in,height=1.25in,clip,keepaspectratio]{antonioaraujo.jpg}}]{Antonio Gregorio Araujo Brett}
613Antonio Araujo es Ingeniero de Sistemas, egresado de la Universidad de Los Andes, en
614Mérida, Venezuela. Actualmente
615cursa estudios de Maestría en Computación de la Facultad de Ingeniería
616de la Universidad de Los
617Andes. Ha asesorado
618proyectos de certificación
619electrónica y participado como ponente en varias jornadas y congresos de
620certificación electrónica y
621firmas electrónicas en el país.
622Se desempeña desde el año 2007 como Analista de la gestión de
623desarrollado en Tecnologías Libres de
624la Fundación Centro Nacional de Desarrollo e Investigación en
625Tecnologías Libres – CENDITEL Nodo
626Mérida.
627%\end{IEEEbiography}
628
629%\begin{IEEEbiography}[{\includegraphics[width=1in,height=1.25in,clip,keepaspectratio]{jogerquintero.jpg}}]{Joger André Quintero Escalante}
630
631Joger Quintero es Técnico Superior en Informática, egresado del Instituto Universitario Tecnológico de Ejido, en
632Ejido, Venezuela.  Se desempeña como Analista Desarrollador en CENDITEL(Nodo Mérida) desde el año 2011.
633%\end{IEEEbiography}
634
Note: See TracBrowser for help on using the repository browser.