Desarrollo de una autoridad para manejo de estampillas de tiempo
50
0
0
Texto completo
(2) TABLA DE CONTENIDOS. 1. INTRODUCCIÓN ................................................................................... 3. 2. PKI BANCO DE LA REPÚBLICA.............................................................. 5 2.1 2.2. 3. GENERALIDADES .................................................................................. 5 MARCO LEGAL ..................................................................................... 6. ANTECEDENTES Y JUSTIFICACIÓN ....................................................... 9 3.1. CERTIFICADOS DIGITALES ......................................................................11. 4. DESCRIPCIÓN DEL PROBLEMA ........................................................... 13. 5. MARCO CONCEPTUAL ......................................................................... 14 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13. 6. CERTIFICATION AUTHORITY ....................................................................14 CERTIFICATE REPOSITORY ......................................................................15 CERTIFICATE REVOCATION .....................................................................15 KEY BACKUP AND RECOVERY ...................................................................16 AUTOMATIC KEY UPDATE .......................................................................16 KEY HISTORY.....................................................................................17 CROSS CERTIFICATION .........................................................................17 SUPPORT FOR NON-REPUDIATION .............................................................18 CLIENT SOFTWARE ..............................................................................18 TIME STAMPING ..................................................................................18 TIME STAMP PROTOCOL ........................................................................21 TRANSACCIONES DE LA TSA ...................................................................21 BENEFICIOS DE LA TSA.........................................................................23. ANÁLISIS, PROPUESTA Y ALCANCE ................................................... 24 6.1 6.2 6.3 6.4. REQUERIMIENTOS FUNCIONALES DE LA TSA................................................24 REQUERIMIENTOS NO FUNCIONALES ..........................................................24 REQUERIMIENTOS DE LA APLICACIÓN .........................................................24 ALCANCE ..........................................................................................26. 7. IMPLEMENTACIÓN ............................................................................. 27. 8. CONCLUSIONES Y TRABAJO FUTURO ................................................. 35. 9. ANEXOS ............................................................................................. 37 9.1 9.2 9.3. GLOSARIO ........................................................................................37 DIAGRAMAS ......................................................................................38 CASOS DE USO ..................................................................................43. 2.
(3) 1. INTRODUCCIÓN. La veracidad de la información es uno de los mayores factores que debe afrontar la sociedad actual. Con la forma de hacer negocios actualmente (electrónicamente), las firmas manuscritas ya no son suficientes para saber si un documento es válido o no. Por esto surgen las firmas digitales, que permiten saber si una persona u otra firmo digitalmente un documento o una transacción. Pero con el desarrollo de las transacciones electrónicas, también aparece la necesidad de manejar el tiempo de una manera segura y confiable. Esto para saber si una persona hizo una acción en específico en una fecha y en una hora que se pueda corroborar y que la persona no pueda repudiar esta información de ninguna manera. El Banco de la República como banco central de Colombia, hace transacciones de todo tipo; tanto internas entre sus empleados, como externas con otras entidades financieras. Con la implementación de la Infraestructura de llaves Públicas (PKI), en el Banco de la República, (se explica en el marco teórico). Este gano confidencialidad, integridad, autenticación y no repudiación de la información en las operaciones que ameritan tener este tipo de seguridad, pero para complementar estas funciones, se tenía que implementar una autoridad del manejo seguro del tiempo, para que la infraestructura de llaves públicas tuviera una herramienta, en la cual se podría verificar el momento del tiempo en que se hizo una transacción de cualquier tipo, y que nadie pudiera refutar la veracidad de esta información.. 3.
(4) •. Objetivo General:. Estudiar los mecanismos necesarios para implementar una autoridad del manejo del tiempo, bajo los estándares internacionales, dentro del contexto de una infraestructura de llaves públicas (PKI).. Objetivos Específicos: Diseñar e implementar la aplicación Time Stamp Authority, que funcione como una autoridad del tiempo dentro del contexto de la PKI del Banco de la República, basándose en el Request for Comment (RFC) Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP), que es el estándar internacional para la creación de una autoridad del tiempo dentro de una PKI.. 4.
(5) 2. 2.1. PKI BANCO DE LA REPÚBLICA. Generalidades. Dentro de un entorno en donde la economía se ha globalizado, es frecuente encontrar operaciones que deben realizarse no solo entre distintos sitios de la ciudad, sino entre diversos países en donde el trámite manual ya no tiene cabida. El flujo de los mensajes informáticos que representan las operaciones de organizaciones como el Banco de la República, normalmente debe pasar a través de medios de comunicación inseguros como Internet. Todo esto ha abierto un espectro de riesgos informáticos sobre las operaciones digitales actuales que no pueden ser descuidados por el Banco de la República. Entre los riesgos se encuentran: •. Pérdida de confidencialidad: Las operaciones o los mensajes pueden verse seriamente comprometidos en la medida que estos requieran ser tramitados sin que nadie pueda entender lo que conlleva el mensaje en sí,. •. Modificación de la información (integridad): Una transacción financiera en donde se involucra dinero, debe estar protegida contra posibles modificaciones por parte de entes que no están legalmente habilitados para hacerlo,. •. Suplantación de la fuente o el destino de la operación: Una operación debe tener la certeza tanto en su origen como en su destino final. Por ningún motivo pueden ser suplantados en algún momento,. •. Rechazo en el trámite formal de una operación (repudiación): El debido trámite de una operación o una transacción no puede ponerse en duda,. •. Estado sobre el trámite de la operación: Una operación debe garantizar que en todo momento pueda ser rastreada en la medida que se conozca que ha venido sucediendo con ella,. •. Disponibilidad de la información: Cualquiera sea el caso, en cualquier momento toda la información referente a una operación debe estar disponible para la persona legalmente habilitada.. 5.
(6) Debido a estos riesgos informáticos ha sido necesario que la tecnología de la información tenga presente el acordar y proponer los mecanismos para transmitir y proteger las operaciones realizadas a través de mensajes de información. Dichos mecanismos han sido presentados y desarrollados en tres generaciones sobre tecnología de seguridad informática: encripción simétrica, encripción asimétrica e infraestructuras de llaves públicas (PKI): •. Encripción simétrica: Esquema que busca garantizar la confidencialidad y la integridad de la información. Es un algoritmo que encripta (cifra) y desencripta (descifra) la información utilizando la misma llave de encripción (código personal). Este esquema tiene el inconveniente de que todos los participantes de la comunicación segura deben conocer la misma llave y por tanto su distribución se hace compleja e insegura dependiendo de los medios que se utilicen para hacerlo. No permite gestionar las llaves en el tiempo; es decir que si una persona va encriptando archivos con una llave y la cambia en el tiempo, ésta debe tener claridad de que llave utilizó para poder recuperar el archivo.. •. Encripción Asimétrica: Esquema mucho más robusto que el anterior. Sin embargo requiere mucho más recurso de procesamiento y no es tan eficiente cuando encripta y/o desencripta mensajes muy grandes. Maneja un par de llaves para cada participante, una denominada privada y otra pública que puede ser distribuida sin riesgo alguno. Este esquema permite, además de encriptar y desencriptar, firmar digitalmente los mensajes o archivos. Con la firma se garantiza la autenticación de las partes e integridad del mensaje de tal forma que éste no pueda ser alterado. Como consecuencia de esto la no repudiación se puede garantizar ya que se conoce con exactitud quien hizo qué en todo momento. No permite gestionar las llaves en el tiempo; es decir que si una persona va encriptando archivos con su par de llaves y las cambia en el tiempo, ésta debe tener claridad de que llaves utilizó para poder recuperar el archivo.. •. Infraestructura de Llaves Públicas – PKI: Este esquema es la nueva tecnología que recoge los beneficios de los dos anteriores y permite suplir las falencias de los mismos. Una PKI gestiona por completo la administración de las llaves y permite hacer que los procesos basados en esquemas de encripción, sean llevaderos con la funcionalidad y crecimiento de las organizaciones en el tiempo.. 6.
(7) 2.2. Marco Legal. Colombia es uno de los países pioneros en reglamentación respecto al trámite de mensajes digitales (comercio electrónico). El marco legal colombiano comprende: •. Ley 527 de Agosto de 1999: Define y reglamenta el acceso y uso de los mensajes de datos, del comercio electrónico y de las firmas digitales, se establecen las entidades de certificación (parte de una PKI) y se dictan otras disposiciones. http:/www.sic.gov.co/Normatividad/Leyes/Ley 527-99.htm. •. Decreto 1747 de Septiembre de 2000: Se reglamenta parcialmente la ley 527 en lo relacionado con las entidades de certificación, los certificados y las firmas digitales. http://www.sic.gov.co/Normatividad/Decretos/Decreto%201747-00.htm. •. Resolución 26930 de Octubre de 2000: Estándares para la autorización y funcionamiento. de. las. entidades. de. certificación. y. sus. auditores.. http://www.sic.gov.co/Normatividad/Resoluciones/Resolucion%2026930-2000.htm •. Sentencia C-662/00 Junio de 2000 Corte Constitucional: Respuesta de la Corte Constitucional a la demanda efectuada por los notarios públicos a la ley 527. http://bib.minjusticia.gov.co/jurisprudencia/CorteConstitucional/2000/Constitucion alidad/C-662-00.htm. Una PKI contribuye significativamente al logro, en términos de seguridad informática, de lo correspondiente al marco legal colombiano. Hoy en día un mensaje digital tiene el mismo efecto probatorio que el papel ante un juez y dependerá del modelo de seguridad que se haya aplicado, el tener los suficientes argumentos probatorios en caso de un incidente legal. Bajo el marco legal colombiano existen dos posibles entidades de certificación: •. Cerrada: Son aquellas que se conciben para generación y administración de certificados sólo para sus usuarios directos y además no se cobra por ello,. •. Abierta: Es abierta cualquier entidad que incumpla los lineamientos de la cerrada.. 7.
(8) Los certificados emitidos por las entidades de certificación abierta connotan el efecto de presunción; los certificados emitidos por la cerrada no. No obstante es claro que los certificados emitidos por la cerrada pueden llegar a tener el mismo efecto probatorio de los de la abierta, argumentando elementos adicionales que no son exigidos en la abierta. Las entidades de certificación, abiertas o cerradas, deben ser autorizadas por la Superintendencia de Industria y Comercio. La abierta exige mayores requisitos que la cerrada. En cualquier servicio, es fundamental contar con mecanismos que permitan, ante un escenario jurídico, llevar argumentos suficientes para demostrar ante un juez como se están cumpliendo los fundamentos.. El Banco de la República no puede ser una entidad de certificación abierta ya que sus estatutos no se lo permiten. Además, no es del interés del Banco vender certificados a terceros. Bajo la perspectiva del Banco de la República la PKI contribuye al logro de los fundamentos. de. la. seguridad. informática en:. Autenticación,. Confidencialidad,. Integridad, Control de Acceso, Disponibilidad, No Repudiación y Auditabilidad. 8.
(9) 3. ANTECEDENTES Y JUSTIFICACIÓN. Antes de la Implementación de la PKI, el Banco, tenía varios mecanismos de seguridad, (PGP, autenticación con SecureCards), pero con el rápido crecimiento de las transacciones en línea, la administración de estos servicios por separado, se convirtió en una carga administrativa muy alta, además de que algunos de estos mecanismos, para la época actual ya no eran tan confiables como antes. Entre los problemas que tenían estos son los más importantes: -. Posible perdida de confidencialidad,. -. Alteración de la información,. -. Suplantación. -. Repudiación,. -. Incapacidad para reconstruir el proceso de intercambio de los mensajes,. -. Pérdida de acceso a los mensajes generados (Disponibilidad).. Los objetivos de implementar la PKI, fueron los siguientes: 1. Fortalecer los niveles de seguridad en los servicios del Banco •. Mecanismos de autenticación más robustos e integrados. •. Mayor cobertura (punto a punto) en confidencialidad e integridad. •. Mayor oportunidad en la recuperación de la información electrónica. •. Mayor automatización de procesos de autenticación y disminución de procesos manuales asociados. •. Mayores facilidades de auditabilidad. •. Mecanismos adicionales para la no repudiación. 2. Alinear parte del esquema de seguridad con la legislación vigente: •. Permitir características similares o superiores de seguridad en los documentos electrónicos Vs. los documentos en papel por la firma digital. •. Aprovechar las bondades de la ley sobre mensajes de datos. • 3. Posibilitar mayor agilidad al trámite de documentos y servicios electrónicos del Banco por la visación automática. 9.
(10) 4. Adoptar estándares y recomendaciones mundiales de Seguridad Informática. Como se puede ver, una PKI contribuye significativamente al logro y cumplimiento, en términos de seguridad informática, de las normas establecidas por el marco legal colombiano; dicho mejor, Colombia y en particular el Banco, cuenta con un referente legal vigente que le permite subir su nivel de seguridad a través de herramientas avanzadas en seguridad como el PKI. Hoy en día un mensaje digital tiene el mismo efecto probatorio que el papel ante un juez y dependerá del modelo de seguridad que se haya aplicado, el tener los suficientes argumentos probatorios en caso de un incidente informático. El modelo de seguridad del Banco busca principalmente el cumplimiento de los 7 fundamentos de seguridad informática, en todos sus servicios críticos, a saber:. a). Confidencialidad: Cuando la información es sólo accesible por aquellos a los. cuales se ha autorizado su acceso. b). Integridad: Cuando la información es exacta y completa. Cuando se garantiza. que la información no se modifica desde su momento de creación. c). Disponibilidad: Cuando la información es accesible a los usuarios autorizados. en el momento de requerirla. d). Autenticación: Cuando se puede garantizar la identidad de quien solicita acceso. a la información. e). Autorización o Control de Acceso: Cuando la información es accedida solo por. los usuarios que tienen los privilegios necesarios y suficientes para hacerlo. f). No repudiación: Cuando la información involucrada en un evento corresponde. a quien participa en el mismo, quien no podrá desconocer su intervención en éste. g). Observancia: Cuando la información relacionada con las acciones y actividades. de los usuarios. (personas o procesos) se encuentra debidamente registrada y. 10.
(11) monitoreada. Además cuando se vela y propende por el adecuado funcionamiento del modelo de seguridad informática.. La PKI que tiene actualmente el Banco de la República, no tiene implementada una autoridad segura del tiempo, pero tiene los medios necesarios para poder desarrollarla, cumpliendo con los estándares internacionales. En general las principales características de la PKI son:. •. Minimiza la suplantación, incorporando el concepto de certificado digital,. •. Administración automática y centralizada de llaves públicas,. •. Posibilita la autenticación de usuarios, aplicaciones y servidores bajo un esquema integral, ampliando la cobertura de protección de información dentro del centro de cómputo,. •. Facilita el visado de firmas, el control de históricos y vigencias de llaves, la cual puede ser automática (PKI gestionada),. •. Permite atacar la disponibilidad y no repudiación simultáneamente,. •. No importa la cantidad de participantes,. •. Se disminuyen los puntos a controlar del esquema de autenticación,. •. No provee gestión sobre la administración de mensajes y archivos electrónicos,. •. Su implantación implica costos adicionales por adecuaciones de aplicaciones que quieran operar bajo este esquema,. •. El mantenimiento está asociado con un esquema de licenciamiento.. 11.
(12) La PKI busca robustecer el modelo de seguridad de la organización de tal forma que una vez se requiera un marco probatorio ante cualquier incidente legal, ésta se convierta en herramienta probatoria fundamental. 3.1. •. Certificados Digitales. Definición: . Mensaje de datos con información acerca del titular, incluida su llave pública.. . Esta firmado digitalmente por la entidad que lo genera para garantizar su origen.. . Facilita procesos automáticos de validación pues el certificado se convierte en una credencial que identifica de manera única a un usuario.. •. Principales usos de los certificados: . Autenticación de: Usuarios, Servidores, Aplicaciones, etc.. . Protección de la información punto a punto, es decir que los mensajes viajan seguros desde el punto que se originó hasta su destino final,. . Validación de la integridad de mensajes y archivos, es decir que se garantiza que la información no sufrió modificaciones desde el momento que se generó.. El siguiente gráfico muestra un certificado típico:. 12.
(13) 13.
(14) 4. DESCRIPCIÓN DEL PROBLEMA. La mayoría de empresas tienen desde hace algún tiempo mecanismos de certificación. No obstante, estos trabajan aisladamente y cada usuario debe ser definido y administrado en cada uno de ellos redundantemente con las implicaciones respecto a riesgos que esto genera. De seguir así se tendría que manejar tantos componentes de certificación, como sitios de certificación fueran surgiendo de acuerdo al servicio informático implantado (por ejemplo el correo electrónico es uno de ellos). A esta problemática se le añade la complejidad de tener que administrar las llaves (públicas y privadas) en el tiempo, es decir, un usuario normalmente tendrá que ir cambiando sus llaves con el paso del tiempo por seguridad. Si éste desea recuperar un mensaje o archivo de hace varios años, debe tenerse en cuenta que se debe utilizar el par de llaves utilizado en esa época. La problemática anterior está siendo resuelta por las plataformas estándares que utilizan certificados digitales como modelo de certificación en todos sus servicios. Todo esto es resuelto por la PKI gestionada la cual se encuentra completamente alineada con los estándares mundiales. Por otro lado, algunos esquemas de seguridad informática con que cuentan actualmente las empresas para validar usuarios, asegurar contenido de mensajes, verificar el origen de los mismos y asegurar la intervención de la contraparte en la transmisión, no se basan en certificados digitales y no aprovechan las bondades jurídicas de la legislación vigente sobre mensajes de datos. La administración manual de claves de seguridad y la dificultad para recuperar mensajes antiguos cifrados, compromete la capacidad probatoria de una entidad en casos de reclamación.. 14.
(15) 5. MARCO CONCEPTUAL. Una PKI (Public Key Infrastructure) o Infraestructura de Llaves Públicas, pretende ser un. punto central seguro de certificación para múltiples aspectos del manejo de la. seguridad informática. (Manejo de la autenticación, integridad, confidencialidad, y no repudio de la información). Esto se acopla con una combinación de técnicas de criptografía simétrica y asimétrica que permiten el uso de una infraestructura única, robusta y sencilla en vez de múltiples aplicaciones de seguridad complejas y rígidas. Una PKI se conforma básicamente de estas partes y servicios:. -. Certification Authority (Autoridad Certificadora). -. Certificate Repository (Repositorio de certificados). -. Certificate Revocation (Revocación de certificados). -. Key Backup and Recovery (Respaldo y recuperación de llaves). -. Automatic Key update (Actualización automática de llaves). -. 5.1. Key History (Historia de las llaves). -. Cross Certification (Certificación cruzada). -. Support for Non – Repudiation (Soporte para no repudio). -. Time Stamping (Estampillas de tiempo). -. Client Software (Programas del cliente). Certification Authority. La idea original en la criptografía de llave pública, era la de que dos extraños, se pudieran comunicar de una manera segura.. Si una persona quería enviarle un. mensaje a otra persona que no conoce previamente, la persona que quiere enviar asocia su mensaje con la llave pública del receptor, para que pueda encriptar el mensaje y enviarlo al receptor, que es la única persona que puede leer el mensaje, desencriptandolo con su llave privada.. 15.
(16) Pero el problema es como tanto el receptor como la persona que envía es la que dice ser. En este punto entra un tercero a jugar que es una autoridad confiable (trusted authority). Esta entidad goza de la confianza de un segmento de la población, o quizás toda la población, para ejecutar la función de “crear” una pareja de llaves (pública y privada), para cierta entidad (persona natural, o persona jurídica). Estas autoridades, también se conocen como autoridades de certificación (certification authorities, o CAs) en la terminología de PKI; estas autoridades certifican que el par de llaves juntas, pertenecen a una persona o entidad. Más adelante se verá que un certificado digital, contiene no solo las llaves, sino otros elementos, que componen todos, un certificado digital. La CA es un componente crítico de una PKI y por ende forma parte de la definición de esta.. 5.2. Certificate Repository. La CA, solo resuelve una parte del problema, de enviar un texto seguro entre dos extraños. El certificado autorizado por la CA, asocia la llave pública con la identidad del receptor, pero si el remitente no tiene el certificado del receptor, este no podrá enviarle el mensaje encriptado. Para solucionar esto, debe existir un repositorio robusto, escalable y on-line, para que el remitente pueda encontrar el certificado del receptor, para comunicarse de una manera segura con este. Este repositorio es el certificate repository. Para implementar este, existen varias plataformas entre las. cuales están, X.500, LDAP, Web servers,. FTP servers, DNS, y base de datos relacionales.. 5.3. Certificate Revocation. La CA firma un certificado digital atando el par de llaves, a la identidad de un usuario. En el mundo real, hay eventos que pueden romper esta unión. Ejemplo:. 16.
(17) Cambio de identidad de una persona, (apellido de soltera, a apellido de casada), o que la llave privada fue copiada por otro usuario. Para solucionar esto debe haber un mecanismo que permita alertar a la comunidad de usuarios que el certificado de esta persona, no debe ser aceptado, como prueba de pertenecer a una persona. Este mecanismo se llama certificate revocation. Una analogía con el mundo real, es el pase de conducción, este certifica que una persona es quien dice ser (nombre, y fotografía) + el número del pase, expedido por una autoridad confiable (Ministerio de transporte). Cuando el policía, revisa la licencia, no solo mira que sea original, y que no este vencida sino que llama a una central, donde le confirman si esta revocada o no. Por esto se necesita que exista este módulo en una PKI.. 5.4. Key Backup and Recovery. En cualquier entorno, hay que esperar que un porcentaje de los usuarios pierdan el acceso a su llave privada. Esto puede ocurrir, por falta de uso, perdida de la clave, o destrucción del medio en donde se guardaba la llave (daño de disco duro, smart card, o diskette). La perdida de datos protegidos por el vencimiento o perdida de una llave, es totalmente. inaceptable.. Una. empresa. puede. tener. documentos. importantes. encriptados con una llave privada de alguna persona, si esta la pierde estos documentos, no se podrán recuperar, lo cual puede afectar al negocio en varios aspectos. La solución a este problema está en implementar una copia de respaldo y de recuperación de las llaves de desencripción privadas (más adelante se explica como funciona las llaves para firmar, y las llaves para desencriptar). Este procedimiento se llama key backup recovery, y hace parte de lo que es una PKI.. 17.
(18) 5.5. Automatic Key Update. Un certificado tiene un límite de vida, esto por razones teóricas, como por ejemplo (“Se cambian las llaves con la frecuencia de limitar la cantidad de datos protegidos por una llave a x megabytes”). Cualquiera que sea la razón, es claro que un certificado tiene la necesidad de expirar y ser reemplazado por uno nuevo. La mayoría de los usuarios de la PKI, les parecerá engorroso hacer la renovación del certificado de manera manual, por ejemplo pueden olvidar la fecha de expiración, y cuando va a hacer el procedimiento el certificado ya no es válido, y no puede hacer la renovación de este, es más tiene que hacer un procedimiento muy parecido a la de creación del certificado por primera vez. Por esta razón, la PKI debe tener un mecanismo automático de renovación de los certificados, sin intervención del usuario. Cuando la fecha de renovación se acerca, la operación de renovación ocurre y un nuevo certificado es generado y reemplaza al anterior.. 5.6. Key History. El concepto de renovación de llaves, ya sea manual o automático, implica que en el curso del tiempo un usuario tiene múltiples certificados “viejos” y al menos uno actual. Esta serie de certificados y sus respectivas llaves es conocida como la historia de llaves del usuario o (key history). Guardar esta serie, es muy importante porque los datos que un remitente ha enviado para si mismo o para otra persona , no puede ser desencriptada cinco años después de que fue encriptada con su llave de desencripción actual. (re-encriptar los datos con una nueva llave, es una manera ineficiente de resolver este problema). Como el proceso de key update el manejo de la historia de las llaves debe ser un proceso automático y manejado por la PKI. La PKI debe tener todas las llaves de la historia, hacer la copia de respaldo y recuperación cuando sea apropiado y encontrar la llave apropiada que corresponda a cualquier dato.. 18.
(19) 5.7. Cross Certification. La idea de tener una PKI global es un concepto utópico. En vez de esto hay múltiples PKIs implementadas y operadas independientemente, para varias comunidades. Teniendo estas PKIs, es inevitable que algunas de ellas estén interconectadas. Cambiando las relaciones de negocio o por otras razones, los usuarios de. una PKI,. pueden llegar a necesitar comunicarse de forma segura con usuarios de otra PKI. El concepto de cross certification se basa en formar relaciones de confianza entre las PKI, para que una pueda verificar los certificados de otra, y al revés.. 5.8. Support for Non-Repudiation. Los usuarios de una PKI hacen acciones con la intención de que queden asociadas a su identidad. Por ejemplo un usuario firma un documento, diciendo que ese documento es propiedad de él. Es un requerimiento para la PKI, que los usuarios no puedan romper esta asociación arbitrariamente, especialmente para su propio beneficio. Por ejemplo meses después de firmar un documento, la persona no puede negar que esa firma proviene de el, y que fue otra persona, la que firmó el documento, o que alguien tomó su llave y la usó sin su autorización. La PKI debe proveer mecanismos para evitar y prevenir la repudiación como una propiedad que se llama no repudio. La PKI, por si sola no puede proveer no repudiación verdadera o completa, debe haber un elemento humano para aplicar a discreción un juicio sobre una evidencia, para saber si es de una persona o no. Sin embargo la PKI debe dar soporte a este proceso proveyendo la evidencia técnica requerida, como la autenticación de los datos de origen, y una afirmación confiable, de la fecha en que fueron firmados los datos.. 19.
(20) 5.9. Client Software. El software cliente es un componente esencial de una PKI, sin este, los servicios ofrecidos por la PKI no tienen sentido, porque entonces no hay como usarlos. Es importante notar que esto no es SW de aplicación, no hay código PKI dentro de la aplicación, como un plug in para el browser o el cliente de correo. Si es así se estaría violando el concepto de infraestructura. En vez de esto las aplicaciones se conectan a la PKI a través de puntos estandarizados, tal como en una infraestructura, pero la aplicación por si misma no interactúa con los servidores PKI, esto es que la aplicación usa la infraestructura, más no hace parte de ella.. 5.10 Time Stamping. Un punto central seguro de certificación para que la PKI provea una fuente confiable de seguridad, es la del manejo seguro del tiempo o time stamping. Esto significa que la fuente del tiempo debe ser confiable y el valor del tiempo debe ser transmitido por un camino seguro a través de los años de conservación, por ejemplo, de un documento. Uno de los elementos críticos para el soporte de los servicios de no repudio es el uso del secure time stamping, dentro de la PKI (El tiempo que provee esta autoridad debe venir de una fuente confiable, de fuentes mundiales oficiales como el US Naval Observatory Master Clock Time (http://tycho.usno.navy.mil/), es preferido, ya que para asuntos legales sería válido tener el tiempo oficial de una entidad reconocida mundialmente por el manejo del tiempo, y no una fuente local: Para esto, el evento B, debe seguir al evento A, y si la autoridad del tiempo dice que es así, nadie puede refutar lo contrario. Para explicar por que es útil tener una autoridad del tiempo, se pueden revisar estas preguntas cuando un usuario revisa un documento digital. 1. ¿Quién es al autor del archivo, quien lo escribió, quién lo aprobó? 2. ¿Cuando el archivo fue creado, y cuando fue modificado?. 20.
(21) En ambos casos, la pregunta se basa en el mismo archivo en esa precisa secuencia de bits. La respuesta a la primera pregunta dice quién lo creo, o lo aprobó. La respuesta a la segunda dice cuando el documento fue por última vez modificado. Las dos preguntas pueden tener soluciones, un sistema para contestar la primera pregunta es el esquema de certificado digital. Para la segunda pregunta existe el esquema de Secure Time Stamping. Los siguientes ejemplos muestra como funciona el procedimiento: Carlos Pérez tiene la idea para un nuevo proyecto, la escribe en un documento, y le coloca una estampilla de tiempo. La estampilla de tiempo y el documento, pueden probar que la idea es de Carlos Pérez, que modificó por última vez el archivo en esa fecha y no de otra persona que puede haber plagiado su idea, así este la haya publicado primero. Segundo ejemplo: •. Un cliente desea hacer una compra de elementos de oficina, el cliente guarda y llena un documento electrónico, solicitando los productos necesarios.. •. El cliente firma digitalmente la orden de compra (Este paso no es necesario para el proceso de timestamping). •. La estampilla de tiempo, se adiciona al documento, porque el vendedor exige que las ordenes tengan una estampilla de este tipo.. •. En este paso se procesa la transacción, generando un valor único, llamado función de hash. Esto permite al vendedor verificar que el cliente hizo la solicitud en una fecha específica.. El procedimiento de time stamping, funciona a grandes rasgos de la siguiente manera: El remitente firma un documento con su certificado digital, y desea que también tenga una estampilla de tiempo. Esta persona le aplica una función de hash segura al documento, y como resultado de esta obtiene el message digest o valor único, que solo puede ser obtenido sobre el documento original, este resultado se envía a la Time Stamp Authority TSA, (hay que aclarar que el documento nunca se envía a la TSA, solo el digest). Esta le devuelve al remitente una estampilla de tiempo digital, la cual. 21.
(22) consiste en el message digest, la fecha y la hora en que recibió el documento y la firma de la TSA. Como el message digest, no revela ninguna información acerca del contenido del documento, la TSA no puede obtener información de los documentos a los cuales les pone la estampilla de tiempo. Después el autor del documento puede presentar el documento y la estampilla de tiempo juntos, para probar cuando fue firmado el documento. Un verificador computa el message digest del documento, asegurando que concuerda con el digest de la estampilla de tiempo y también verifica que la firma de la TSA, sea la que esta en la estampilla de tiempo. Dos cosas que se destacan del time stamping, que pueden ser útiles, para afianzar la integridad del certificado digital de la TSA son: La TSA basa su seguridad en autenticación con certificados digitales y segundo, el certificado digital de la TSA puede ser renovado automáticamente para que sea valido indefinidamente. La aplicación debe seguir los estándares internacionales usados en una PKI. El estándar oficial para el manejo de las estampillas de tiempo en una PKI es el. Time. Stamp Protocol (TSP), que está especificado en la RFC (Request for Comment) 3161 del grupo Internet X.509 Public Key Infrastructure. La aplicación va a usar este protocolo, para las transacciones entre la TSA y el cliente que solicita una estampilla de tiempo.. 5.11 Time Stamp Protocol. Los servicios de no repudio requieren la habilidad de establecer la existencia de los datos antes de una fecha específica. El protocolo TSP es usado como soporte para. 22.
(23) estos servicios. Un ejemplo de cómo probar que una firma digital fue creada durante el periodo de validez de un certificado de llave pública, es presentándolo como un anexo. En orden de asociar un dato con un punto particular en el tiempo, la TSA necesita ser usada. Esta entidad, provee la prueba de existencia, para un dato en particular en un instante de tiempo. En este RFC, no se establecen requerimientos de seguridad en su totalidad para la transacción TSA, como otros estándares de PKI, este no establece requerimientos para la autorización para la CA. En vez de esto, se supone que la TSA, le ha hecho saber a sus clientes las políticas que implementa para asegurar la generación de las estampillas de tiempo, y los clientes harán uso de los servicios de la TSA solo si ellos están satisfechos con estas políticas.. 5.12 Transacciones de la TSA Como primer mensaje de este mecanismo, la entidad que hace la petición, pide una estampilla de tiempo, enviando una petición, (la cual incluye un TimeStampReq, que es definido más adelante) a la TSA. Como segundo mensaje, la TSA responde, enviando una respuesta (la cual incluye un TimeStampResp), a la entidad solicitante. Además de recibir la respuesta de la TSA (que incluye un TimeStampResp y un TimeStamp Token), esta entidad debe verificar el estado de error devuelto en la respuesta, y si no hay error alguno, debe verificar la validez de los campos del TimeStampToken y la validez de la firma digital, de la TSA. En particular debe verificar que la estampilla de tiempo, corresponda a la que solicitó, además verificar que el token contenga el certificado que identifica a la TSA, y que este no este revocado en una CRL (Certification Revoke List), además que el digest enviado sea el que solicitó y el OID del algoritmo de hash usado. También se verifica, la línea de tiempo de respuesta, verificando el tiempo incluido en la respuesta, contra una fuente confiable de tiempo local, si esta está disponible. O el valor de un número “nonce” (cifra de varios números, con una probabilidad alta de ser generado por el cliente solo una vez) incluido en la respuesta, comparado con el valor. 23.
(24) incluido en la petición. Si alguna de estas validaciones falla, el TimeStampToken debe ser rechazado. Fuera de esto el cliente debe verificar el campo de política, para saber si esta de acuerdo con las políticas que le ofrece la TSA, para poder usar la aplicación.. Ejemplo TSA. Medios de Transporte No hay mecanismos de transportes mandatorios para los mensajes en la TSA en el RFC. Los mecanismos descritos son opcionales, mecanismos adicionales pueden ser añadidos en el futuro. Estos son:. -. Correo electrónico. -. Protocolo basado en archivos. -. Protocolo basado en sockets. -. Protocolo basado en http. Hay que aclarar que la TSA no valida al solicitante, para poner una estampilla de tiempo. Para esta validación se tiene que usar el módulo de la PKI, al que le corresponde esta función.. 24.
(25) 5.13 Beneficios de la TSA. Con la TSA se tiene un soporte para verificar que un documento fue firmado en una fecha y hora en específico, además se tiene el modo de probar que un documento fue hecho o editado por una persona y que el documento no fue alterado por alguien más. Con la implementación de esta, se puede probar legalmente que un documento fue firmado a una fecha en específico, y no antes o después (no repudiación). 6. ANÁLISIS, PROPUESTA Y ALCANCE. Dado el marco teórico de la PKI, y de la TSA, se realizó el diseño de la aplicación, en la cual se identificaron los siguientes requerimientos funcionales y no funcionales:. 6.1. Requerimientos Funcionales de la TSA. -. Incluir un valor del tiempo de fuente confiable, en cada estampilla de tiempo.. -. Producir una estampilla de tiempo, solo hasta recibir una petición válida del solicitante. (Una. petición. válida. es. aquella. que. se. puede. decodificar. correctamente). -. Firmar cada estampilla de tiempo usando una llave generada exclusivamente para este propósito.. -. Usar una fuente valida y confiable del tiempo.. -. Generar un log por cada transacción realizada.. 6.2. Requerimientos no Funcionales. -. Incluir un identificador (entero) para cada estampilla de tiempo generada.. -. Incluir dentro de cada estampilla de tiempo un identificador que indique las. políticas de seguridad bajo las cuales fue creado el token. - Solamente se le pondrá estampilla de tiempo a la representación hash del dato.. 25.
(26) -. Examinar el OID (Object Identifier) de la función hash usada y verificar que el. tamaño de esta sea consistente con el algoritmo de hash usado (ej. 20 bytes para SHA-1 o 16 bytes para MD5). -. La estampilla de tiempo no tiene ningún identificador de la entidad que hace la. petición.. 6.3. Requerimientos de la aplicación. -. Aplicar una función hash segura al documento que se quiere enviar para poner la estampilla de tiempo.. -. Enviar el digest a la TSA. -. Verificar el digest que recibió de la TSA sea el mismo del documento a la cual se le aplicó la función hash, junto con la estampilla de tiempo. -. Verificar la firma digital de la TSA.. -. Informar al usuario, la fecha y hora de la estampilla de tiempo, que tiene un documento.. Los casos de uso, diagramas de secuencia y diagrama de clase, se pueden ver en la sección anexos.. Para poder diseñar la aplicación, se tiene que tener en cuenta, la infraestructura actual del banco, que tiene lo siguiente:. •. Entidad de Registro (RA): Este componente es el encargado de autenticar y registrar ante la PKI los usuarios que en ella actuarán. Entre sus funciones se tiene: atender y validar solicitudes, aprobar o rechazar solicitudes, registrar las solicitudes y por último informar a la entidad de certificación sobre la existencia de un nuevo usuario en la PKI,. •. Entidad de Certificación (CA): La entidad de certificación es quien administra las credenciales de los usuarios. A cada usuario una vez solicita y se le aprueba la solicitud de ingreso, se le genera un par de llaves (privada y pública). La privada siempre permanece con el usuario; la pública es almacenada en una estructura. 26.
(27) administrada por la PKI denominada certificado digital. A través de este certificado se puede garantizar que la llave pública si pertenece a un usuario determinado. Las funciones de las entidades de certificación son: expedir y revocar certificados, generar copias de certificados, permitir que ciertos certificados expiren por alguna circunstancia justificada, manejar el histórico de certificados de los usuarios y administrar listas de certificados revocados. •. Servicios de validación de certificados: Estos servicios son el día a día del esquema de certificación. A través de ellos se constata la validez de un certificado que pretende ser utilizado para tramitar alguna operación,. •. Herramientas de gestión (lado cliente y servidor): Son partes de software que permite acoplarse a productos existentes para que puedan hablar en términos de la infraestructura propuesta por la PKI. Un ejemplo de esto es la parte de seguridad que se le adhiere al correo electrónico que le permite manejar correos seguros y firmados,. •. Herramientas para desarrollar nuevas aplicaciones en términos de la PKI: Son parte de código que permiten crear nuevas aplicaciones que puedan integrase a la PKI.. La infraestructura del banco, permite desarrollar aplicaciones, bajo el lenguaje de programación JAVA, además que la empresa proveedira tiene un API (Application Program. Interface),. en. este. mismo. lenguaje,. que. cumple. los. estándares. internacionales, para desarrollar la TSA. 6.4. Alcance. La aplicación TimeStampAuthority funcionará bajo un entorno web (servlets + JSP’s), en el cual usuario registrado en la PKI, se podrá autenticar ante la RA (Registration Authority), obtener su certificado digital, y después podrá firmar documentos y verificar la firma de estos por medio de la aplicación. Además de esto se implementará una GPO (Global Policy Object), en el entorno Windows, para que un solo usuario pueda manejar la aplicación, (cambiar la hora del sistema y subir y bajar la aplicación.). 27.
(28) La TSA se integrará con la PKI que está montada en el Banco de la República, para que esta tome el rol de autoridad segura del tiempo en la PKI del banco. Ademas d será operada como un servicio TTP (Trusted Third Party).. 28.
(29) 7. IMPLEMENTACIÓN. A continuación se presentan detalles relacionados con la implementacion de la aplicación. Los requerimientos estáticos (páginas html) los sirve un servidor web Apache v 1.3.29, que corre bajo la plataforma Solaris. Este servidor trabaja sopre el protocolo Secure Sockets Layer (SSL), que hace que la información que se recibe del cliente y hacia el cliente este siempre cifrada. Los requerimientos dinámicos (Servlets + páginas JSP’s), los sirve el contenedor Web Apache Tomcat v. 5.0. Para que la aplicación funcionara de esta forma, se implementó un protocolo del servidor Apache que permitía que reconociera, cuales páginas las servia el mismo, y cuales el application server. La aplicación cuenta con la función de timeout, lo cual permite terminar la sesión de un usuario si este no realiza ninguna operación después de cierto periodo de tiempo.. -Autenticación:. Es el medio por el cual los usuarios pueden identificarse y ser validados por el sistema. La forma mas común de autenticación, es presentando un usuario y una contraseña. Pero también existen otras técnicas que pueden ser utilizadas en los sistemas, como los certificados digitales, tarjetas inteligentes, biométricos, etc.. En el caso de la TSA, existen dos tipos de autenticación:. - Roaming user - Desktop user. En el caso de roaming user, el usuario ingresa un nombre de usuario y una clave, la aplicación, recibe estos dos parámetros, va ante la entidad de registro de la PKI,. 29.
(30) verifica que está en el sistema,. luego va al directorio LDAP de la PKI, extrae el. certificado digital del usuario, verifica que este no este registrado en la Certification Revocation List (CRL) de la PKI, y después carga en memoria del computador cliente el certificado, para que este pueda firmar los documentos via web.. Desktop user. La autenticación por medio de este método se diferencia de la anterior, porque el usuario no se autentica con un nombre de usuario y clave, sino que el usuario indica un archivo en donde esta guardado su certificado digital, y escribe su clave, con esta información la aplicacion verifica que el certificado digital exista en el sistema y no esté revocado, después de esto el usuario ya puede proceder a firmar los documentos digitalmente.. 30.
(31) - Firmar Archivo Esta opción permite firmar digitalmente cualquier archivo de texto o binario con el certificado digital del usuario, además de esto cuanto se firma el archivo, se agrega la estampilla de tiempo al archivo, para saber en qué instante de tiempo fue firmado el archivo.. 31.
(32) El usuario selecciona un archivo, después de esto, la aplicación solicita la clave de la persona de nuevo, y si es correcta, procede a firmar el archivo con las credenciales del usuario. Si el proceso tuvo éxito la aplicación muestra una página, en donde informa que el archivo ha sido firmado correctamente e informa de un link donde el usuario puede obtener su archivo firmado, para que este lo distribuya a las personas interesadas, ya sea vía correo electrónico, u otro medio. El formato por el cual se firma el archivo es el PKCS7, el cual se describe a continuación: Formato PKCS7 Para firmar digitalmente cualquier archivo, existe el estándar PKCS-7 o la evolución de este que se llama. CMS (Cryptographic Message Syntax, RFC-2630).. 32.
(33) El formato PKCS-7 fue el que se utilizó para firmar digitalmente los documentos y adicionalmente agregar la estampilla de tiempo. El formato PKCS-7 es el estándar oficial de RSA para en manejo de “sobres seguros” (RFC-2315). Además es el formato para firmar y/o cifrar datos con técnicas simétricas o asimétricas. Algunas de las ventajas del formato son: -. Puede tener en el mismo archivo varias firmas (con jerarquía o paralelas). -. En el mismo archivo contiene las CRLs (Certification Revocation Lists), y los certificados digitales.. -. Es un formato recursivo (Un archivo que ya ha sido firmado previamente, puede volverse a firmar y así sucesivamente). Esquema General de PKCS-7. Información general del archivo. Tipo de contenido Contenido 1…n Tipo de contenido Contenido. PKCS-7 Tipo de Contenido - Datos Codificación (encoding) de una secuencia genérica de bytes.. 33.
(34) - Datos Firmados Dados + firmas digitales (1..N, paralelas). - Datos envueltos (enveloped Data) Datos cifrados simétricamente + llave. - Digest Data datos + digest. PKCS-7 Esquema de datos firmados. Datos Firmados Contenido Versión algoritmo ContentInfo Certificados. Versión. CRLs SignerInfo Timestamp. Entidad Cert. HashCifrado. - Ver Firma Archivo. 34.
(35) Este modulo de la aplicación permite ver y verificar la firma digital de un archivo, además de mostrar la estampilla de tiempo, y obtener el archivo original. Para poder acceder a esta función, el usuario tiene que estar autenticado ante el sistema Como se puede observar en la imagen, si el archivo fue firmado por medio de la aplicación, mostrará los datos referentes al usuario que firmó el archivo, además de los datos de timestamping, y también tendrá un link donde el usuario podrá obtener el archivo original.. -. Cambiar Clave. Esta opción de la aplicación permite cambiar la clave del usuario, cumpliendo con las políticas de seguridad implementadas para ello, es decir que la clave debe tener al menos ocho (8) caracteres, incluyendo mayúsculas, minúsculas, números, caracteres especiales, además que la clave no puede contener el nombre de usuario, ni ser la misma que la clave actual, y tampoco puede repetir caracteres.. 35.
(36) Esto permite que la clave que se usa, sea una clave “segura”, ya que baja la probabilidad de ser capturada, mediante un ataque de diccionario, y usando un ataque de fuerza bruta, se puede demorar mucho tiempo en obtenerla.. - Salir del Sistema Esta opción, borra las cookies, y cualquier información del usuario, al terminar la sesión en la aplicación.. 36.
(37) 8. CONCLUSIONES Y TRABAJO FUTURO. La implementación de una Infraestructura de Llaves Públicas (PKI), es una muy buena opción, para incrementar la seguridad de una entidad, ya que permite cumplir. a. cabalidad. (confidencialidad,. los. principios. integridad,. básicos. disponibilidad,. de. la. seguridad. autenticación,. informática. autorización,. no. repudiación y observancia) de la información. La implementación en el Banco de la República, ha sido muy exitosa, ya que se ha reducido el número de sistemas de autenticación que se tenían, además que se ha incrementado el uso de documentos digitales, y se ha disminuido notablemente la impresión de los documentos, para firmarlos con la firma tradicional. Se espera que la aplicación de autoridad del tiempo, se esté usando próximamente, después de hacer pruebas de rendimiento, además de concienciar a los usuarios de la importancia de la estampilla. de tiempo, para verificar la validez de un. documento.. 37.
(38) Trabajo Futuro. Para complementar la aplicación, se espera crear la política global de objetos en Windows, para que solo una persona pueda administrar la aplicación, ademas que solo esa persona sea autorizada para modificar la hora de la máquina en la que está corriendo la aplicación. Hay que aclarar, que las máquinas que están en el Banco de la República, están sincronizadas, con un servidor principal, que permite tener la hora de las máquinas igual.. 38.
(39) REFERENCIAS BIBLIOGRÁFICAS - http://www.entrust.com/authority/timestamp (Entrust timestamping) - http://www.rsasecurity.com/rsalabs/faq/7-11.html (what’s s a digital timestamping) - http://www.ietf.org/rfc/rfc3161.txt (Internet X.509 Public Key Infrastructure Time Stamp Protocols (TSP) (RFC 3161)) - https://digitalid.verisign.com/client/help/id_intro.htm (What is a digital ID). 39.
(40) 9 9.1. ANEXOS. Glosario. API (Application program Interface): Conjunto de funciones, rutinas, protocolos y herramientas, para que los desarrolladores programen aplicaciones, para un ambiente en específico. Certificado: Información de varios tipos que es un formato estándar, que es firmado digitalmente por una autoridad certificadora (CA).. Certification Authority (CA): Módulo perteneciente a una PKI que asegura la veracidad de las identidades electrónicas (certificados, políticas, listas de revocación de certificados), ademas firma los certificados con su llave para esta operación. certificate revocation list (CRL): Certificado firmado, que contiene los seriales de los certificados de llaves públicas que han sido revocados, además de la razón por la cual fueron revocados. Distinguished Name (DN): Nombre completo, que identifica a una persona o una entidad.. 40.
(41) 9.2. Diagramas. 41.
(42) 42.
(43) 43.
(44) 44.
(45) 9.3. Casos de Uso. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Resumen: Curso Básico Eventos:. TSAAdmin1 Subir servicio TSA Opcional Baja Caso de uso, para que un usuario autorizado pueda subir el servicio de time stamping 1. El usuario ingresa el login de entrada. 2. El usuario ingresa el password para ingresar al sistema. 3. El sistema valida las entradas del usuario.(Exp. 1) 4. El usuario carga el certificado digital de la TSA (TSAAdmin3) 5. La aplicación obtiene la dirección IP del servido, para que el cliente pueda saber en que dirección está atendiendo la TSA. 5. El usuario activa el servicio de TimeStamping de la aplicación servidor. Caminos de Excepción: Pre-condiciones:. Exp. 1: No corresponden las entradas de login y password del .epf, por lo tanto se niega el acceso, y no puede subirse el servicio de la TSA. 1.El servicio de time stamping, va a utilizarse como un servicio de windows, por lo que cuando el usuario quiera activar el servicio, por la opción de servicios de windows, la aplicación, le mostrará la pantalla de login de la aplicación 2.Login = string ; password= string. 3. Tiene que estar creado y guardado el archivo .epf (entrust profile), creado exclusivamente para la TSA, donde está guardado lo siguiente: • • • • • • •. Post- Condiciones:. Autor: Fecha:. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Resumen: Curso Básico Eventos:. User's distinguished name (DN) User's decryption private key User's signing private key Decryption private key history Verification and encryption public certificates CA's verification public certificate Options specific to an Entrust PKI. El sistema permite el acceso del usuario si el login y password corresponden al archivo .epf de la TSA, de lo contrario niega el acceso del usuario al sistema, después de esto, el usuario activa el servicio de TimeStamping, que finalmente lo que hace es subir el servicio de Windows de la TSA Elkin Mauricio Ortiz M. 15 de marzo de 2004. TSAAdmin2 Bajar Aplicación. Opcional Baja Caso de uso, para que un usuario autorizado pueda bajar el servicio de time stamping 1. El usuario ingresa el login de entrada. 2. El usuario ingresa el password para ingresar al sistema. 3. El sistema valida las entradas del usuario.(Exp. 1) 4. El usuario baja el servicio de TimeStamping de la aplicación servidor. Caminos de Excepción: Pre-condiciones:. Post- Condiciones:. Exp. 1: No corresponden las entradas de login y password del .epf, por lo tanto se niega el acceso, y no puede bajarse el servicio de la TSA. 1.El servicio de time stamping, va a utilizarse como un servicio de windows, por lo que cuando el usuario quiera activar el servicio, por la opción de servicios de windows, la aplicación, le mostrará la pantalla de login de la aplicación 2.Login = string ; password= string. El sistema permite el acceso del usuario si el login y password corresponden al archivo .epf de la TSA, de lo contrario niega el acceso del usuario al sistema, después de esto, el usuario baja el servicio de TimeStamping, que finalmente lo que hace es bajar el servicio de Windows de la TSA. 46.
(46) Autor: Fecha:. Elkin Mauricio Ortiz M. 15 de marzo de 2004. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Resumen:. TSAAdmin3 Cargar Entrust profile. Necesario Alta Cargar el archivo necesario para que la TSA, pueda firmar los timestamp tokens, que contienen la petición de timestamp por parte del cliente. 1. El usuario abre un dialogo de buscar un archivo (seleccionar archivo) y escoge el archivo .epf de la TSA.. Curso Básico Eventos:. 2.. el usuario carga el archivo. Pre-condiciones:. No existe el archivo .epf por lo cual no se carga el servicio El archivo .epf no corresponde al de la TSA, por lo cual no es válido usarlo, El archivo .epf de la TSA debe estar guardado localmente.. Post- Condiciones: Autor: Fecha:. El sistema carga el archivo de la TSA, con que puede firmar las transacciones. Elkin Mauricio Ortiz M. 15 de marzo de 2004. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Resumen: Curso Básico Eventos:. TSAAdmin4 Administrar Puerto TSA. Necesario Baja Se cambia el puerto por el cual la TSA atiende los requerimientos del cliente. 1. El usuario escoge el puerto por el cual desea que la TSA atienda los requerimientos del cliente.. Caminos de Excepción:. Caminos de Excepción: Pre-condiciones:. 2.. La aplicación verifica que el puerto a escoger no este en uso, y no pertenezca a otro servicio (Ej. Pto 80).. 3.. la TSA reinicia el servicio, para cargar la nueva configuración del puerto.. 4.. la TSA atiende los requerimientos por el nuevo puerto.. El puerto escogido es utilizado por otro servicio, por lo cual no se puede escoger. 1. El puerto debe ser un número entre 0 y 65535. 2. El usuario debe estar logueado en la aplicación. Post- Condiciones: Autor: Fecha:. El servidor atiende los requerimientos por el nuevo puerto escogido. Elkin Mauricio Ortiz M. 15 de marzo de 2004. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Resumen:. TSAAdmin5 Administrar logs TSA. Deseable Baja Se cambia el archivo donde la TSA, guarda los logs de las transacciones realizadas. 1. El usuario selecciona el archivo donde desea que se guarde los logs de las transacciones realizadas sobre el sistema. (Esto se hace seleccionando el archivo mediante Windows). Curso Básico Eventos:. 2.. El usuario carga el archivo de Log. Caminos de Excepción: Pre-condiciones:. El archivo no existe, por lo cual hay que crear un nuevo archivo El archivo de Log, debe tener la extensión .log. Post- Condiciones: Autor: Fecha:. El servidor guarda los logs de las transacciones en el archivo escogido. Elkin Mauricio Ortiz M. 15 de marzo de 2004. 47.
(47) Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Resumen:. Curso Básico Eventos:. Caminos de Excepción: Pre-condiciones:. Post- Condiciones: Autor: Fecha:. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Resumen: Curso Básico Eventos:. TSAAdmin6 Copiar archivo de Log en máquina segura. Deseable Baja Todos los días a las 11:59 PM la aplicación servidor copia el archivo Log de las transacciones y lo guarda en otra máquina, donde el administrador de l TSA no tiene acceso. Si se puede se hace Log centralizado por medio del estándar de syslog 1. la aplicación hace una copia del archivo .Log vigente en el momento de hacer el proceso. 2.. la aplicación guarda el archivo en una máquina en la cual tenga permisos de copiar archivos.. 3.. la aplicación guarda una copia exacta del Log local, para posterior verificación del archivo. La aplicación no puede guardar el archivo en la otra máquina, por lo cual se cancela la acción La aplicación servidor debe tener permisos de copiar el archivo .Log en la máquina remota. La aplicación guarda copia del Log en otra máquina para asegurar su integridad, por parte del administrador local. Elkin Mauricio Ortiz M. 15 de marzo de 2004. TSAClient1 Autenticar Usuario Necesario Alta El usuario cliente se autentica en la aplicación, para que pueda usar los servicios de esta. 1. El usuario ingresa el login de usuario que tiene en la PKI del Banco de la República. Ej: 79693388-usuprueba-00-01000-01 2.. El usuario ingresa la clave correspondiente al login. 3.. El usuario entra a la aplicación si el usuario y la clave son correctos. 4.. El usuario cuando se autentica al sistema queda autorizado para usar la aplicación.. 5.. El usuario accede su roaming profile, que está guardado en el directorio LDAP de la PKI, y se carga en memoria.. Post- Condiciones: Autor: Fecha:. El nombre de usuario y/o la clave están errados, por lo cual no se puede usar la aplicación Usuario= string, clave = string El roaming server debe estar funcionando, así como el directorio LDAP de la PKI El usuario queda autorizado a usar los servicios de la aplicación. Elkin Mauricio Ortiz M. 16 de marzo de 2004. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Resumen: Curso Básico Eventos:. TSAClient2 Especificar dirección IP y puerto de la TSA a utilizar Necesario Baja El usuario específica la dirección IP y el puerto, donde atiende l TSA 1. El usuario escribe la dirección IP de la TSA. Caminos de Excepción: Pre-condiciones:. Caminos de Excepción:. 2.. El usuario escribe el puerto de la TSA. 3.. El usuario verifica la información escrita. 4.. la TSA informa que puede atender especificaciones que dio el usuario. requerimientos. con. las. La TSA no se encuentra disponible, o no existe ninguna TSA que atienda por esa dirección IP y por ese puerto, por lo que el usuario debe especificar otra. 48.
(48) Pre-condiciones: Post- Condiciones: Autor: Fecha:. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Resumen: Curso Básico Eventos:. dirección IP y oro puerto El usuario debe estar autenticado en la aplicación Dirección IP: int , puerto: INT La TSA verifica que puede atender en la dirección IP y el puerto que especificó el usuario. Elkin Mauricio Ortiz M. 16 de marzo de 2004. TSAClient3 Cargar documento a firmar Necesario Alta El usuario carga el documento que quiere firmar o al cual quiere revisar la firma digital, y “desencriptar” 5. El usuario abre un dialogo, de seleccionar un archivo de Windows. 6.. Caminos de Excepción: Pre-condiciones: Post- Condiciones: Autor: Fecha:. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Resumen:. Curso Básico Eventos:. El usuario selecciona el archivo, y carga el documento a firmar.. El usuario no puede cargar el documento, por que no existe El usuario debe estar autenticado en la aplicación El archivo a firmar debe estar creado previamente El usuario carga el archivo que quiere firmar, o al cual quiere revisarle la firma digital, y el cual quiere “desencriptar” Elkin Mauricio Ortiz M. 16 de marzo de 2004. TSAClient4 Firmar Documento Necesario Alta El usuario firma el documento con su firma digital, y la TSA válida la fecha y hora en que se hizo este proceso. Se crea un nuevo archivo que tiene la firma digital y la validación de la TSA de la fecha y hora exacta en que se firmó el documento. 1. La aplicación saca el digest del archivo a firmar. 2.. La aplicación firma el digest del archivo, con la llave privada del usuario, guardada en el roaming profile.. 3.. la aplicación crea una copia del documento original, y le agrega la firma digital del usuario que se acaba de hacer.. 4.. La aplicación saca el digest al archivo firmado.. 5.. la aplicación cliente crea un request con este digest y lo envía a la TSA. 6.. la TSA crea un time stamp token que contiene el digest enviado en el request más la estampilla de tiempo (fecha y hora en que recibió el request), este time stamp token debe ir firmado con la llave privada de la TSA.. 7.. La estampilla de tiempo se añade al archivo firmado previamente.. 8.. Se crea el archivo firmado y con la estampilla de tiempo en el disco duro, añadiendo la extensión .ent (Ej. prueba.txt.ent). 9.. Se verifica que el certificado digital no este revocado (TSAClient5).. 10. Se genera un Log de la transacción (TSAClient6) Caminos de Excepción:. Pre-condiciones: Post- Condiciones: Autor:. No se pudo crear la estampilla de tiempo, por lo cual se aborta la operación. El certificado digital de la TSA no es válido, por lo cual no sirve la estampilla de tiempo. El usuario debe estar autenticado en la aplicación. El archivo a firmar ya debe estar cargado El usuario firma el archivo con su firma digital, y la TSA garantiza la fecha y hora en que se hizo esta operación. Elkin Mauricio Ortiz M.. 49.
(49) Fecha:. 16 de marzo de 2004. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Resumen: Curso Básico Eventos:. TSAClient5 Verificar certificado digital TSA Necesario Alta La aplicación verifica el certificado digital de la TSA 1. Cuando se firma el documento, la aplicación verifica que el certificado digital, de la TSA, no se encuentre en una CRL (certification revoke list). 2.. Caminos de Excepción: Pre-condiciones: Post- Condiciones: Autor: Fecha: Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Resumen: Curso Básico Eventos:. La aplicación termina el proceso de firmar el documento, ya que la firma digital que se genero con la llave privada de la TSA guardada en el certificado digital de la TSA es válida.. La aplicación no firma el documento, cancela la operación e informa al usuario que el certificado digital de la TSA no es válido, Usuario= string, clave = string El roaming server debe estar funcionando, así como el directorio LDAP de la PKI El usuario queda autorizado a usar los servicios de la aplicación. Elkin Mauricio Ortiz M. 16 de marzo de 2004 TSAClient6 GenerarLog Necesario Media La aplicación genera un Log del proceso de firmar un documento, así la transacción haya sido exitosa o no se haya podido realizar. 1. cuando se firma un documento, en la TSA se crea un Log de lo ocurrido en la transacción.. Autor: Fecha:. Por un error inesperado no se genera el Log, y no queda rastro de la transacción. TSA debe estar funcionando correctamente Se crea un registro de Log de la transacción realizada, no importa si es exitosa o no. Elkin Mauricio Ortiz M. 16 de marzo de 2004. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Resumen: Curso Básico Eventos:. TSAClient7 Ver certificado digital TSA Deseable Baja La aplicación muestra los detalles del certificado digital de la TSA 1. el usuario escoge la opción de ver certificado digital de la TSA. Caminos de Excepción: Pre-condiciones: Post- Condiciones:. 2.. la aplicación carga la parte pública del certificado digital de la TSA. 3.. La aplicación muestra los detalles del certificado previamente (versión algoritmo utilizado, emisor, etc.). digital. cargado. Post- Condiciones: Autor: Fecha:. La aplicación no puede mostrar los detalles del certificado digital, porque este no tiene un formato correcto El usuario debe estar autenticado La parte pública del certificado digital, debe ser correcta. El usuario observa los detalles del certificado digital de la TSA Elkin Mauricio Ortiz M. 16 de marzo de 2004. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Resumen:. TSAClient8 Ver certificado digital Usuario Deseable Baja La aplicación muestra los detalles del certificado digital del usuario autenticado. Caminos de Excepción: Pre-condiciones:. 50.
(50) Curso Básico Eventos:. 4.. el usuario escoge la opción de ver su certificado digital. 5.. la aplicación carga la parte pública del certificado digital.. 6.. La aplicación muestra los detalles del certificado previamente (versión algoritmo utilizado, emisor, etc.). digital. cargado. Post- Condiciones: Autor: Fecha:. La aplicación no puede mostrar los detalles del certificado digital, porque este no tiene un formato correcto El usuario debe estar autenticado La parte pública del certificado digital, debe ser correcta. El usuario observa los detalles del certificado digital del usuario Elkin Mauricio Ortiz M. 16 de marzo de 2004. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Resumen: Curso Básico Eventos:. TSAClient9 Ver documento original sin firma Necesario Alta La aplicación “desencripta ” el archivo firmado y lo deja en su estado original 1. El usuario carga el documento (TSAClient3).. Caminos de Excepción: Pre-condiciones:. Caminos de Excepción: Pre-condiciones:. Post- Condiciones: Autor: Fecha:. Identificador Nombre Caso de Uso: Necesario/Deseable Prioridad Resumen: Curso Básico Eventos:. Caminos de Excepción: Pre-condiciones:. Post- Condiciones: Autor: Fecha:. 2.. la aplicación copia el fragmento del archivo original, sin firma digital y sin estampilla de tiempo. 3.. la aplicación crea el archivo original, con la copia que se obtuvo en el anterior paso. (se quita la extensión .ent y queda la extensión original prueba .txt). 4.. la aplicación informa que el archivo original, ya fue copiado a la carpeta.. 5.. El usuario puede ver el archivo, con la aplicación que abre el archivo (.txt lo abre Notepad). La aplicación no puede hacer el proceso, por lo cual saca una pantalla de error El usuario debe estar autenticado Debe existir un archivo con extensión .ent El archivo debe estar cargado en la aplicación El archivo original es copiado del archivo firmado, y el usuario lo puede ver con su aplicación de preferencia Elkin Mauricio Ortiz M. 16 de marzo de 2004. TSAClient10 Ver Propiedades de documento (estampilla de tiempo y persona que firmó el documento) Necesario alta La aplicación muestra fecha, hora y persona que firmo el documento 1. El usuario carga el documento (TSAClient3). 2.. el usuario escoge la opción de ver los detalles del documento. 3.. la aplicación saca los datos de la estampilla de tiempo y de la firma digital del documento.. 4.. la aplicación muestra la fecha, hora y persona que firmó el documento. La aplicación no puede mostrar esta información, por lo que muestra una pantalla de error El usuario debe estar autenticado El archivo debe estar cargado El archivo debe ser correcto El usuario observa las propiedades del documento (fecha y hora de la firma, además del nombre de la persona que firmó el documento) Elkin Mauricio Ortiz M. 16 de marzo de 2004. 51.
(51)
Documento similar