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