FIRMA DIGITAL Y SELLADO DE TIEMPO Prof. Vincenzo Mendillo Septiembre 2009 Objetivo Familiarizarse con el uso de la función hash, firma digital y sellado de tiempo para asegurar la integridad, autenticidad y no repudio de las transacciones en red.

Requisitos Se aconseja leer o efectuar previamente las prácticas sobre Criptografía de clave pública y Certificados digitales y PKI. Estudiar previamente la clase Integridad y autenticidad de la información.

Sección A: Introducción Uno de los aspectos decisivos para afianzar las transacciones electrónicas en nuestra incipiente “Sociedad de la Información” es que exista una plataforma tecnológica y jurídica que garantice las operaciones que se hagan en el mundo digital. Pero si ya es complicado actualmente demostrar la validez de un documento escrito, firmado y notariado, la dificultad probatoria será mayor en el futuro cuando la firma se convierta en una serie de bits intangibles. A las personas que todavía basan sus acuerdos en estampar una firma escrita, les resultará difícil recurrir a la realidad virtual para sellar sus acuerdos en Internet! Analizando esta situación, se comprende que será necesario reemplazar el tradicional soporte físico por un proceso virtual donde no exista papel, tinta y sobre todo, una firma estampada. Sin embargo debemos comprender que esto plantea un nuevo problema: el de acreditar tanto la autenticidad como la autoría de los documentos electrónicos. Una característica básica de un documento auténtico es su integridad, y en un documento tradicional como un contrato o cheque, si se aprecian modificaciones o tachaduras, el mismo es invalidado. De manera similar, cuando por errores de transmisión, fallas en el medio de almacenamiento o intencionalmente, se modifica el contenido de un documento electrónico, entonces dicho documento pierde su integridad y por tanto su autenticidad. Concretamente, para que dos sujetos puedan intercambiar entre ellos documentos electrónicos de forma segura, deben cumplirse al menos los siguientes requisitos: 1) Integridad, que implica la certeza de que el documento no haya sufrido alteración alguna. 2) Autenticidad, que implica poder atribuir, sin lugar a dudas, la autoría del documento a una determinada persona. 3) No-repudiación, que implica que el autor del documento no pueda negar en ningún caso su autoría. Pues bien, las firmas digitales pueden ser consideradas como procedimientos técnicos que tratan de dar respuesta a las necesidades apuntadas anteriormente, a fin de posibilitar las transacciones legales, fiscales, financieras y comerciales por medios electrónicos. La tecnología de firma digital basada en la infraestructura de clave pública (PKI) permite en la actualidad que se intercambien documentos electrónicos con la plena confianza acerca de la identidad de los emisores y la integridad de los datos que contienen. En numerosos países, la promulgación de leyes sobre la firma digital ya permite que la factura electrónica, así como otros actos y contratos firmados por este mecanismo, sean legalmente válidos y tengan el mismo efecto que los celebrados por escrito, con la ventaja adicional de la reducción del costo de transacción y la garantía de mayor eficiencia y productividad. Función hash y MAC Una forma muy utilizada para detectar las alteraciones en un mensaje digital M, es usar la función hash la cual produce una huella digital H(M) efectuando un resumen del mensaje (también llamado extracto o digesto).

-2-

Ese resumen se anexa al mensaje y es conocido como Message Authentication Code (MAC). Para verificar que el mensaje no fue alterado, se recalcula el MAC del documento y se compara con el MAC anexo al mensaje.

Si los MAC son distintos, el mensaje fue alterado. Si en cambio son iguales, el mensaje probablemente está intacto. Pero no se puede tener la certeza de que está intacto, ya que un intruso podría eventualmente haber interceptado y alterado el mensaje, recalculando el MAC para que no se detecte la alteración. El MAC cumple una función parecida a los códigos detectores de errores (como CRC), pero de una forma muy superior, ya que posee las siguientes propiedades: 1. H puede ser aplicada a mensaje de datos de cualquier longitud. 2. H produce una salida de longitud fija. 3. H(M) es relativamente fácil de computar 4. Dado un resumen m, es computacionalmente infactible encontrar M de la forma H(M) = m. 5. Dado un mensaje cualquiera M, es virtualmente imposible encontrar M’ diferente de M y tal que H(M’) = H(M). 6. Es virtualmente imposible encontrar un par (M, M’) tal que H(M) = H (M’). Las tres primeras propiedades son requeridas para facilitar la aplicación práctica del sistema. La cuarta propiedad es "one-way". Es decir, es fácil generar el MAC dado un mensaje M, pero virtualmente imposible generar el mensaje M dado el MAC. La quinta propiedad garantiza que no haya “colisiones”, es decir dos mensajes que produzcan el mismo resultado. Una función hash que cumpla la cinco primeras propiedades es una función hash débil. La función hash que además cumpla la sexta propiedad, es una función hash robusta. En la literatura se han propuesto variados algoritmos para realizar la función hash, pero luego se ha mostrado que muchos de ellos son vulnerables. El algoritmo debe ser lo suficientemente bueno para evitar que alguien que conozca el mensaje original NO pueda forjar otro que produzca el mismo MAC. Existe una clase de ataque conocido como el ataque del cumpleaños, llamado así por la analogía de lo fácil que resulta el encontrar dos personas en un mismo grupo que tengan la misma fecha de cumpleaños. Actualmente se dispone de varios algoritmos que tienen amplia aceptación. Uno de ellos es Message Digest 5 (MD5), descrito en RFC 1321 y desarrollado en 1992 por Ron Rivest (el mismo del sistema RSA), el cual produce un resumen de 128 bits. Otro es Secure Hash Algorithm (SHA), el cual fue desarrollado por el National Institute of Standards and Technology (NIST) en 1993 y que produce un resumen de 160 bits. MD5 es uno de los más populares algoritmos de hash, resultado de una serie de mejoras sobre el algoritmo MD4, diseñado por Ron Rivest. Procesa los mensajes de entrada en bloques de 512 bits, y produce una salida de 128 bits. Sin embargo en 1996 se anunció una colisión de hash en MD5 que hizo que los criptógrafos comenzaran a recomendar su reemplazo con SHA-1 o RIPEMD-160. La salida de MD5 de 128 bits es representada típicamente como un número de 32 dígitos hexadecimal. Como ejemplo, el siguiente texto de 28 bytes ASCII es procesado con MD5 para calcular su correspondiente salida hash: MD5("Esto si es una prueba de MD5") = e07186fbff6107d0274af02b8b930b65. Un simple cambio en el mensaje produce un cambio total en el resultado. Por ejemplo, al cambiar dos letras, el "si" por un "no", resulta lo siguiente: MD5("Esto no es una prueba de MD5") = dd21d99a468f3bb52a136ef5beef5034. Compárase con: MD5("Esto si es una prueba de MD5") = e07186fbff6107d0274af02b8b930b65. SHA-1 fue desarrollado como parte del DSS (Digital Signature Standard) por la Agencia de Seguridad Nacional norteamericana (NSA) y se le considera seguro, al menos por ahora. Un documento FIPS (Federal Information Processing Standard), que

-3oficialmente lo describe, afirma que los principios subyacentes a SHA-1 son similares a los de MD4. Existen cuatro variantes adicionales que se han publicado desde entonces, cuyas diferencias se basan en un diseño algo modificado y rangos de salida incrementados: SHA-224, SHA-256, SHA-384 y SHA-512 Todos ellos son referidos como SHA-2. Un ejemplo de la codificación SHA-1 puede ser resumen (en este caso expansión!) del carácter vacío: SHA1("") = da39a3ee5e6b4b0d3255bfef95601890afd80709. RIPEMD-160 es un algoritmo de hash de 160 bits desarrollado en Europa y publicado en 1996. Es una versión mejorada de RIPEMD, que estaba basado sobre los principios del diseño del algoritmo MD4, y es similar en seguridad y funcionamiento al más popular SHA-1. También existen versiones de 128, 256 y 320 bits de este algoritmo, llamadas RIPEMD-128, RIPEMD-256 y RIPEMD-320 respectivamente. Hashed MAC (HMAC) Como se mencionó antes, un intruso podría eventualmente interceptar y alter los mensajes, recalculando el MAC para que no se detecte la alteración. Se puede minimizar este riesgo si se cifra el mensaje, el MAC o el mensaje + MAC. Se le llama HMAC. En la figura se ilustra el caso en que se cifra el hash con una clave secreta K compartida..

Observe que si se cifra con un algoritmo simétrico (por ejemplo 3DES o AES), donde el remitente y el destinatario comparten una clave secreta, entonces tras la comparación, el destinatario no tendría ninguna duda de que dicho mensaje proviene del remitente (más allá de la posibilidad de que la clave pudiese haberse visto comprometida), logrando así la autenticación. Sin embargo este esquema no impide el repudio, porque el remitente pudiera alegar que realmente el mensaje lo produjo el destinatario, con quien compartía el conocimiento de la clave. De hecho, cualquiera de los dos podría haber sido el autor del mensaje. Firma digital El no repudio se puede resolver fácilmente mediante la firma digital, basada en la criptografía de clave pública RSA (Rivest-ShamirAdleman). Con esta técnica, un mensaje se cifra primero con la clave pública y después se descifra con la clave privada. El único que podrá leer ese mensaje encriptado es el destinatario, porque es el único que posee la contrapartida de la clave pública: la clave privada.

A pesar de sus ventajas, los algoritmos de clave pública son computacionalmente pesados y resultan lentos cuando se requiera cifrar un volumen alto de información, por lo que hoy día se usan principalmente en 2 aplicaciones: a) Autenticación y firma digital. b) Distribución de la clave secreta común en un sistema criptográfico convencional como DES, 3DES, AES (los cuales son más rápidos). Para la primera aplicación se utilizan la claves en el siguiente orden: primero la privada y luego la pública, es decir que el mensaje es cifrado con la clave privada. Cuando dicho mensaje llega al destinatario, éste lo “desencriptará” con la clave pública del remitente, que conocía de antemano. Si el resultado es un mensaje legible, entonces sólo pudo haberlo “encriptado” quien dice ser el remitente, pues nadie más conoce esa clave privada. Si, en cambio, si el resultado es un mensaje que es una secuencia de caracteres ininteligibles, el mensaje no fue cifrado utilizando esa clave privada o fue alterado. Sin embargo, cifrar un mensaje completo mediante RSA es una tarea lenta, especialmente para mensajes largos. Además no serviría para mensaje que no contengan texto simple, ya que el mensaje es ilegible. Para solventar esta dificultad, se cifra el resumen o

-4huella digital del mensaje mediante la clave privada del remitente, lo cual produce la firma digital, la cual se agrega al mensaje a enviar. El destinatario separa la firma digital del mensaje y aplica a este último la misma función hash. Seguidamente desencripta con su clave pública la huella digital del mensaje y la compara con la calculada. Si son diferentes, entonces, o bien el contenido del mensaje fue modificado después de ser firmado, o el remitente no es quien afirma ser.

El proceso se ilustra de forma resumida en la siguiente figura:

Como ya se mencionó, la firma digital posee las siguientes propiedades: • Integridad: el que recibe el mensaje puede estar seguro de que éste no ha sido modificado por un tercero. • Autenticidad: El receptor de un mensaje firmado puede estar seguro de la identidad del remitente. • No repudio: el remitente del mensaje no puede negar haberlo enviado. Tome en cuenta que la firma digital no protege la confidencialidad del mensaje. Si se desea también esto, el emisor lo cifra justo antes de enviarlo. Una forma conveniente es cifrar el mensaje (plaintext) con un algoritmo rápido (como 3DES o AES) utilizando una clave de sesión y enviar esa clave junto con el mensaje cifrado (ciphertext). El receptor recupera la clave de sesión con su clave privada y con ella descifra el mensaje. Luego se ocupa de verificar la integridad y la autenticidad mediante la firma digital. El esquema de cifrado y descifrado se ilustra en la siguiente figura.

-5-

En la siguiente figura se ilustra el esquema de firma digital y encriptación para el correo electrónico utilizado en PGP (Pretty Good Privacy):

Donde: EP y DP = encriptación y desencriptación mediante criptografía de clave pública EC y DC = encriptación y desencriptación mediante criptografía de clave convencional KRa = Clave privada de A; KUa = Clave pública de A KRb = Clave privada de B; KUb = Clave pública de B Ks = Clave de sesión Z = Compresión mediante ZIP Z-1 = Descompresión mediante ZIP | | = Concatenación

-6Autoridades de certificación y PKI En la transacciones electrónicas, si el emisor como el receptor ya se conocen y confían el uno con en el otro, se pueden intercambiar directamente sus claves públicas para comprobar los mensajes. Pero usualmente tanto el emisor como el receptor podrían no conocerse directamente o no confían entre sí, pero confían en un tercero o intermediario para intercambiarse sus claves. Una Autoridad de certificación es esa tercera parte de confianza que acredita la unión entre una determinada clave y su propietario real. Estas autoridades emiten certificados de claves de usuarios, firmando con su clave privada el certificado digital de las partes, válido por un período determinado, que asocia el nombre distintivo de un usuario con su clave. Actúan como una especie de notario electrónico que valida un certificado digital, firmándolo con su propia clave privada, para así garantizar la autenticidad de dicha información. En la siguiente figura se ilustra el esquema.

La existencia de autoridades de certificación y de una infraestructura de clave pública (PKI) es extremadamente importante para las transacciones comerciales en línea. Por ejemplo, cuando un cliente le ordene por Internet a un proveedor el envío de una mercancía, el proveedor necesita tener la seguridad de que la orden es genuina y no fue dañada o alterada en el camino. Supóngase además que el proveedor envía la mercancía, e inmediatamente después de esto, el precio de mercado cae abruptamente. Un cliente deshonesto podría aducir que él jamás emitió la orden para comprar dicha mercancía. Cuando el proveedor presente el mensaje ante un juez, el cliente podría negar haber enviado dicha orden. Pero el juez, mediante la firma digital del cliente avalada por una Autoridad de certificación reconocida, puede comprobar que más nadie pudo haber enviado esa orden. Solamente mediante las firmas digitales pueden llevarse a cabo de forma segura contratos, órdenes de compra, pagos, etc. a través de las redes. Ya existen muchos países donde se hacen uso de firmas electrónicas para la presentación de declaraciones y trámites diversos, por ejemplo: Colombia, Corea, Chile, Dinamarca, Eslovaquia, España, Estados Unidos, Finlandia, Francia, Holanda, Hungría, Irlanda, Islandia, Italia, Japón, México, Suecia, Turquía. En Venezuela se dispone de la Ley sobre Mensajes de Datos y Firmas Electrónicas (Decreto 1.024 del 10-02-2001) y algunos de sus artículos relevantes son los siguientes: Artículo 16. La Firma Electrónica que permita vincular al Signatario con el Mensaje de Datos y atribuir la autoría de éste, tendrá la misma validez y eficacia probatoria que la ley otorga a la firma autógrafa. Artículo 18. La Firma Electrónica, debidamente certificada por un Proveedor de Servicios de Certificación conforme a lo establecido en este Decreto-Ley, se considerará que cumple con los requisitos señalados en el artículo 16. Artículo 38. El Certificado Electrónico garantiza la autoría de la Firma Electrónica que certifica así como la integridad del Mensaje de Datos. El Certificado Electrónico no confiere la autenticidad o fe pública que conforme a la ley otorguen los funcionarios públicos a los actos, documentos y certificaciones que con tal carácter suscriban.

Sección B: Ejercitación con hash y firma digital Para familiarizarse con las funciones hash, se va a utilizar en primer lugar el programa didáctico CriptoRes, elaborado en la Universidad de Politécnica de Madrid (España).

-71. Instale el programa, el cual se encuentra en la carpeta Hash\MD5-SHA del DVD. 2. Corra el programa y desde el menú principal, seleccione Criptosistemas | MD5. Introduzca una cadena de texto y vea el resultado, que es un resumen de 16 bytes.

3. Seleccione Criptosistemas | SHA-1. Introduzca la misma cadena de texto y vea el resultado, que será un resumen de 20 bytes. 4. Para cooncer más de las funciones hash, instale el programa HashCalc, el cual se encuentra en la carpeta Hash\ HashCalc del DVD. 5. Corra el programa y lea rápidamente la ayuda en línea. Luego introduzca una cadena de texto y oprima Calculate para obtener el resumen MD5 y SHA1de ese texto.

6. En Data Format seleccione File y en Data seleccione el archivo Leame.txt en la carpeta Firma Digital\HashCalc del DVD. Oprima Calculate y compruebe que el resumen SHA1 coincide con el que se encuentra en el archivo Leame-SHA1.txt en la carpeta Hash\HashCalc del DVD.

7. El programa HashCalc también permite calcular HMAC (Hashed-Message Authentication Code). HMAC es un resumen protegido con una clave. Tiene como fin evitar que un atacante altere un mensaje y además recalcule y modifique el resumen asociado a ese mensaje, para que así no se detecte el cambio.

-88. Utilizando la clave abc123, compruebe que el resumen SHA1 coincide con el que se encuentra en el archivo Leame-HMAC.txt en la carpeta Hash\HashCalc del DVD.

Si alguien altera el archivo Leame.txt, podría corregir el archivo Leame-SHA1.txt para que no detecte el cambio, pero no podría corregir el archivo encriptado Leame-HMAC.txt (ya que no conoce la clave), así que se detectaría el cambio. 9. Para familiarizarse con las firmas digitales, se va utilizar el mismo programa didáctico ExpoCrip, el cual se encuentra en la carpeta Firma Digital\ExpoCrip del DVD. Corra el programa y desde el menú principal, seleccione Firmas | Firma RSA. 10. Introduzca p = 17, q = 31, e = 7. El valor d se calcula automáticamente a partir de los números anteriores. Coloque un texto a firmar y pulse Realizar Firma. A continuación pulse Comprobar Firma y debería aparecer un mensaje que la firma es correcta.

11. Note que aquí se aplica la firma digital en su forma más báasica, es decir no se usa la función hash, sino que simplemente se cifra el mensaje con la clave privada y se descifra con la clave pública. Si usted altera el texto, dejando la firma anterior, cuando pulsa Comprobar firma, aparece un mensaje alertando que la firma es incorrecta. 12. En ExpoCript seleccione ahora Firmas | Firma DSS. La firma DSS (Digital Signature Standard) es una variante del algoritmo de ElGamal, y es el estándar federal de EE.UU. para la firma digital. La información pública está formada por la tripleta (p, q, g) siendo: p: número primo grande q: número primo divisor de p-1 g: valor entero que cumpla: α = g(p-1/q) mod p ≠ 1. 13. La clave privada es un entero aleatorio x elegido por el firmante y tal que 1 < x < q, mientras que la clave pública asociada y viene dada por: y = ax mod p. Para firmar un mensaje M tal que 1 < M < p, el firmante elige un entero aleatorio k con 1 < k < q. DSS tiene la característica de que las firmas de un mismo documento son diferentes, ya que k es aleatorio. 14. Introduzca p = 223, q = 37, g = 17, x = 20, k = 12. El valor alfa (α) se calcula automáticamente a partir de los números anteriores. Coloque un texto a firmar y pulse Realizar Firma. A continuación pulse Comprobar Firma y le debería informar que la firma es correcta. 15. Si usted altera el texto, dejando la firma anterior, al pulsar Comprobar firma aparece una alerta de que la firma es incorrecta.

-916. Cambie el valor de x de 20 a 25 y pulse Realizar Firma. Al comprobar la firma, el programa le indicará que no se puede comprobar. Investigue esta anomalía.

Sección B: Firma digital de documentos PDF PDF (Portable Document Format) es un formato de almacenamiento de documentos, desarrollado por la empresa Adobe Systems. Está especialmente ideado para documentos susceptibles de ser impresos, ya que especifica toda la información necesaria para la presentación final del documento, determinando todos los detalles de cómo va a quedar, no requiriéndose procesos ulteriores de ajuste ni de formateo. Cada vez se utiliza más también como especificación de visualización, gracias a la gran calidad de las fuentes utilizadas y a las facilidades que ofrece para el manejo del documento, como búsquedas, hiperenlaces, etc. Además puede incorporar texto, gráficos, imágenes e incluso música. PDF es multiplataforma, es decir, puede ser utilizado con los principales sistemas operativos (Windows, Unix o Mac), sin que se modifiquen ni el aspecto ni la estructura del documento original. Es uno de los formatos más extendidos en Internet para el intercambio de documentos. Por ello es muy utilizado por empresas, gobiernos e instituciones educativas. Es una especificación abierta, para la que se han generado herramientas de software libre que permiten crear, visualizar o modificar documentos en formato PDF. Un ejemplo es la suite ofimática OpenOffice.org. Puede cifrarse para proteger su contenido e incluso firmarlo digitalmente. La firma digital de un documento PDF identifica a la persona que firma el documento. Sin embargo, a diferencia de las firmas tradicionales en papel, cada firma digital almacena información acerca de la persona que firma el documento. Téngase en cuenta que la firma que se muestra es sólo su representación en la página, no es la información de firma digital real. Con la firma visible se puede incluir una imagen (por ejemplo, la firma real escaneada, la foto del firmante o el logotipo de la empresa). La imagen se recorta y se adapta su escala para que se ajuste al campo de firma.

El autor de un documento PDF puede agregar una firma para indicar su aprobación. Además, un documento PDF puede firmarse más de una vez por más de una persona. Por ejemplo, el autor puede guardar un documento PDF que contenga campos de formulario como certificado y permitir que sólo se rellenen campos de formulario. Si otra persona abre el documento PDF, un mensaje indica si la certificación sigue siendo válida. Esta persona podrá rellenar el formulario y firmar el documento al terminar.

La primera firma de un documento PDF se denomina firma de autor. Cuando se agrega la primera firma a un documento, se tiene la opción de certificarlo. La certificación de un documento permite avalar su contenido y especificar los tipos de cambios permitidos para que el documento siga estando certificado. Las firmas posteriores incluidas en el documento se denominan firmas ordinarias. Al guardar un documento PDF de Adobe como certificado, se está avalando su contenido al tiempo que especifica los tipos de cambios permitidos para que el documento siga estando certificado. Por ejemplo, suponga que un departamento gubernamental crea un formulario con campos de firma. Al completar el formulario, el departamento certifica el documento para permitir que los usuarios cambien únicamente los campos de formulario y firmen el documento. Los usuarios pueden rellenar el formulario y firmar el documento, pero si eliminan páginas o agregan comentarios, el documento no conservará su estado de certificado. La certificación de un documento ayuda a garantizar que los documentos PDF no se modifiquen sin la aprobación del autor. 1. Para familiarizarse con documentos PDF firmados, haga doble clic sobre el archivo Acta de notas.pdf que se encuentra en la carpeta Firma Digital\Muestras del DVD. Debe tener instalado una versión reciente de Acrobat Reader (por ejemplo la 7) que la puede descargar de www.adobe.com/es. Es preferible la versión en español. 2. Observe el final del documento, donde está la firma digital del profesor. El icono con el signo de interrogación indica que la firma no se ha podido verificar. Haga clic sobre el mismo y seleccione Propiedades de la firma. Explore toda la

-10información que allí aparece.

3. Para que una firma sea válida, el certificado del firmante, o uno de sus certificados principales utilizados para emitirlo, debe estar en la lista de identidades de confianza, y no debe haber caducado ni haberse revocado. Para incluir el certificado del firmante en la lista, seleccione Mostrar certificado.

4. Abra General y vea quién es la entidad emisora. Luego abra Detalles y tome nota del valor de la huella digital SHA-1 y MD5. Confirme que la información es correcta (SHA-1 = B4 A7 46 39 A3 1C F4 E7 41 D9 7A E4 FF E2 C8 57 20 91 1C AB).

6. Si la información del certificado es correcta, abra Confiar y haga clic en Agregar identidades de confianza y, finalmente, Aceptar.

6. Si ahora hace clic sobre el icono con el signo de interrogación, el mismo debería cambiar, indicando que la firma es válida. Con esta forma de validación no hace falta que el certificado del firmante ni de la entidad emisora del certificado se encuentren el almacén de certificados de Windows. Compruébelo. ¿Qué posibles implicaciones tiene esto? 7. Los datos del archivo Acta de notas.pdf han sido sutilmente alterados para subir la nota al último estudiante. Abra el archivo modificado Acta de notas2.pdf y observe el símbolo de advertencia, el cual indica que el documento fue modificado después de agregarse la firma. El autor del documento PDF también puede bloquear los campos después de firmar el documento para así impedir que se hagan cambios posteriores. 8. Para ver otro documento PDF firmado, haga doble clic sobre el archivo Constancia tests CISSP.pdf que también se encuentra en la carpeta Firma Digital\Muestras del DVD. Debería tener una firma digital válida, ya que fue firmado con la misma clave privada que Acta de notas.pdf.

-119. Avance la fecha de su computador e investigue qué pasa con la validez de la firma digital. ¿Qué implicaciones podría tener este hecho desde el punto de vista legal? Regrese después el PC a la fecha correcta. 10. La firma digital puede ser invisible o visible. Haga doble clic sobre el archivo Transferencia bancaria.pdf que se encuentra en la carpeta Firma Digital\Muestras del DVD, en el cual la firma es invisible. Pero los detalles de esa firma invisible se muestran en la ficha Firmas. En cambio, una firma visible se muestra tanto en la ficha Firmas como en el propio documento impreso.

11. El archivo Transferencia bancaria.pdf ha sido forjado para efectuar un fraude bancario y convertido en el archivo Transferencia bancaria2.pdf. Observe cómo se reportan cambios posteriores en la ficha Firmas.

Sección C: Estampado de firma digital en documentos PDF Para estampar la firma digital en documento PDF, lo ideal es utilizar Acrobat Standard o Acrobat Professional en español. Una de las razones es que los datos de la firma aparecen en español y no en inglés. Pero como el precio de estos productos es relativamente alto, se puede utilizar otra solución. Para crear documentos PDF, existe el producto gratuito PrimoPDF, cuya versión más reciente se puede descargar de http://www.PrimoPDF.com. Para firmar y cifrar documentos PDF, existe el producto PDFSealer, cuya versión más reciente se puede descargar de http://www.iteksoft.com en forma de demo. 1. Instale PrimoPDF, el cual se encuentra en la carpeta Firma Digital del DVD. 2. Como primera prueba de creación de un documento PDF, abra con Word el archivo Transferencia bancaria.doc que se encuentra en la carpeta Firma Digital\Muestras. Modifique algunos datos (fecha, beneficiario, etc.) y pulse Imprimir. Cuando le aparezca la lista de impresoras disponibles, seleccione PrimoPDF.

3. En PDF Settings seleccione Print y en Save As ponga una ruta al disco duro.

-12-

4. Haga doble clic sobre el archivo Transferencia bancaria.pdf que se acaba de crear a fin de que se abra con Acrobat Reader y vea su contenido. Cierre Acrobat Reader para que no interfiera con el siguiente paso. 5. Instale PDFSealer, el cual se encuentra en la carpeta Firma Digital del DVD. Para que no le aparezca la marca de demo en la firma digital, puede usar la clave que arroja KeyGen.exe. Nota: Esta forma de registro es sólo para fines didácticos y no para uso personal o comercial. 6. Corra PDFSealer y desde File abra el archivo PDF que creó anteriormente. Note que la interfaz que usa PDFSealer es Acrobat Reader. 7. Desde Digital Signatures seleccione Signature Appearance y proceda a configurar su firma digital.

8. En primer lugar para firmar usted requiere de un certificado digital, el cual se selecciona del cuadro correspondiente.

9. Si todavía no tiene un certificado, lo puede solicitar a entidades independientes emisoras de certificados, por ejemplo VeriSign, Thawte Consulting o British Telecom, yendo al sitio Web de esas organizaciones: https://digitalid.verisign.com/client/enroll.htm https://www.thawte.com/cgi/enroll/personal/step1.exe https://www.trustwise.com/Class1EnrolmentMS.html 10. Ud. deberá esperar un e-mail de vuelta con las instrucciones para obtener e instalar su certificado digital. 11. Otra alternativa es que usted mismo genere su certificado, utilizando MakeCert, OpenSSL o Windows Server, tal como se explica en la práctica “Certificados Digitales y PKI”. 12. Una vez en posesión del certificado, mediante Create configurando los aspectos de su firma, tal como se indica:

-1312. En la ventana de Properties, llene todo los datos. En Imported Image, puede usar una imagen con su foto y su firma manuscrita. Si no tiene ninguna disponible, busque en Internet.

13. En la ventana de Properties llene todo los datos. En Imported Image, puede usar una imagen con su foto y su firma manuscrita. Si no tiene ninguna disponible, busque en Internet. 14. Finalmente proceda a firmar el documento desde Digital Signatures | Sign Document. Seleccione Sign and SaveAs y guárdelo con otro nombre. 15. Al primer intento, la apariencia y la posición de la firma no va a ser la adecuada, por lo que deberá editar los siguientes parámetros hasta que quede satisfecho.

16. Experimente con el activar o desactivar los demás parámetros (name, thumbprint, etc.) y note el efecto sobre la firma. Si desactiva Show signature appareance, la firma será invisible. 17. A un documento PDF se le puede aplicar máxima seguridad encriptándolo e impidiendo cambios no autorizados. Para probarlo, abra con Word el archivo Transferencia bancaria.doc u otro archivo y pulse Imprimir. Cuando le aparezca la lista de impresoras disponibles, seleccione PrimoPDF y luego pulse el botón Security.

18. Configure los permisos de lectura y escritura y ponga las contraseñas correspondientes.

-14-

19. Una vez creado el archivo Transferencia bancaria.pdf, intente abrirlo mediante Acrobat Reader y se le pedirá la contraseña. Una vez abierto, vaya a Documento | Seguridad y compruebe que las restricciones están habilitadas.

20. Cierre Acrobat Reader y abra el mismo archivo mediante PDFSealer. Aplíquele su firma digital y guárdelo. Ahora ese documento posee las propiedades de: confidencialidad, autenticidad, integridad y no repudio! En caso de una disputa, ¿cree usted que lograría convencer a un juez? 21. Para completar esta sección, aplique su firma digital al documento Transferencia de fondos.pdf que se encuentra en la carpeta Firma Digital\Muestras.

-15-

Sección D: Firma digital de documentos XML XML (sigla en inglés de eXtensible Markup Language) es un lenguaje extensible de etiquetas desarrollado por el World Wide Web Consortium (W3C). La razón de XML, es que el popular HTML ha ido creciendo de una manera descontrolada, a pesar de los esfuerzos del W3C de poner orden y establecer reglas y etiquetas para su estandarización. Este ente empezó en 1998 el desarrollo de XML, que aún continúa. Este lenguaje es mucho más elaborado y pretende solucionar las carencias de HTML A primera vista, un documento XML es similar a los documentos HTML, pero realmente no es igual y hay una diferencia fundamental: un documento XML contiene metadatos (es decir datos que se autodefinen), mientras que un documento HTML contiene datos mal definidos, mezclados con elementos de formato. En XML se separa el contenido de la presentación. Al igual que HTML, XML se basa en documentos de texto en los que se utilizan etiquetas para delimitar los elementos. Sin embargo, XML define estas etiquetas en función del tipo de datos que está describiendo y no de la apariencia final que tendrán en pantalla o en la copia impresa, además de permitir definir nuevas etiquetas y ampliar las existentes. El W3C ha incorporado mecanismos de seguridad a XML mediante XML Encryption y XML Signature, que ya se usan en el comercio electrónico. XML Encryption tiene como propósito asegurar la confidencialidad de partes de documentos XML a través de la encriptación parcial del documento. XML Encryption se puede aplicar a cualquier recurso Web, incluyendo contenido que no sea XML. XML Signature asegura la integridad, autenticidad y no repudio de partes del documento XML mediante el uso de la firma digital. XML Key Management es un protocolo para distribuir y registrar claves públicas a través de la PKI (Infraestructura de Clave Pública). Está compuesto de dos partes que son: el registro de la clave pública (X-KRSS) y la información de clave pública (X-KISS). Como ilustración, a continuación se muestra un trozo de código que muestra información de un cliente y su tarjeta de crédito, con un límite de Bs. 2.000.000 para realizar su compra. Juan Marcano 1234 5678 9012 Banco XYZ 10/07

El número de la tarjeta de crédito es una información que debería ser confidencial por motivos de seguridad, por lo cual es importante que esté cifrada. La forma de realizar el encriptado de esa parte con XML Encryption sería el siguiente: Juan Marcano A23B45C56

Al cifrar el elemento completo de tarjeta de crédito, el elemento en sí mismo se oculta, por lo que no es posible saber si el cliente está usando un tarjeta de crédito o simplemente dinero en metálico. El elemento DatosClave contiene el número encriptado del elemento TarjetaCredito. También es posible firmar digitalmente todo el documento, como se ve a continuación:. XML Signature:

-16j6lwx3rvEPO0vKtMup4NbeVu8nk= MC0CFFrVLtRlk=...

...

.........

El elemento Signature encapsula la firma digital. Contiene tres sub-elementos: SignedInfo, SignatureValue y KeyInfo. El elemento SignedInfo contiene información sobre qué es lo que se firma y cómo se firma, es decir, contiene la información necesaria para crear y validar la firma. Este elemento contiene dos algoritmos. Por un lado, está el que es el algoritmo de transformación de SignedInfo antes de realizar la firma digital. Por otro lado, estaría el método de firma (), que sería el algoritmo utilizado para calcular el valor de la firma digital. También se incluye en el elemento SignedInfo las referencias a los objetos que se van a firmar () que incluye además y . La validación de una firma requiere dos procesos que son la validación de la firma y la validación de los resultados de las referencias. El elemento es el encargado de indicar el algoritmo para canonizar el elemento SignedInfo, que tendrá lugar durante la creación de la firma. El , es el encargado de indicar el algoritmo para general la firma a partir de la canonización de SignedInfo. El resultado obtenido si indicará en el elemento SignatureValue. Cada elemento , incluye una referencia al objeto que se firmará. Al mismo tiempo incluye el resultado de que es el valor resultante. El elemento , contiene el resultado de la firma digital que se ha aplicado sobre el elemento SignedInfo. El resultado de esta firma está codificado y contiene un atributo que es único con el que se identificará la firma en procesos posteriores de validación. El elemento , se trata de un elemento opcional que indica la clave que ha de utilizarse para validar la firma. El elemento , especifica la clave para validar la firma digital. Resumiendo, se tiene que el elemento SignedInfo contiene lo que se firma. Por otro lado, el elemento SignatureValue, contiene la firma, es decir, contiene el elemento SignedInfo en forma canonizada, resumida y encriptada con la clave privada del firmante. Y por último, KeyInfo, que contiene el certificado de la clave pública del firmante. En la figura siguiente se muestran detalles de los distintos componentes de la firma digital mediante XML. Para más información, consulte el documento anexo a la versión electrónica de esta guía o haga una búsqueda en Internet.

1. Para ver algunos ejemplos de documentos XML firmados, vaya a XML Security Library en http://www.aleksey.com/xmlsec/index.html y seleccione el link Online Verifier.

-17-

2. Trate de verificar la firma de algunos de los documentos de prueba. Quizás la verificación le de un error. Investigue la posible causa.

Sección H: Sellado digital de tiempo En ciertas transacciones electrónicas, la hora y fecha en que se realiza una acción (envío o recepción de mensajes, creación o eliminación de documentos, etc.) es de gran importancia, a veces aún más que la propia información en sí. Algunas de transacciones en las que el tiempo es fundamental pueden ser voto electrónico, firma electrónica de contratos, presentación de documentación a concursos públicos o solicitudes electrónicas de patentes. En muchos de estos casos, lo crucial no es sólo determinar el tiempo en que ocurrió esa acción, sino poder demostrar, a posteriori, que realmente se desarrolló en ese instante. Como ejemplo, con la firma digital se plantea el siguiente problema: Estoy seguro que el documento fue firmado por una determinada persona, pero ¿cómo puedo estar seguro, técnica y legalmente, de que fue firmado en una determinada fecha y hora? La fecha en el texto del documento o la fecha de creación del archivo no es ninguna garantía de la fecha y hora en que se firmó el documento, ya que se pueden fácilmente modificar. Un segundo problema es que el certificado digital del firmante era válido a la hora de firmar, pero luego caducó o fue revocado, (aunque esto no debería invalidar la firma). Es parecido al caso de que caduque una tarjeta de crédito, sin por eso invalidar las compras hechas antes de su vencimiento.

Supongamos el siguiente caso: Una orden de compra es firmada digitalmente por un empleado. Esta firma es verificada por el departamento de compras antes de aprobarla y tramitarla. Un año más tarde se hace una auditoría, pero el empleado ha dejado la organización y se ha revocado su certificado. El departamento el compras debe demostrar que la firma era válida hace un año. Como se puede apreciar de los problemas y casos descritos, surge la necesidad de disponer de un medio que de garantías, técnicas y jurídicas, de "sellar" la fecha y hora en un documento digital. El sellado de tiempo (o time stamping en inglés), también llamado fechado digital, es un mecanismo por medio del cual se puede asociar una transacción electrónica con una fecha y hora para así tener evidencias (técnicas y jurídicas) de tal acto que tuvo lugar en un determinado momento del tiempo. Permite demostrar que una serie de datos han existido y no han sido alterados desde un instante específico en el tiempo. La hora que aparece en el sello digital debe estar expresada en UTC (Universal Time Coordinated) a fin de no se preste a confusión según el país. UTC es la zona horaria de referencia respecto a la cual se calculan todas las otras zonas del mundo. Es el sucesor del GMT (Greenwich Mean Time), aunque todavía algunas veces se le denomina así. La nueva denominación fue acuñada para eliminar la inclusión de una localización específica en un estándar internacional.

La hora legal en Venezuela es UTC-4 y es responsabilidad del Observatorio Cagigal, perteneciente a la Dirección de Hidrografía y Navegación de la Armada (http://www.dhn.mil.ve). Una autoridad de sellado de tiempo (en inglés TSA, Time Stamping Authority) es un ente dedicado a las funciones de emisión de sellos en las condiciones necesarias de seguridad y precisión del tiempo mediante el uso de los satélites GPS (Global Positioning System) u otro mecanismo (ej. reloj atómico) como fuente horaria casi perfecta. La sincronización al reloj maestro se hace usualmente mediante NTP (Network Time Protocol) utilizando un servidor de tiempos que actúa a nivel Stratum 1, enviando paquetes IP con información sobre el valor del tiempo UTC.

-18Como ejemplo, una fuente de tiempo podría utilizar un reloj con precisión 1 microsegundo y estabilidad de 32 s/año. Este reloj se sincronizaría cada segundo con las señales de referencia procedentes de varios satélites de la constelación Navstar que constituye el alma del sistema GPS y que son visibles desde la ubicación geográfica del servidor. La configuración de la constelación Navstar asegura que en todo momento son visibles al menos cuatro satélites desde cualquier lugar del mundo que tenga una visión total del horizonte El protocolo básico utilizado para el sellado es TSP (Time Stamp Protocol), descrito en RFC 3161. En Europa existe la directiva TS 102 023 V1.2.1 de ETSI titulada: Technical specification for Electronic Signatures and Infrastructures (ESI) - Policy requirements for time-stamping authorities. Para generar un sellado de tiempo, se parte del documento digital y de él se se obtiene un resumen (hash). Sobre este resumen se genera el sellado de tiempo: Esto es, la TSA firma digitalmente el resumen, junto con la fecha y hora provenientes de la fuente confiable y otra información. El archivo que contiene el sello se le entrega al usuario.

La TSA actúa como tercera parte de confianza testificando la existencia de un determinado documento digital en una fecha y hora concretos. Igual que en la vida real, se podría pensar en falsificar el sello, para aplicarlo a otro documento. Para evitarlo, se firma digitalmente. Cualquiera puede verificar la validez de un sello emitido y firmado digitalmente de la TSA, para lo cual se requiere el certificado digital de la TSA, emitido por una autoridad de confianza (raíz). Ese certificado contiene el atributo de Impresión de fecha en el campo Uso mejorado de claves.

Los documentos (objetos) que pueden ser sellados no están sujetos a una estructura fija. Con esta libertad de formato, el servicio de sellado digital de tiempo puede emitir sellos para elementos tan dispares como: una transacción electrónica bancaria, un documento de patente o de su solicitud, obras intelectuales de todo tipo (escritos, imágenes, registros sonoros, software, etc.). Para desligar la emisión del sello de la naturaleza específica del documento u objeto al que se refiere, lo más conveniente es utilizar una función hash, con la que se obtiene una representación resumida de dicho objeto y, a partir de la cual, en ningún caso, es posible obtener el documento original o cualquier información sobre el mismo. El "resumen" o "valor hash" representa al objeto digital, a todos los efectos, de forma unívoca ya que la probabilidad de que dos documentos distintos tengan el mismo "resumen" es del orden de (1/2)^128 para una función hash de 128 bits. De esta manera, al sellar esta representación resumida del documento, lo que realmente se está haciendo es sellar el documento original. En varias partes del mundo el servicio de sellado de tiempo empieza a ser ofrecido por entes públicos y privado. En España, por ejemplo, CATCert (http://www.catcert.net) lo suministra a la administración pública de Cataluña. En España también el servicio es suministrado por la Agencia Notarial de Certificación (http://www.ancert.com). Ésta es una entidad constituida por el Consejo General del Notariado, el Instituto Notarial de Tecnologías de Información, y dedicada a la provisión de servicios a los más de 3.000 notarios en España, y a la prestación de servicios de certificación necesarios para garantizar la seguridad, validez y eficacia de la emisión y recepción de comunicaciones y documentos a través de técnicas y medios electrónicos, informáticos y telemáticos (EIT) en las relaciones que se produzcan entre personas físicas y jurídicas. A nivel comercial en España la empresa IPSCA (http://www.ipsca.com) ofrece una serie de soluciones en esta área. En el Reino Unido el servicio es ofrecido por empresas como por Ascertia (http://www.ascertia.com) y en Estados Unidos por DigiStamp (http://www.digistamp.com).

-19-

Las siguientes son algunas razones que modernamente justifican el uso del servicio de sellado de tiempo: Mejorar la confianza en el comercio electrónico La precisión en el tiempo y en los contenidos de las transacciones resulta de gran importancia para el comercio electrónico. Sin embargo, las transacciones actuales se realizan usando fuentes de tiempo de los propios computadores de compradores o vendedores, por tanto el tiempo no es confiable y puede ser fácilmente manipulado y repudiado. Asimismo, los contenidos de los pedidos, facturas, u otros documentos implicados en transacciones on-line son susceptibles de ser alterados. Estos problemas diezman la confianza de la gente en el comercio electrónico y entorpecen su desarrollo. Aplicando la firma digital y el sellado de tiempo en los documentos manejados on-line, se garantiza que las transacciones ocurrieron en un momento particular y sus contenidos no han sido alterados desde entonces. El fraude y la repudiación ya no son posibles fácilmente. Compradores y vendedores pueden operar por tanto en un entorno más seguro y tener confianza en el comercio en Internet. Proteger la propiedad intelectual Internet es un medio excelente para compartir el trabajo creativo. Desafortunadamente, cualquier trabajo publicado en Internet es susceptible de ser plagiado. Peor aún, los mecanismos para demostrar la autoría de un trabajo, en caso de disputa, son prácticamente inexistentes. El sellado de tiempo puede usarse para certificar la existencia de cualquier trabajo creativo, incluyendo texto, gráficos, audio o video, desde de un momento concreto. Emitir sellos de tiempo electrónicos impide infringir los derechos de la propiedad intelectual. Si la creación se plagia, la persona con el sello de tiempo más antiguo tendrá una prueba fehaciente para reclamar la propiedad del copyright de esa creación. Potenciar la PKI En la Infraestructura de Clave Publica (PKI) tradicional, una firma digital indica quien ha firmado un documento electrónico. No obstante, la firma puede eventualmente repudiada si el documento no incluye una fuente confiable de tiempo. Un sello de tiempo sobre la firma digital proporciona tiempo preciso de una tercera parte confiable, mostrando en qué momento se firmó el documento. De esta manera el documento posee en grado mayor la propiedad de no-repudio.

Si se recopila información sobre la validez de certificado en el momento de la firma, como por ejemplo mediante OCSP (Online Certificate Status Protocol), y se solicita un sello de tiempo a todo el conjunto, firma y elementos de verificación, se tiene una firma

-20firma digital mucho más confiable. OCSP es un método para determinar el estado de revocación de un certificado digital X.509 usando otros medios que no sean el uso de CRL (Lista de Revocación de Certificados). Este protocolo está descrito en RFC 2560 y fue creado para solventar ciertas deficiencias de las CRL. Cuando se despliega una PKI (Infraestructura de Clave Pública), es preferible la validación de los certificados mediante OCSP en vez de CRL por varias razones, pero sobre todo porque OCSP puede proporcionar una información más del estado de revocación de un certificado. ¿Dónde se aplica? • Protección de la propiedad intelectual. • Registro electrónico / libros financieros / apuestas / pedidos. • Trazas (logging) seguras. • Transacciones seguras en comercio electrónico. • Voto electrónico. • Muchas otras áreas... Entre las otras áreas posibles consideremos, por ejemplo, el caso de la evaluación continua de alumnos, en la cual se debe realizar una serie de trabajos a lo largo del periodo y que deben ser entregados antes de determinado día, pero la evaluación se realiza al final. Los alumnos pueden ir enviando al profesor un email con el resumen (hash) del archivo que contiene la tarea realizada, a fin de que el profesor le aplique el sellado de tiempo: “Juan Pérez ha completado la tarea XYZ en fecha DD/MM/AA, la cual se encuentra en el archivo Tarea1.pdf y su resumen MD5 es 29a2fa33dca39b6d9a2bc0748a335f33” Al final del periodo el alumno entrega un CD-ROM con todas las tareas y el docente, recalculando el hash, puede comprobar que las tareas parciales se entregaron a tiempo y que no fueron modificadas desde que se registraron. Como otro caso consideremos el de un congreso o evento científico internacional donde se solicita que el autor envíe su ponencia antes de determinada fecha. Al usar el sellado de tiempo, el ponente tiene una prueba de que antes de esa fecha tenía el documento escrito. Si se pierde el documento por algún problema en el servidor de correos, red, etc. o el documento es enviado con posterioridad vía correo postal, entregado en mano, etc., se puede verificar que se han cumplido los plazos. Consideremos otro caso más, el de una licitación pública tradicional, donde varias empresas presentan sus ofertas en sobre cerrado, esperando ganar la licitación. Una vez vencido el plazo, se reúnen en un acto público todas las partes involucradas para verificar el estado inalterado de los sellos y luego abrir los sobres haciendo así su contenido público. Si alguien pudiese abrir los sobres antes de que se termine el plazo de presentación de ofertas, el transgresor podría conocer información privilegiada que le permitiría ganar fraudulentamente la licitación. Si alguien pudiese sustituir o modificar una oferta previa incluyendo algo nuevo después de que haya terminado el plazo de presentaciones, también dispondría de información privilegiada que posiblemente se habría filtrado desde sus oponentes, ya que estos se encuentran confiados al creer que nada puede hacerse ya para modificar las opciones presentadas. En una licitación pública moderna no habría que entregar en modo alguno las ofertas antes de que deban ser abiertas y hechas públicas. Para poder hacerlo así, tan sólo es necesario que exista un mecanismo confiable que pruebe la existencia de cada una de las propuestas con anterioridad al final del plazo de presentación, de modo que también nadie pueda modificarlas con posterioridad y antes de hacerlas públicas resolviendo automáticamente el concurso Ese mecanismo es precisamente el sellado digital de tiempo, cuya única finalidad es probar que en un determinado instante de tiempo, todos los agentes involucrados declararon disponer o disponían de un determinado documento, es decir de su oferta para la licitación. Para experimentar con el usos del sellado de tiempo se va a utilizar el producto proXSign de la empresa SETCCE (Security Technology Competence Centre) de Lituania, ya que es bastante liviano y permite un periodo de prueba de 30 días. 1. Instale el software, el cual se encuentra en la carpeta Firma Digital\ proXSign del DVD. Si está caducado, puede intentar atrasar el reloj de su PC. 2. Desde Windows y mediante Inicio | Programas | SETCCE corra el programa y además consulte rápidamente User’s Guide. 3. En Wizard seleccione XML Timestamp y luego Timestamp one file.

-214. Seleccione un archivo para sellar y continúe.

5. Seleccione dónde guardar el sello:

6. Pulse el botón Timestamp y posiblemente le aparezca el siguiente error:

7. Si pulsa el botón Show Certificate, se le muestra el siguiente mensaje, lo cual significa que el certificado no tiene una raíz de confianza.

8. Pulse el botón Instalar certificado para activar la confianza y pulse la tacla Back para reintentar de nuevo. Está vez no debería haber problemas.

-229. Si posteriormente usted u otro quiere verificar la validez del sello de tiempo asociado a ese archivo, simplemente corra el programa y seleccione Verify timestamp.

10. Seguidamente introduzca el nombre del archivo sellado y el sello. Pulse Verify.

11. Si todo sale bien, finalmente aparece el siguiente mensaje:

12. Si desea experimentar con otro producto de sellado de tiempo, pruebe con ec-Protect de Hong-Kong (http://www.ec-protect.com). Debe tener instalado además el plugin Java Runtime Environment (JRE) que se puede descargar de http://java.sun.com.

Sección I: Informe Elabore un informe de no menos de 8 páginas donde se reportan las experiencias más relevantes, se analizan los resultados obtenidos, finalizando con conclusiones y eventuales recomendaciones. El informe debe ser individual y redactado con palabras propias; no se permite repetir el texto del material que se encuentra en esta guía, en el DVD o en otras fuentes. Debe contener un resumen de las actividades realizadas, con ejemplo de resultados. Deben analizarse y discutirse esos resultados, en particular si se presentaron problemas o aspectos inesperados. También deben incluirse las conclusiones y eventuales recomendaciones. Los informes deben enviarse regularmente al profesor a lo largo del curso, mediante el correo electrónico. Serán penalizadas las entregas retrasadas y no se aceptarán entregas muy retrasadas. Además NO se aceptarán informes entregados todos juntos los últimos días de finalización del curso.

-23-

An Introduction to XML Digital Signatures By Ed Simon, Paul Madsen, Carlisle Adams O'Reilly Media, Inc., August 2001 Introduction Current security technologies in common deployment are insufficient for securing business transactions on the Web. Most existing browser-based security mechanisms, generally adequate for low-value business-to-consumer transactions, do not provide the enhanced security or flexibility required for protecting high-value commercial transactions and the sensitive data exchanges that comprise them. For instance, Secure Sockets Layer (SSL) provides for the secure interchange of sensitive data between a browser and Web server, but once received, the data is all too frequently left unprotected on the server. In fact, SSL protects the data at a point in its travels when its confidentiality is, relatively speaking, far less likely to be attacked. If you were a hacker, which would you think is a better application of your time: sniffing IP packets in transit in order to obtain a single user's credit card number or breaking into a back-end database containing thousands of credit card numbers? This problem is aggravated in the case where a message is routed from server to server. If the data itself were encrypted, as opposed to just its transport, it would help reduce the incidents of unencrypted data left vulnerable on public servers. As important as protecting the confidentiality of business messages is ensuring their long-term authenticity (who sent them?), data integrity (have they been modified in transit?), and support for non-repudiation (can the sender deny sending them?); in other words, functionality that ubiquitous, existing Internet security technologies (e.g., SSL and username/password) do not provide alone. The globally-recognized method for satisfying these requirements for secure business transactions is to use digital certificates to enable the encryption and digital signing of the exchanged data. A brief introduction to these concepts is provided below. The term "public key infrastructure" (PKI) is used to describe the processes, policies, and standards that govern the issuance, maintenance, and revocation of the certificates, public, and private keys that the encryption and signing operations require. The very features that make XML so powerful for business transactions (e.g., semantically rich and structured data, text-based, and Web-ready nature) provide both challenges and opportunities for the application of encryption and digital signature operations to XML-encoded data. For example, in many workflow scenarios where an XML document flows stepwise between participants, and where a digital signature implies some sort of commitment or assertion, each participant may wish to sign only that portion for which they are responsible and assume a concomitant level of liability. Older standards for digital signatures provide neither syntax for capturing this sort of high-granularity signature nor mechanisms for expressing which portion a principal wishes to sign. Two new security initiatives designed to both account for and take advantage of the special nature of XML data are XML Signature and XML Encryption. Both are currently progressing through the standardization process. XML Signature is a joint effort between the World Wide Web Consortium (W3C) and Internet Engineering Task Force (IETF), and XML Encryption is solely W3C effort. This article presents a brief introduction to the XML Signature specification and the underlying cryptographic concepts. Public Key Cryptography Public key cryptography allows users of an insecure network, like the Internet, to exchange data with confidence that it will be neither modified nor inappropriately accessed. This is accomplished through a transformation of the data according to an algorithm parameterized by a pair of numbers -- the so-called public and private keys. Each participant in the exchange has such a pair of keys. They make the public key freely available to anyone wishing to communicate with them, and they keep the other key private and protected. Although the keys are mathematically related, if the cryptosystem has been designed and implemented securely, it is computationally infeasible to derive the private key from knowledge of the public key. The nature of the relation between the public and private keys is such that a cryptographic transformation encoded with one key can only be reversed with the other. This defining feature of public key encryption technology enables confidentiality because a message encrypted with the public key of a specific recipient can only be decrypted by the holder of the matching private key (i.e., the recipient, if they have properly protected access to the private key). Even if intercepted by someone else, without the appropriate private key, this third party will be unable to decrypt the message. It's crucial that confidentiality can be supported without requiring that the sender and recipient exchange any "secret" data in addition to the message itself, as is the case in symmetric cryptography. Indeed it was precisely the requirement of key exchange between sender and recipient, which quickly becomes impractical as the number of participants increases, that motivated the invention of public-key cryptography. Although confidentiality is typically the first aspect of cryptography that comes to mind, the special relationship between public and private keys also enables functionality that has no parallel in symmetric cryptography; namely, authentication (ensuring that the identity of the sender can be determined by anyone) and integrity (ensuring that any alterations of the message content can be easily spotted by anyone). These new features and, through them, support for non-repudiation (ensuring the origin or delivery of data in order to protect the sender against false denial by the recipient that the data has been received or to protect the recipient against false denial

-24by the sender that the data has been sent) provide electronic messages with a mechanism analogous to signatures in the paper world, that is, a digital signature. To create a digital signature for a message, the data to be signed is transformed by an algorithm that takes as input the private key of the sender. Because a transformation determined by the sender's private key can only be undone if the reverse transform takes as a parameter the sender's public key, a recipient of the transformed data can be confident of the origin of the data (the identity of the sender). If the data can be verified using the sender's public key, then it must have been signed using the corresponding private key (to which only the sender should have access). For signature verification to be meaningful, the verifier must have confidence that the public key does actually belong to the sender (otherwise an impostor could claim to be the sender, presenting her own public key in place of the real one). A certificate, issued by a Certification Authority, is an assertion of the validity of the binding between the certificate's subject and her public key such that other users can be confident that the public key does indeed correspond to the subject who claims it as her own. Largely due to the performance characteristics of public-key algorithms, the entire message data is typically not itself transformed directly with the private key. Instead a small unique thumbprint of the document, called a "hash" or "digest", is transformed. Because the hashing algorithm is very sensitive to any changes in the source document, the hash of the original allows a recipient to verify that the document was not altered (by comparing the hash that was sent to them with the hash they calculate from the document they received). Additionally, by transforming the hash with their private key, the sender also allows the recipient to verify that it was indeed the sender that performed the transformation (because the recipient was able to use the sender's public key to "undo" the transformation). The hash of a document, transformed with the sender's private key, thereby acts as a digital signature for that document and can be transmitted openly along with the document to the recipient. The recipient verifies the signature by taking a hash of the message and inputting it to a verification algorithm along with the signature that accompanied the message and the sender's public key. If the result is successful, the recipient can be confident of both the authenticity and integrity of the message. XML Signatures XML signatures are digital signatures designed for use in XML transactions. The standard defines a schema for capturing the result of a digital signature operation applied to arbitrary (but often XML) data. Like non-XML-aware digital signatures (e.g., PKCS), XML signatures add authentication, data integrity, and support for non-repudiation to the data that they sign. However, unlike non-XML digital signature standards, XML signature has been designed to both account for and take advantage of the Internet and XML. A fundamental feature of XML Signature is the ability to sign only specific portions of the XML tree rather than the complete document. This will be relevant when a single XML document may have a long history in which the different components are authored at different times by different parties, each signing only those elements relevant to itself. This flexibility will also be critical in situations where it is important to ensure the integrity of certain portions of an XML document, while leaving open the possibility for other portions of the document to change. Consider, for example, a signed XML form delivered to a user for completion. If the signature were over the full XML form, any change by the user to the default form values would invalidate the original signature. An XML signature can sign more than one type of resource. For example, a single XML signature might cover character-encoded data (HTML), binary-encoded data (a JPG), XML-encoded data, and a specific section of an XML file. Signature validation requires that the data object that was signed be accessible. The XML signature itself will generally indicate the location of the original signed object. This reference can: • be referenced by a URI within the XML signature; • reside within the same resource as the XML signature (the signature is a sibling); • be embedded within the XML signature (the signature is the parent); • have its XML signature embedded within itself (the signature is the child). The Components of an XML Signature

-25-

How to Create an XML Signature Here is a quick overview of how to create an XML signature; please refer to the XML Signature specification for additional information. 1. Determine which resources are to be signed. This will take the form of identifying the resources through a Uniform Resource Identifier (URI). "http://www.abccompany.com/index.html" would reference an HTML page on the Web "http://www.abccompany.com/logo.gif" would reference a GIF image on the Web "http://www.abccompany.com/xml/po.xml" would reference an XML file on the Web "http://www.abccompany.com/xml/po.xml#sender1" would reference a specific element in an XML file on the Web 2. Calculate the digest of each resource. In XML signatures, each referenced resource is specified through a element and its digest (calculated on the identified resource and not the element itself) is placed in a child element like j6lwx3rvEPO0vKtMup4NbeVu8nk= UrXLDLBIta6skoV5/A8Q38GEw44=

The element identifies the algorithm used to calculate the digest. 3. Collect the Reference elements Collect the elements (with their associated digests) within a element like SignedInfo Id="foobar"> j6lwx3rvEPO0vKtMup4NbeVu8nk= UrXLDLBIta6skoV5/A8Q38GEw44=

The element indicates the algorithm was used to canonize the element. Different data streams with the same XML information set may have different textual representations, e.g. differing as to whitespace. To help prevent inaccurate verification results, XML information sets must first be canonized before extracting their bit representation for signature processing. The element identifies the algorithm used to produce the signature value. 4. Signing Calculate the digest of the element, sign that digest and put the signature value in a element. MC0E LE=

5. Add key information If keying information is to be included, place it in a element. Here the keying information contains the X.509 certificate for the sender, which would include the public key needed for signature verification.

-26 CN=Ed Simon,O=XMLSec Inc.,ST=OTTAWA,C=CA MIID5jCCA0+gA...lVN

6. Enclose in a Signature element Place the , , and elements into a element. The element comprises the XML signature. j6lwx3rvEPO0vKtMup4NbeVu8nk= UrXLDLBIta6skoV5/A8Q38GEw44= MC0E~LE= CN=Ed Simon,O=XMLSec Inc.,ST=OTTAWA,C=CA MIID5jCCA0+gA...lVN

Verifying an XML Signature A brief description of how to verify an XML signature: Verify the signature of the element. To do so, recalculate the digest of the element (using the digest algorithm specified in the element) and use the public verification key to verify that the value of the element is correct for the digest of the element. If this step passes, recalculate the digests of the references contained within the element and compare them to the digest values expressed in each element's corresponding element. Conclusion As XML becomes a vital component of the emerging electronic business infrastructure, we need trustable, secure XML messages to form the basis of business transactions. One key to enabling secure transactions is the concept of a digital signature, ensuring the integrity and authenticity of origin for business documents. XML Signature is an evolving standard for digital signatures that both addresses the special issues and requirements that XML presents for signing operations and uses XML syntax for capturing the result, simplifying its integration into XML applications.