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

revisionfinal
Last change on this file since d8108d6 was d8108d6, checked in by aaraujo <aaraujo@…>, 10 years ago

Modificados archivos .tex de capítulos para hacer referencia a imágenes actualizadas.

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