Changeset 82b7928 in libros for maquetacion/capitulo5/capitulo5.tex
- Timestamp:
- Apr 30, 2014, 5:50:58 PM (10 years ago)
- Branches:
- master, revisionfinal
- Children:
- afed176
- Parents:
- d61ff5c (diff), 05ec937 (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent. - File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
maquetacion/capitulo5/capitulo5.tex
raab7301 rd61ff5c 1 \chapter{Certificaci\'on Electr\'onica} 1 %\chapter{Certificaci\'on Electr\'onica} 2 3 \chapter{Desarrollo de una aplicaci\'on para Gesti\'on de una Autoridad de Certificaci\'on Ra\'iz bajo Est\'andar X.509 utilizando Software Libre} 4 2 5 \label{capitulo5} 6 3 7 \chapterauthors{V. Bravo y A. Araujo 4 8 \chapteraffil{Fundación Centro Nacional de Desarrollo e Investigación en Tecnologías Libres} … … 6 10 7 11 8 La gestión de certificados electrónicos de una Infraestructura 9 de Clave Pública (ICP) para establecer identidades digitales se conoce como 10 Certificación Electrónica. Entre los procesos de gestión están la generación, 11 almacenamiento y publicación de certificados, así como la publicación de información 12 y consulta del estado de vigencia y validez de los mismos. 13 14 En la sección \ref{subsubsection:certificadosElectronicos} se presentó el 15 certificado electrónico como un documento electrónico que permite establecer 16 la identidad digital de personas y/o dispositivos. 12 % Desarrollo de una aplicación para Gestión de una Autoridad de Certificación Raíz bajo Estándar X.509 utilizando Software Libre 13 14 % La gestión de certificados electrónicos de una Infraestructura 15 % de Clave Pública (ICP) para establecer identidades digitales se conoce como 16 % Certificación Electrónica. Entre los procesos de gestión están la generación, 17 % almacenamiento y publicación de certificados, así como la publicación de información 18 % y consulta del estado de vigencia y validez de los mismos. 19 % 20 % En la sección \ref{subsubsection:certificadosElectronicos} se presentó el 21 % certificado electrónico como un documento electrónico que permite establecer 22 % la identidad digital de personas y/o dispositivos. 17 23 18 24 … … 27 33 seguridad física y lógica, de la clave privada que permite la generación de estos certificados. 28 34 29 %Este trabajo muestra el proceso de desarrollo de una aplicación para gestionar el 30 En este capítulo se describe el proceso de desarrollo de una aplicación para gestionar 31 una Autoridad de Certificación Raíz utilizando bibliotecas, herramientas, compiladores, 35 Este trabajo muestra el proceso de desarrollo de una aplicación para gestionar 36 una Autoridad de Certificación Raíz utilizando bibliotecas, herramientas, compiladores, 32 37 sistemas operativos y licencias compatibles con los principios del software libre. 33 38 En primer lugar, se determinan los requisitos a ser satisfechos en función de una 34 39 descripción general de las funciones y características de una Autoridad de 35 Certificación; posteriormente, se dise ~nan funcionalidades y se especifican36 requisitos, con el objetivo de producir 37 automatizar. Se dedica una sección de este capítuloa la implementación que consiste40 Certificación; posteriormente, se diseñan funcionalidades y se especifican 41 requisitos, con el objetivo de producir una visión formal de los procesos a 42 automatizar. Se dedica una sección a la implementación que consiste 38 43 en la codificación en un lenguaje de programación, de los procesos previstos en las 39 44 etapas anteriores, como también, de la incorporación de mecanismos fuertes de … … 49 54 50 55 %\begin{abstract} 51 %A Certification Authority Root (CA Root) is a component which role is to represent the highest confidence point in a hierarchical structure denominated Public Key Infrastructure (PKI). A PKI provides people, IP addresses and Web domains with digital certificates under X.509 standard, offering logic security and legal entailment to transactions performed on the internet by the certificate’s owner. Confidence resides in private key protection through strong physical and logical security schemes, so these schemes allow the certificate emission. This work shows the development process of a CA root management application. For this development it's used libraries, tools, compilers, operating systems and licenses compatible with the principles of free software. In first place, the requirements to satisfy are determined based on a general description of a CA's functions and characteristics; subsequently, functionalities are designed and requirements are specified in order to produce a formal vision of the processes 52 %to automate. A section is dedicated to the implementation, this consists on codification in a programming language of the processes forseen in the previous stages, like also, of the incorporation of strong mechanisms of validation of identity of users, registry of events, actions signature by application's administrators, and connections specification with specialized hardware, like smart cards. Finally, application display and configuration are shown, it involves its installation in a safe environment (vault or data center) and CA Root connection with other components of the infrastructure. 56 %A Certification Authority Root (CA Root) is a component which role is to represent the highest 57 % confidence point in a hierarchical structure denominated Public Key Infrastructure (PKI). 58 % A PKI provides people, IP addresses and Web domains with digital certificates under X.509 59 % standard, offering logic security and legal entailment to transactions performed on the 60 % internet by the certificate’s owner. Confidence resides in private key protection through 61 % strong physical and logical security schemes, so these schemes allow the certificate emission. 62 % This work shows the development process of a CA root management application. For this development 63 % it's used libraries, tools, compilers, operating systems and licenses compatible with the 64 % principles of free software. In first place, the requirements to satisfy are determined 65 % based on a general description of a CA's functions and characteristics; subsequently, 66 % functionalities are designed and requirements are specified in order to produce a formal 67 % vision of the processes 68 %to automate. A section is dedicated to the implementation, this consists on codification 69 % in a programming language of the processes forseen in the previous stages, like also, 70 % of the incorporation of strong mechanisms of validation of identity of users, registry 71 % of events, actions signature by application's administrators, and connections 72 % specification with specialized hardware, like smart cards. Finally, application display 73 % and configuration are shown, it involves its installation in a safe environment 74 % (vault or data center) and CA Root connection with other components of the infrastructure. 53 75 %\end{abstract} 54 76 … … 59 81 \section{Introducción} 60 82 61 \label{sec:intro}La disponibilidad de Internet como medio digital seguro permite62 que cualquier persona, empresa, institución, o administración realice transacciones83 \label{sec:intro}La disponibilidad de Internet como medio digital %seguro permite 84 permite que cualquier persona, empresa, institución, o administración realice transacciones 63 85 gubernamentales, comerciales o personales en la mayoría de los casos, tal cual, 64 86 como se realizarían en una oficina o espacio físico de forma presencial. Dado este … … 86 108 87 109 Cuando se traslada el concepto de identidad al medio informático, se habla de 88 identidad digital, y se hace necesario contar c redenciales traducibles a110 identidad digital, y se hace necesario contar con credenciales traducibles a 89 111 información binaria. Por otro lado, la criptografía, por sí misma no proporciona este 90 112 concepto: es el uso de una infraestructura computacional que utiliza algoritmos … … 103 125 proceso desarrollo de la aplicación de gestión, y que están vinculados con los 104 126 principios del software libre y los requisitos muy particulares del ambiente 105 de despliegue, subrayan los objetivos propuestos en este capítulo. %de este trabajo.127 de despliegue, subrayan los objetivos propuestos de este trabajo. 106 128 107 129 \section{Marco Teórico} … … 131 153 Igual que para la disponibilidad, los usuarios pueden ser personas, procesos o 132 154 programas. Para evitar que nadie no autorizado pueda tener acceso a la información 133 transferida y que recorre la Red se utilizan técnicas de cifrado o codificación de155 transferida y que recorre la red se utilizan técnicas de cifrado o codificación de 134 156 datos. Hay que mantener una cierta coherencia para determinar cuál es el grado de 135 157 confidencialidad de la información que se está manejando, para así evitar un esfuerzo … … 141 163 Mediante una firma electrónica se codifican los mensajes a transferir, de forma que una 142 164 función, denominada hash \cite{ACE:03}, calcula un resumen de dicho mensaje y se 143 le a ~nade. La validación de la integridad del mensaje se realiza aplicándole al original la144 misma función y comparando el resultado con el resumen que se a ~nadió al final cuando165 le añade. La validación de la integridad del mensaje se realiza aplicándole al original la 166 misma función y comparando el resultado con el resumen que se añadió al final cuando 145 167 se calculó por primera vez antes de enviarlo. 146 168 Mantener la integridad es importante para verificar que en el tiempo de viaje por 147 la Red de la información entre el sitio emisor y receptor ningún agente externo o169 la red de la información entre el sitio emisor y receptor ningún agente externo o 148 170 extra\~no ha modificado el mensaje. 149 171 150 172 \subsection{Criptografía} 151 La criptografía es la ciencia o arte información utilizando técnicas matemáticas173 La criptografía es la ciencia o arte de ocultar información utilizando técnicas matemáticas 152 174 que hagan posible el intercambio de mensajes de manera que sólo puedan ser leídos 153 175 por las personas o usuarios autorizados \cite{STAL:03}. La criptografía ha tomado 154 gran importancia en los últimos a ~nos, ya que es posible transformar las176 gran importancia en los últimos años, ya que es posible transformar las 155 177 ``técnicas matemáticas'' en algoritmos que pueden ser comprendidos por una computadora. 156 178 Se puede clasificar la criptografía en dos tipos, según el tipo de clave que se utilice: … … 186 208 conoce como certificado autofirmado. 187 209 Dado que los certificados son información pública y lo que se desea es que todos 188 tengan acceso a ellos, pueden hacerse copias del certificado de acuerdo sea necesario. 210 tengan acceso a ellos, pueden hacerse copias del certificado %de acuerdo sea necesario. 211 para su distribución. 189 212 Los certificados electrónicos permiten varias cosas, entre ellas se pueden citar que los 190 usuarios pueden a ~nadir firmas electrónicas a los formularios en línea; que los213 usuarios pueden añadir firmas electrónicas a los formularios en línea; que los 191 214 destinatarios pueden comprobar la autenticidad del correo electrónico confidencial; 192 que los compradores pueden estar seguros de que un websitees legítimo; y por último,193 controla el acceso a bancos y comercios online, así como los intranets y extranets.215 que los compradores pueden estar seguros de que un sitio web es legítimo; y por último, 216 controla el acceso a bancos y comercios en línea, así como las intranets y extranets. 194 217 195 218 \subsection{Estándar X.509} … … 197 220 198 221 X.509 y X.500 fueron originalmente dise\~nados a mediados de los a\~nos 80, antes 199 del enorme crecimiento de usuarios en Internet. Es por esto por lo que se222 del enorme crecimiento de usuarios en la Internet. Es por esto por lo que se 200 223 dise\~naron para operar en un ambiente donde sólo los computadores se interconectaban 201 224 intermitentemente entre ellos. En las versiones 1 y 2 de X.509 se utiliza una … … 215 238 incluso incluir dentro de elemento físico, como una tarjeta inteligente. 216 239 Los certificados en el formato X.509 v3 contienen datos del sujeto, 217 como su nombre, dirección, correo electrónico, etc. (Ver Fig. \ref{fig:estandarx509}) 240 como su nombre, dirección, correo electrónico, etc. La figura \ref{fig:estandarx509} 241 muestra un bosquejo de la especificación del estándar X.509 versión 3. 218 242 219 243 En la versión 3 de X.509, no hace falta aplicar restricciones sobre la estructura … … 264 288 tener la seguridad de que el fichero que reciben o se descargan, proviene exclusivamente 265 289 de una empresa determinada. Con ello se evitan los problemas causados por la 266 suplantación de personalidad y la distribución de objetos da\~ninos o perjudiciales290 suplantación de identidad y la distribución de objetos da\~ninos o perjudiciales 267 291 bajo esta supuesta identidad. Cualquier modificación (por ejemplo: inclusión de un 268 292 troyano o infección de un virus) sobre el software original lo invalidará, con lo que el … … 278 302 permite diseñar sistemas a través de modelos, que se componen de un conjunto 279 303 de símbolos y diagramas en donde se plasma las ideas de funcionalidad. 280 El UML fue creado por Grady Booch, James Rumbaugh e Ivar Jacobson en el a ~no304 El UML fue creado por Grady Booch, James Rumbaugh e Ivar Jacobson en el año 281 305 1997\cite{SCHM:03},\cite{BOOC:99} y \cite{MULL:97}. Cada diagrama tiene fines distintos 282 306 dentro del proceso de desarrollo, su finalidad es presentar diversas perspectivas 283 de un sistema. La clave está en organizar el proceso de dise ~no de tal forma que los analistas,307 de un sistema. La clave está en organizar el proceso de diseño de tal forma que los analistas, 284 308 clientes, desarrolladores y otras personas involucradas en el desarrollo del modelo 285 309 lo comprendan y convengan con él. Los diagramas que componen el lenguaje son: … … 296 320 \end{itemize} 297 321 298 %En este trabajo se utilizaron esencialmente los diagramas de clases, los diagramas de 299 En este capítulo se utilizaron esencialmente los diagramas de clases, los diagramas de 322 En este trabajo se utilizaron esencialmente los diagramas de clases, los diagramas de 300 323 casos de uso y los diagramas de actividades, que se describen brevemente a continuación: 301 324 … … 322 345 por siempre; 2) Libertad de estudiarlo y adaptarlo a nuestras necesidades; 323 346 3) Libertad de redistribuirlo a cualquiera, logrando ayudar a un amigo o vecino; 324 y por último 4) laLibertad de mejorar el programa y publicar las mejoras.347 y por último 4) la Libertad de mejorar el programa y publicar las mejoras. 325 348 326 349 Las libertades antes expuestas, proveen muchos beneficios a los usuarios finales. … … 359 382 \item Autoridad de Certificación (AC): es el nodo central de la infraestructura, 360 383 se encarga de los procedimientos de firma, renovación y revocación de 361 certificados digitales. El procedimiento de firma de certificados utiliza384 certificados electrónicos. El procedimiento de firma de certificados utiliza 362 385 la clave privada de la AC. 363 386 \item Interfaz con los clientes (PUB): es el nodo que brinda toda la información … … 370 393 Los nodos de una ICP pueden ordenarse según diversos modelos. El más utilizado es 371 394 el modelo jerárquico, que presenta una raíz y nodos hijos que distribuyen los 372 certificados a los clientes o entidades finales (Ver Fig. \ref{fig:jerarquia}).373 Se muestra un ejemplo de modelo de jerarquía de una ICP de cuatro niveles,395 certificados a los clientes o entidades finales. En la figura \ref{fig:jerarquia} 396 se muestra un ejemplo de modelo de jerarquía de una ICP de cuatro niveles, 374 397 que se encuentra en el tercer nivel del modelo, que certifica a los usuarios. 375 398 … … 381 404 \end{figure} 382 405 383 Este modelo de establecimiento de relaciones de confianza, es necesari aentre406 Este modelo de establecimiento de relaciones de confianza, es necesario entre 384 407 múltiples autoridades de certificación para garantizar que los usuarios 385 408 (entidades finales) no tengan que depender y confiar en una sola AC, algo que haría … … 394 417 En los párrafos siguientes se discuten los aspectos, procesos y técnicas 395 418 principales, que se siguen a lo largo del desarrollo de la aplicación (software) 396 de gestión del componente Autoridad CertificadoraRaíz.419 de gestión del componente Autoridad de Certificación Raíz. 397 420 398 421 … … 417 440 418 441 La diferencia de escala de los dos tipos de AC conlleva a que la AC Raíz tenga 419 características particulares, que tienen que ver los niveles y elementos de seguridad442 características particulares, que tienen que ver con los niveles y elementos de seguridad 420 443 tanto físicos como lógicos que deben considerarse en la gestión del componente. 421 444 Por ejemplo, la desconexión de red del equipo donde se ejecuta la aplicación de … … 445 468 446 469 La etapa de dise\~no consiste en elaborar diagramas formales que permitan en la etapa 447 de implementación representarrequisitos y procesos de la gestión del componente AC Raíz470 de implementación la representación de requisitos y procesos de la gestión del componente AC Raíz 448 471 en un lenguaje de programación. Para el dise\~no de requisitos se utilizan los diagramas 449 de casos de uso del lenguaje UML, que muestran una primera aproximación las operaciones472 de casos de uso del lenguaje UML, que muestran una primera aproximación de las operaciones 450 473 que se deben realizar en relación con las entradas dadas por los usuarios. Los actores 451 (usuarios) del caso de uso principal que se muestra en la Fig.\ref{fig:casodeusoprincipal}474 (usuarios) del caso de uso principal que se muestra en la figura \ref{fig:casodeusoprincipal} 452 475 son: el Administrador del componente AC, el Administrador del Componente AR, el Administrador 453 476 del componente PUB, y el actor PSC, quiénes son los que interactúan con la aplicación. … … 462 485 Para el resto de la especificación de requisitos se elaboran casos de uso que modelan 463 486 las funcionalidades con que debe contar la aplicación. Para cada actor, se especifican 464 el correspondiente diagrama de caso de uso. En la Fig.\ref{fig:casodeusoac} se487 el correspondiente diagrama de caso de uso. En la figura \ref{fig:casodeusoac} se 465 488 muestra el caso de uso para el actor del componente AC. Las acciones que realiza 466 489 este actor son emisión, renovación y revocación de certificados, que conlleva procesos … … 477 500 478 501 También en esta etapa se construye el modelo de datos de la aplicación. 479 La Fig.\ref{fig:diagramadeclases} muestra de forma parcial, ya que no se incluyen502 La figura \ref{fig:diagramadeclases} muestra de forma parcial, ya que no se incluyen 480 503 los atributos, el diagrama de clases que explica el modelo de datos. Se consideran 481 504 como objetos persistentes del sistema a elementos como usuarios, clientes, … … 492 515 493 516 Para modelar la secuencia de acciones que se realizan para cada caso de uso se 494 utilizan los diagramas de actividades. La Fig.\ref{fig:diagramaactividades}517 utilizan los diagramas de actividades. La figura \ref{fig:diagramaactividades} 495 518 muestra el diagrama de actividades general para el caso de uso ``Emisión de 496 519 certificados''' del actor Administrador del componente AC. Para este conjunto de 497 actividades participan cuatro (4) actores: Administrador del PSC, qui én entrega los520 actividades participan cuatro (4) actores: Administrador del PSC, quien entrega los 498 521 recaudos necesarios para que se le firme su solicitud, el Administrador de la AR, 499 522 quién es el encargado de chequear los recaudos entregados por el PSC, el Administrador … … 506 529 \centering 507 530 \includegraphics[width=8cm]{imagenes/diagramaactividades.png} 508 \caption{Diagrama de actividades }531 \caption{Diagrama de actividades para el caso de uso ``Emisión de Cerificados``} 509 532 \label{fig:diagramaactividades} 510 533 \end{figure} … … 515 538 516 539 En esta etapa se utiliza como insumo los diagramas de casos de uso, diagrama 517 de clases y actividades, generados en la etapa de dise ~no. Se traduce el518 diagrama de clases al que se hace referencia en la Fig.\ref{fig:diagramaactividades}540 de clases y actividades, generados en la etapa de diseño. Se traduce el 541 diagrama de clases al que se hace referencia en la figura \ref{fig:diagramaactividades} 519 542 en un modelo de datos relacional, y se genera un script SQL que genera el mapa de 520 543 tablas relacional, donde las tablas representan relaciones tales como usuarios, … … 528 551 529 552 530 Haciendo uso de las ventajas que trae el uso de software libre (Sección \ref{sec:softlibre}),553 Haciendo uso de las ventajas que trae el uso de software libre, descritos en \ref{sec:softlibre}, 531 554 se implementa la aplicación utilizando la mayor cantidad de líneas de códigos 532 555 disponibles en los repositorios y proyectos de la comunidad, de tal manera que 533 satisfagan los requisitos y funcionalidades planteadas en la etapa de dise ~no.556 satisfagan los requisitos y funcionalidades planteadas en la etapa de diseño. 534 557 En este sentido, se utiliza el código fuente del proyecto XCA \cite{XCA:03}, 535 desarrollado por Christian Hohnst\"{a}dt, 558 desarrollado por Christian Hohnst\"{a}dt, que tiene como objetivo proveer una 536 559 aplicación escrita en el lenguaje de programación C++\cite{STRO:02} y la 537 560 biblioteca Trolltech Qt\cite{BLAN:06}, que cumpla con el estándar X.509. La aplicación 538 561 satisface los requisitos básicos para la gestión del componente de gestión de AC Raíz, 539 esto es, los diagramas UML de la etapa de dise ~no calzan con un gran conjunto de requisitos562 esto es, los diagramas UML de la etapa de diseño calzan con un gran conjunto de requisitos 540 563 satisfechos en el proyecto XCA, esto ocurre debido a que este trabajo comparte 541 objetivos con dicho proyecto; por ejemplo, para el caso de uso de la Fig.\ref{fig:casodeusoac},564 objetivos con dicho proyecto; por ejemplo, para el caso de uso de la figura \ref{fig:casodeusoac}, 542 565 donde el actor debe ejecutar tres acciones: emitir, renovar y revocar certificados, 543 566 la aplicación XCA incorpora estas tres actividades, pero se hace necesario adaptar … … 545 568 546 569 Es importante recalcar, que XCA no sastiface todos los requisitos documentados en la 547 etapa de dise ~no. En respuesta a este hecho, se realiza un proceso de completación de548 funcionalidades. En este sentido, se incorporan características a la aplicación acorde549 con la especificaciones de dise ~no,entre las cuáles se enumeran:570 etapa de diseño. En respuesta a este hecho, se realiza un proceso de incorporación de 571 funcionalidades. En este sentido, se agregan características a la aplicación acorde 572 con la especificaciones de diseño, entre las cuáles se enumeran: 550 573 \begin{itemize} 551 574 \item La incorporación de un sub-sistema de seguridad para acceso a los activos de 552 575 información que gestiona la aplicación, que incluya aspectos de autenticación y 553 576 autorización de usuarios, como lo es la validación de credenciales a través del 554 uso de tarjetas inteligentes, el registro y firma digitalde las acciones realizadas577 uso de tarjetas inteligentes, el registro y firma electrónica de las acciones realizadas 555 578 por los usuarios dentro de la aplicación. 556 En La fig\ref{fig:registro} se muestra la característica de registro de acciones.579 En la figura \ref{fig:registro} se muestra la característica de registro de acciones. 557 580 La ventana a la derecha muestra los detalles de la acción seleccionada en la lista, 558 581 se incluyen datos importantes como nombre de la cuenta de usuario, fecha, hora, y … … 578 601 la codificación y creación de la aplicación de gestión del componente AC Raíz. 579 602 Los tipos de tecnologías que deben seleccionarse son: bibliotecas para construir 580 la interfaz hombre-máquina (HMI ), motor criptográfico, conexiones con hardware,603 la interfaz hombre-máquina (HMI por sus siglas en inglés), motor criptográfico, conexiones con hardware, 581 604 interfaces con repositorio de datos y algoritmos de cálculo criptográfico más utilizados. 582 605 583 606 584 607 Como criptosistema se utiliza OpenSSL version 0.9.8 \cite{VIEG:2002}, que provee 585 de un conjunto de funciones criptográficas apegadas al estándar X.509.. Para la586 construcción de interfaces hombre-máquina y 587 selecciona la biblioteca Trolltech Qt. Comointerfaz para el uso de tarjetas608 un conjunto de funciones criptográficas apegadas al estándar X.509. Para la 609 construcción de interfaces hombre-máquina y uso de algoritmos generales se 610 selecciona la biblioteca Qt. Como interfaz para el uso de tarjetas 588 611 inteligentes se utilizo el estándar PKCS11, también conocido como Cryptoki, que 589 612 especifica una forma para interactuar con este hardware criptográfico\cite{NIC:03}. … … 609 632 más complejos formados por las unidades revisadas en las pruebas unitarias. 610 633 Las pruebas unitarias y de integración presentan la ventajas que son automatizables, 611 y por lo tanto, se cuenta co moherramientas de software para llevarlas a cabo.634 y por lo tanto, se cuenta con herramientas de software para llevarlas a cabo. 612 635 613 636 614 637 El segundo objetivo, es que se satisfagan los requisitos plasmados en la etapa 615 de dise ~no, y que se extraen de los diagramas UML , es decir, la aplicación638 de diseño, y que se extraen de los diagramas UML , es decir, la aplicación 616 639 debe cumplir con las características necesarias para resolver el problema de 617 640 gestión de una AC Raíz. En este sentido, se toma una estrategia basada en … … 619 642 de la comunidad chequear el progreso en el proyecto. Los prototipos son 620 643 chequeados por los usuarios y la modificación de requisitos y notificación de 621 errores son notificados en un sistema web de chequeo y seguimiento 644 errores son notificados en un sistema web de chequeo y seguimiento\cite{TRAC:07}. 622 645 623 646 También se habilita un sistema de control de versiones de licencia libre … … 626 649 versión de los programas fuentes. 627 650 628 Debido a que la aplicación de gestión de AC Ra iz debe ser parte de una651 Debido a que la aplicación de gestión de AC Raíz debe ser parte de una 629 652 infraestructura, es necesario realizar pruebas en condiciones similares a la 630 653 configuración final de ésta; por ello se simula la configuración de producción que … … 643 666 restringido por llaves y controles biométricos, y el flujo de información digital 644 667 hacia adentro y afuera de la bóveda debe ser realizado a través de dispositivos 645 de memoria secundaria con seguridad incorporada, tal como un lapiz usb (pendrive) 646 con bloqueo por contrase~na, como se muestra en la figura. También es necesario 647 la habilitación de servidores para la validación de los periodos de vigencia de 648 los certificados (OSCP), y para la generación de solicitudes de firma de certificados, 668 de memoria secundaria con seguridad incorporada, tal como una memoria usb (pendrive) 669 con bloqueo por contraseña, como se muestra en la figura \ref{fig:arquitecturapsc}. 670 También es necesario la habilitación de servidores para la validación de los períodos de vigencia de 671 los certificados a través del protocolo de estado de certificado en línea (OCSP por sus siglas en inglés), 672 y para la generación de solicitudes de firma de certificados, 649 673 donde las entidades finales o usuarios consignan los recaudos. 650 674 … … 662 686 de tarjetas inteligentes, inicialización de HSM, y copias de seguridad. 663 687 664 \section{ Lecciones aprendidas}688 \section{Conclusiones} 665 689 666 690 La puesta en marcha de una AC Raíz supone obligatoriamente contar con una 667 691 aplicación que gestione este componente de la infraestructura. En este sentido, 668 éste capítulo mostró el proceso de desarrollo de una aplicación que respondiera692 éste trabajo mostró el proceso de desarrollo de una aplicación que respondiera 669 693 a los requisitos particulares de gestión, determinados por el rol de confianza 670 raíz y última que debe representar la Autoridad.En función de ello, la671 aplicación tiene un alto grado de especialización, ya que 694 raíz que debe representar la Autoridad de Certificación. En función de ello, la 695 aplicación tiene un alto grado de especialización, ya que cuenta con un 672 696 mercado relativo de pocos usuarios, si se compara con el mercado de los sistemas 673 697 de información o aplicaciones de ofimática, y su operación se realiza en 674 condiciones est andándares y específicas. A pesar de este hecho, para la698 condiciones estándares y específicas. A pesar de este hecho, para la 675 699 construcción de la aplicación se integraron varios proyectos disponibles en los 676 repositorios de software libre, que permitió disponer de un criptosistema700 repositorios de software libre, lo que permitió disponer de un criptosistema 677 701 estándar y suficientemente completo para cumplir con los requisitos descritos 678 en la etapa de dise ~no. La criptografía se utiliza como herramienta para702 en la etapa de diseño. La criptografía se utiliza como herramienta para 679 703 otorgar las tres propiedades (Confidencialidad, Integridad y Disponibilidad) 680 704 de la seguridad informática a los datos que gestiona la aplicación, y en virtud … … 683 707 con los estándares aceptados a nivel mundial. 684 708 685 En la etapa de dise ~no, los diagramas de casos de uso y actividades sirvieron709 En la etapa de diseño, los diagramas de casos de uso y actividades sirvieron 686 710 para obtener una visión formal de los requisitos y de los procesos con los que 687 cumplir la aplicación. Estos documentos de dise ~no en el lenguaje UML, permitieron711 cumplir la aplicación. Estos documentos de diseño en el lenguaje UML, permitieron 688 712 alcanzar de manera más rápida y certera los objetivos que son coincidentes con la 689 713 gestión real de una AC Raíz. … … 692 716 gestionados por la aplicación sean compatibles con el esquema de seguridad basado 693 717 en un tercero de confianza, y aceptado por gran cantidad de aplicaciones y sitios 694 de comercio y transacciones seguras en internet.718 de comercio electrónico y transacciones seguras en internet. 695 719 696 720 Para la tarea de eliminación de fallas las técnicas como la colaboración utilizando … … 740 764 almacenar con un alto nivel de seguridad claves privadas. 741 765 742 %\bibliography{ BibACRaizArticulo}766 %\bibliography{referenciasCapitulo5} 743 767 %\bibliographystyle{plain} 744 768 745 769 746 770 % bibliografia 771 \begin{thebibliography}{} 772 773 \bibitem{NIC:03} 774 R. Nichols and P. C. Lekkas, "Seguridad para comunicaciones inal{\'a}mbricas". McGraw-Hill, Mexico, 2003. 775 776 \bibitem{STAL:03} 777 William Stallings, "Fundamentos de Seguridad de Redes. Aplicaciones y Est{\'a}ndares", Prentice Hall, España, 2003. 778 779 \bibitem{NASH:02} 780 Nash Duane and Joseph Brink, "PKI: Infraestructura de clave p{\'u}blica", McGraw-Hill,. Mexico, 2002. 781 782 \bibitem{ACE:03} 783 Vicente Aceituno Canal, "Seguridad de la información", Noriega Editores, Mexico, 2003. 784 785 \bibitem{SCHM:03} 786 Joseph Schmuller, "Aprendiendo UML en 24 horas", Prentice Hall, Mexico, 2003. 787 788 \bibitem{BOOC:99} 789 G., Booch, "UML Lenguaje Unificado de Modelado", Addison Wesley, 1999. 790 791 792 \bibitem{MULL:97} 793 Alain Pierre-Muller, "Modelado de objetos con UML", Eyrolles, Barcelona, España, 1997. 794 795 796 \bibitem{FSF:07} 797 Free Software Definition, http://www.fsf.org/licensing/essays/free-sw.html, 2007. 798 799 800 \bibitem{SARW:03} 801 Sarwar, Koretsky, "El libro de Linux", Pearson, Prentice Hall, Madrid, España, 2003. 802 803 \bibitem{KURT:01} 804 Kurt Wall et al, "Programación en Linux", Prentice Hall, Madrid, España, 2001. 805 806 807 \bibitem{XCA:03} 808 Christian Hohnst\"{a}dt, XCA, una interfaz gr\'afica para OpenSSL, Clave p\'ublicas y privadas, 809 certificados, solicitudes y listas de revocación. http://sourceforge.net/projects/xca/. 810 811 \bibitem{STRO:02} 812 Bjarne Stroustrup, "El lenguaje de programación C++", Addison Wesley, Madrid, España, 2002. 813 814 \bibitem{BLAN:06} 815 James Blanchette and Mark Summerfield, "C++ GUI Programming with Qt 4", Prentice Hall, Massachusetts, USA, 2006. 816 817 \bibitem{VIEG:2002} 818 John Viega and Matt Messier and Pravir Chandra, "Network Security with OpenSSL", O'Really, 2002. 819 820 \bibitem{PRESS:05} 821 Roger S. Pressman, "Ingenier'ia del software. Un enfoque práctico", Mc Graw-Hill, Mexico 2005. 822 823 \bibitem{TRAC:07} 824 TRAC web-based software project management, http://trac.edgewall.org/, 2007. 825 826 \bibitem{PILA:04} 827 C. Michael Pilato and Ben Collins-Sussman and Brian W. Fitzpatrick, "Version Control with Subversion ", O'Really, 2004. 828 829 830 \end{thebibliography} 747 831 748 832 … … 786 870 % 787 871 % %\begin{abstract} 788 % A Certification Authority Root (CA Root) is a component which role is to represent the highest confidence point in a hierarchical structure denominated Public Key Infrastructure (PKI). A PKI provides people, IP addresses and Web domains with digital certificates under X.509 standard, offering logic security and legal entailment to transactions performed on the internet by the certificate’s owner. Confidence resides in private key protection through strong physical and logical security schemes, so these schemes allow the certificate emission. This work shows the development process of a CA root management application. For this development it's used libraries, tools, compilers, operating systems and licenses compatible with the principles of free software. In first place, the requirements to satisfy are determined based on a general description of a CA's functions and characteristics; subsequently, functionalities are designed and requirements are specified in order to produce a formal vision of the processes 789 % to automate. A section is dedicated to the implementation, this consists on codification in a programming language of the processes forseen in the previous stages, like also, of the incorporation of strong mechanisms of validation of identity of users, registry of events, actions signature by application's administrators, and connections specification with specialized hardware, like smart cards. Finally, application display and configuration are shown, it involves its installation in a safe environment (vault or data center) and CA Root connection with other components of the infrastructure. 872 % A Certification Authority Root (CA Root) is a component which role is to represent the 873 % highest confidence point in a hierarchical structure denominated Public Key Infrastructure (PKI). 874 % A PKI provides people, IP addresses and Web domains with digital certificates under X.509 875 % standard, offering logic security and legal entailment to transactions performed on the 876 % internet by the certificate’s owner. Confidence resides in private key protection through 877 % strong physical and logical security schemes, so these schemes allow the certificate emission. 878 % This work shows the development process of a CA root management application. For this development 879 % it's used libraries, tools, compilers, operating systems and licenses compatible with the 880 % principles of free software. In first place, the requirements to satisfy are determined based 881 % on a general description of a CA's functions and characteristics; subsequently, functionalities 882 % are designed and requirements are specified in order to produce a formal vision of the 883 %processes 884 % to automate. A section is dedicated to the implementation, this consists on codification in a 885 % programming language of the processes forseen in the previous stages, like also, 886 % of the incorporation of strong mechanisms of validation of identity of users, 887 % registry of events, actions signature by application's administrators, and 888 % connections specification with specialized hardware, like smart cards. 889 % Finally, application display and configuration are shown, it involves its 890 % installation in a safe environment (vault or data center) and CA Root connection 891 % with other components of the infrastructure. 790 892 % %\end{abstract} 791 893 %
Note: See TracChangeset
for help on using the changeset viewer.