Laboratorio Nacional de Informatica Avanzada Centro de...

Laboratorio Nacional de Inform�atica Avanzada

Centro de Ense~nanza LANIA

Dise~no y Desarrollo de un Prototipo deNotar��a Digital

TESIS

que presenta:

Vladimir Gonz�alez Garc��a

Para obtener el grado de:

Maestro en Ciencias de la Computaci�on

Directores de tesis:

Dr. Francisco Jos�e Rodr��guez Henr��quezDra. Nareli Cruz Cort�es

Xalapa, Veracruz, M�exico Agosto 2007

2 Agradecimientos

Agradecimientos

Agradezco al Laboratorio Nacional de Inform�atica Avanzada A.C porbrindar el Posgrado en Ciencias Computacionales y a su cuerpo de docentespor ampliar mis conocimientos en el �area de las Ciencias Computacionales.

Agradezco al Consejo Nacional de Ciencia y Tecnolog��a por el apoyobrindado para la realizaci�on de este trabajo por medio de los apoyos �-nancieros brindados.

Agradezco a la secci�on de computaci�on del CINVESTAV-IPN por permi-tirme el uso de sus instalaciones durante la realizaci�on de este trabajo.

Agradezco al Dr. Francisco Jos�e Ramb�o Rodr��guez Henr��quez la oportu-nidad y el apoyo para la realizaci�on de este tema de tesis.

Agradezco a la Dra. Nareli Cruz Cort�es por su apoyo constante en larealizaci�on de este tema de tesis.

Agradezco a mis compa~neros de maestr��a que me apoyaron siempre quelos necesite, en especial a Blanca Cecilia L�opez Ram��rez que me auxilio eninnumerables ocasiones durante el desarrollo de la maestr��a.

Agradezco al personal administrativo del LANIA y del CINVESTAV quesiempre me brindo su ayuda para realizar los tr�amites necesarios durante eldesarrollo de este proyecto

Dedicatoria 3

Dedicatoria

Dedico este trabajo de tesis a mis padres y mi hermana por brindarmetodo el amor, cari~no, apoyo y comprensi�on necesario para el desarrollo yconclusi�on de este tema de tesis. En especial en los momentos m�as dif��cilesque enfrent�e y durante todos los cambios realizados en mi vida para lograreste proyecto.

4 Resumen

Resumen

El presente trabajo desarrolla e implementa un prototipo de Notar��a Digi-tal el cual nos permite certi�car documentos digitales. Para poder implemen-tar la Notar��a Digital se de�ne una arquitectura que se maneja de maneracentralizada. Se desarrollan todas las entidades que se encuentran en la ar-quitectura y todos los servicios b�asicos necesarios para su funcionamiento. Setoma un caso pr�actico para el uso de esta Notar��a Digital que es el servicio decomprobantes �scales digitales del Sistema de Administraci�on Tributaria delgobierno Mexicano. Se describen los procesos de manera detallada as�� comolas estructuras b�asicas y los formatos utilizados para una Notar��a Digital ypara el uso de comprobantes �scales digitales.

�Indice general

Agradecimientos 2

Dedicatoria 3

Resumen 4

Introducci�on 8

1. Conceptos B�asicos 131.1. Notar��a Digital . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.1.1. De�nici�on . . . . . . . . . . . . . . . . . . . . . . . . . 131.1.2. Importancia . . . . . . . . . . . . . . . . . . . . . . . . 141.1.3. Factura electr�onica . . . . . . . . . . . . . . . . . . . . 15

1.2. Criptograf��a . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.2.1. De�nici�on . . . . . . . . . . . . . . . . . . . . . . . . . 161.2.2. Servicios de seguridad . . . . . . . . . . . . . . . . . . 161.2.3. Criptograf��a sim�etrica . . . . . . . . . . . . . . . . . . 181.2.4. Criptograf��a asim�etrica . . . . . . . . . . . . . . . . . . 191.2.5. Funci�on Picadillo . . . . . . . . . . . . . . . . . . . . . 211.2.6. Firma Digital . . . . . . . . . . . . . . . . . . . . . . . 211.2.7. Certi�cado Digital . . . . . . . . . . . . . . . . . . . . 22

1.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2. Infraestructura PKI 252.1. Componentes PKI . . . . . . . . . . . . . . . . . . . . . . . . 26

2.1.1. Autoridades Certi�cadoras (ACs) . . . . . . . . . . . . 272.1.2. Autoridad de Registro (AR) . . . . . . . . . . . . . . . 282.1.3. Repositorio . . . . . . . . . . . . . . . . . . . . . . . . 29

5

6 �INDICE GENERAL

2.1.4. Emisor CRL . . . . . . . . . . . . . . . . . . . . . . . . 292.1.5. Entidades Finales . . . . . . . . . . . . . . . . . . . . . 29

2.2. Arquitecturas PKI . . . . . . . . . . . . . . . . . . . . . . . . 302.2.1. Jer�arquica . . . . . . . . . . . . . . . . . . . . . . . . . 302.2.2. Malla . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.2.3. Puente . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3. Notar��a Digital 333.1. Servidor de Estampas de Tiempo . . . . . . . . . . . . . . . . 33

3.1.1. Estampas de Tiempo . . . . . . . . . . . . . . . . . . . 343.1.2. Autoridades de Estampas de Tiempo (AET) . . . . . . 35

3.2. Protocolo de almacenamiento a largo plazo . . . . . . . . . . . 373.2.1. De�nici�on . . . . . . . . . . . . . . . . . . . . . . . . . 373.2.2. Servicios proporcionados . . . . . . . . . . . . . . . . . 38

3.3. Registro de evidencia . . . . . . . . . . . . . . . . . . . . . . . 393.3.1. Generaci�on . . . . . . . . . . . . . . . . . . . . . . . . 413.3.2. Veri�caci�on . . . . . . . . . . . . . . . . . . . . . . . . 41

3.4. Estampa de Tiempo de Almacenamiento . . . . . . . . . . . . 433.4.1. Generaci�on . . . . . . . . . . . . . . . . . . . . . . . . 433.4.2. Veri�caci�on . . . . . . . . . . . . . . . . . . . . . . . . 45

3.5. Cadenas de Estampas de Tiempo y Secuencias de Estampasde Tiempo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.5.1. Generaci�on . . . . . . . . . . . . . . . . . . . . . . . . 463.5.2. Veri�caci�on . . . . . . . . . . . . . . . . . . . . . . . . 47

3.6. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4. Comprobantes Fiscales Digitales del SAT 514.1. Descripci�on del Sistema . . . . . . . . . . . . . . . . . . . . . 52

4.1.1. Solicitud de Certi�cados Digitales (SOLCEDI) . . . . . 534.1.2. Sistema de Certi�caci�on del SAT (CERTISAT WEB) . 554.1.3. Funcionamiento pr�actico . . . . . . . . . . . . . . . . . 574.1.4. Consideraciones Generales . . . . . . . . . . . . . . . . 59

4.2. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5. Implementaci�on 615.1. Arquitectura propuesta de Notar��a Digital . . . . . . . . . . . 63

5.1.1. Notar��a Digital . . . . . . . . . . . . . . . . . . . . . . 63

�INDICE GENERAL 7

5.1.2. Autoridad Certi�cadora . . . . . . . . . . . . . . . . . 665.1.3. Autoridad de Estampas de Tiempo . . . . . . . . . . . 675.1.4. Base de Datos . . . . . . . . . . . . . . . . . . . . . . . 685.1.5. Generador de Comprobantes Fiscales Digitales (GENCFD) 68

5.2. Arquitectura de la aplicaci�on . . . . . . . . . . . . . . . . . . . 685.2.1. OPENSSL . . . . . . . . . . . . . . . . . . . . . . . . . 685.2.2. Sintaxis de Notaci�on Abstracta Uno(Abstract Syntax

Notation One ASN.1) . . . . . . . . . . . . . . . . . . . 695.2.3. XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6. Conclusiones 716.1. Contribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . 726.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . 72

A. Conversi�on de ASN.1 a hexadecimal en lenguaje C 73

B. Formato de Comprobante Fiscal Digital certi�cado 75

C. Errores en la interfaz del SAT de CFD 79C.1. Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

C.1.1. Autenticaci�on con llave privada . . . . . . . . . . . . . 79C.1.2. Falsi�caci�on de fechas . . . . . . . . . . . . . . . . . . 80C.1.3. Uso de certi�cados . . . . . . . . . . . . . . . . . . . . 80C.1.4. Algoritmos de criptograf��a . . . . . . . . . . . . . . . . 80C.1.5. Carencia de almacenamiento seguro . . . . . . . . . . . 81

C.2. Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . . 81C.2.1. Autenticaci�on del contribuyente . . . . . . . . . . . . . 81C.2.2. Generaci�on de comprobantes �scales digitales . . . . . 81C.2.3. Otros algoritmos de criptograf��a . . . . . . . . . . . . . 82C.2.4. Almacenamiento seguro . . . . . . . . . . . . . . . . . 83

8 �INDICE GENERAL

Introducci�on

En la actualidad se est�a realizando una enorme migraci�on de datos de suforma tradicional en papel hacia la forma digital, desde el manejo de alg�unformato contable hasta llevar incluso todo el sistema de la empresa en forma-to digital, guardando la informaci�on en medios electr�onicos. Esta migraci�onest�a cambiando la forma de hacer negocios y por lo tanto el gobierno tambi�entiene que actualizarse para poder manejar la nueva tecnolog��a.

En el caso de M�exico se est�a haciendo el esfuerzo para poder utilizardocumentos digitales para el pago de impuestos, espec��camente el manejode los comprobantes �scales, por lo que se ha realizado la migraci�on haciacomprobantes �scales digitales, en especial hacia la factura electr�onica, lacual es un mecanismo que permite la comprobaci�on de los ventas de unaempresa. Sin embargo, al realizar tal migraci�on surgen problemas que ya seten��an solucionados con los documentos en papel, por ejemplo la certi�caci�onde un documento realizada por un notario.

Los documentos digitales ofrecen la ventaja de poder ser intercambiadosf�acilmente y de poder tener copias de �estos sin ninguna restricci�on aunquecon estas caracter��sticas surgen problemas nuevos tales como el mantener se-guros los documentos sin que nadie pueda alterarlos y sin que la informaci�onsea comprometida, as�� como la comprobaci�on de la fecha de creaci�on de losdocumentos digitales puesto que pueden ser modi�cados f�acilmente o simple-mente reemplazados con uno nuevo que contenga la misma informaci�on.

A pesar de que los documentos pueden ser protegidos con t�ecnicas crip-togr�a�cas, ninguna permite comprobar la fecha de creaci�on de manera con-�able, por lo que es necesario utilizar un protocolo que brinde la posibilidadde comprobar la fecha de creaci�on de un documento digital, por ejemplopara situaciones como el manejo de patente o el pago de impuestos en unafecha determinada. Esta certi�caci�on debe de hacerse basada en las t�ecni-cas criptogr�a�cas que existen hoy en d��a pero teniendo en cuenta que estas

9

10 Introducci�on

t�ecnicas pueden ser quebradas y la informaci�on comprometida, por lo tantoeventualmente ser�a necesario renovar la seguridad en los documentos. Es im-portante tener en cuenta los posibles ataques a los documentos digitales y alintercambio de los datos.

El Sistema de Administraci�on Tributaria de M�exico (SAT) al usar docu-mentos digitales permite realizar el intercambio de �estos a trav�es de Internet,lo cual agiliza procesos y tiempos pero potencialmente puede comprometerlos datos, debido a todos los ataques que se pueden realizar durante el inter-cambio de los datos en un medio de comunicaci�on inherentemente inseguro.El SAT implementa la �rma digital, as�� como realiza la funci�on de autoridadcerti�cadora.

La �rma digital nos permite determinar con certeza qui�en realiz�o un de-terminado documento y que no ha sido comprometida la informaci�on �rmadapor esta identidad. Sin embargo surge el problema del manejo de las llavesque se usan para �rmar, debido a ello es necesaria la presencia de una au-toridad que asegure a qui�en pertenecen las llaves. La autoridad se encarga deadministrar a los usuarios autorizados y de manejar y almacenar las llavesp�ublicas en forma de certi�cados digitales que son formatos que nos brindanm�as informaci�on acerca de la llave p�ublica.

Bas�andonos en herramientas como la �rma digital, la infraestructura dellave p�ublica y la autoridad de estampas de tiempo se puede crear una Notar��aDigital que permite certi�car documentos digitales. Esta Notar��a Digital sebasa en un protocolo que se encuentra actualmente en fase de borrador y queest�a siendo elaborado por el grupo de trabajo LTANS [15] de la IETF1.

El prop�osito de esta tesis es crear un prototipo de Notar��a Digital, quepermita certi�car documentos digitales. El protocolo de Notar��a Digital uti-liza estampas de tiempo con informaci�on adicional principalmente un �arbolhash reducido [23]. Gracias a la informaci�on adicional se pueden actualizarlas estampas de tiempo y el algoritmo hash. Con �estas actualizaciones segarantiza la fecha de creaci�on y la integridad del documento. El protocolo es-peci�ca la forma de intercambio de los datos y el formato para la transmisi�on,no se apega a ning�un lenguaje de programaci�on en espec��co puesto que uti-liza un lenguaje est�andar (ASN.1 [11]) para la comunicaci�on. El prototipode Notar��a Digital desarrollado en esta tesis permite almacenar documentosdigitales y certi�car su fecha de creaci�on.

El objetivo de esta tesis es desarrollar un prototipo de Notar��a Digital,

1Acr�onimo por sus siglas en ingles The Internet Engineering Task Force

Introducci�on 11

a trav�es de los servicios de almacenamiento, renovaci�on, recuperaci�on y eli-minaci�on de archivos digitales certi�cados. Los objetivos particulares que sequieren lograr son:

1. Desarrollar un prototipo de una Notar��a Digital.

2. Implementar una arquitectura de Notar��a digital.

3. Utilizar un protocolo para el almacenamiento y recuperaci�on de archivosdigitales certi�cados.

4. Utilizar t�ecnicas criptogr�a�cas como �rma digital y estampas de tiem-po.

5. Generar y certi�car comprobantes �scales digitales que se basan en elest�andar del Sistema de Administraci�on Tributaria de M�exico

6. Realizar la emulaci�on de la interfaz del Sistema de Administraci�on Tri-butaria de M�exico e incluir la certi�caci�on de los documentos digitales.

El resto de este documento de tesis est�a organizado como sigue: En elcap��tulo 1 de Conceptos B�asicos, se manejan las t�ecnicas b�asicas de Crip-tograf��a que nos van a permitir certi�car un documento. En el cap��tulo 2 dela Infraestructura de PKI, se hace una breve descripci�on de la infraestruc-tura de llave p�ublica necesaria para garantizar las llaves usadas para �rmardocumentos. En el cap��tulo 3 de Notar��a Digital, se describen las t�ecnicascriptogr�a�cas y las herramientas necesarias para poder realizar una Notar��aDigital. En el cap��tulo 4 de Comprobantes Fiscales Digitales del SAT, sedescribe el sistema que utiliza el SAT para la administraci�on de las facturaselectr�onicas las cuales utilizamos como caso pr�actico para certi�car documen-tos digitales. En el cap��tulo 5 de Implementaci�on, se describe el prototipo deNotar��a Digital el cual permite probar los protocolos descritos. en el cap��tulo6 de Conclusiones, se describen las conclusiones obtenidas del trabajo de tesisas�� como posibles mejoras.

12 Introducci�on

Cap��tulo 1

Conceptos B�asicos

En este cap��tulo se muestran los conceptos b�asicos en los cuales se basaeste trabajo de tesis. Se describen los conceptos de Notar��a Digital y deCriptograf��a que son necesarios para comprender c�apitulos posteriores.

1.1. Notar��a Digital

Con la creciente oferta y demanda de servicios digitales surge la necesidadde certi�car los documentos electr�onicos. Una de las diferencias principalesentre un documento en papel y uno electr�onico radica en que el documentoen papel tiene dependencia del medio, es decir que el primero permite alma-cenar el documento de manera f��sica, mientras que, el segundo no garantizauna prueba f��sica de su legalidad. Una de las principales desventajas de al-macenar un documento en forma digital es que no garantiza la integridadde la informaci�on durante su tiempo de vida, por ejemplo es posible alterarf�acilmente la fecha de creaci�on de un documento.

1.1.1. De�nici�on

La funci�on notarial se extiende a todas las actividades jur��dicas no con-tenciosas, con�ere al usuario seguridad jur��dica, evita posibles litigios y con- ictos, que puede resolver por medio del ejercicio de la mediaci�on jur��dica yes un instrumento indispensable para la administraci�on de una buena justicia[3].

Debido a la necesidad de veri�car la validez de un documento y prevenir

13

14 CAP�ITULO 1. CONCEPTOS B�ASICOS

litigios, �este debe ser certi�cado por una autoridad que da fe p�ublica, porejemplo un notario. La autoridad debe adjuntar informaci�on que asegure laveracidad del documento tal como autor��a, �rmas, hora y fecha. Despu�es deincorporar la informaci�on el notario almacena el documento como pruebapara demostrar su legalidad.

Con el constante desarrollo de uso de medios electr�onicos por parte delas empresas, y consecuentemente de documentos digitales, resulta esencialdesarrollar un m�etodo de certi�caci�on seguro. Adem�as, es necesario propor-cionar un m�etodo irrefutable para veri�car que un documento ha sido creadoen un momento determinado y que no ser�a alterado posteriormente. El Ser-vicio de Notar��a Digital utiliza un sistema criptogr�a�camente seguro para lacerti�caci�on de documentos y es aplicable a cualquier tipo de archivo elec-tr�onico. El sistema de certi�caci�on documental opera de forma independientea la seguridad del sistema, garantizando en primer lugar, que el documentoha sido creado en un d��a y hora espec��co; en segundo, que el documento noha sido alterado desde esa fecha; y, por �ultimo, que no puede ser confundidocon ning�un otro documento.

1.1.2. Importancia

Al certi�car documentos electr�onicos se evita el plagio de la informaci�ony se garantiza que el documento no ha sido modi�cado.

Existen muchos escenarios en los cuales los usuarios deben de probar laexistencia de datos en un punto espec��co del tiempo y demostrar la integri-dad de los datos desde �este, a�un cuando la duraci�on del tiempo de existenciaal de demostraci�on sea largo. Adicionalmente, los usuarios deben ser capacesde veri�car �rmas realizadas en datos �rmados electr�onicamente muchos a~nosdespu�es de su creaci�on [36]. Una meta de la Notar��a Digital es probar quelos datos son verdaderos. La Notar��a Digital puede ser utilizada para muchasaplicaciones pr�acticas como: testamentos, registros de propiedad, datos m�edi-cos, archivos de casos criminales, archivos personales y contratos. La Notar��aDigital puede ser utilizada por cualquier entidad (por ejemplo organizaciones,ciudadanos y notarios).

La durabilidad de los datos digitales es indeterminada debido al incesanteprogreso de la tecnolog��a. La Notar��a Digital debe solucionar aspectos comotiempo de vida del almacenamiento, prevenci�on contra desastres, prevenci�oncontra los avances en el criptoan�alisis o capacidades computacionales, cam-bios en la tecnolog��a de software y problemas legales. Dentro de esta tesis se

1.1. NOTAR�IA DIGITAL 15

toma en cuenta la prevenci�on contra los avances en el criptoan�alisis, los otrospuntos se encuentran fuera del alcance de este trabajo.

La Notar��a Digital persigue la meta de certi�car los datos sobre un periodolargo a trav�es de un r�egimen de mecanismos t�ecnicos dise~nados para soportarla solicitud de prueba de veracidad de los datos. Por ejemplo, peri�odicamentese deben desarrollar actividades que permitan preservar la integridad de losdatos y el no repudio de la existencia de los datos en un punto en el tiempo.

Una Notar��a Digital debe de ser un servicio independiente, por ejemplopuede ser localizada en una red empresarial o puede ser implementada co-mo un servicio externo accesible v��a Internet. Puede usar funcionalidades deotros servicios como por ejemplo solicitar estampas de tiempo a un servicioindependiente [36].

A continuaci�on se muestran ejemplos del uso de la Notar��a Di-gital como un servicio independiente:

Una compa~n��a certi�ca contratos usando un servicio de terceras partes.

Un hospital certi�ca datos m�edicos usando un servicio interno.

Un individuo quiere generar evidencia de posesi�on de datos en un pun-to espec��co en el tiempo, por ejemplo para prop�ositos de propiedadintelectual o �rma de un contrato.

Una o�cina de justicia quiere almacenar los archivos criminales tal quela integridad de los datos pueda ser demostrada despu�es de muchosa~nos.

Una compa~n��a solicita probar la veracidad de un contrato en el caso deuna disputa

Una o�cina de justicia prepara la informaci�on para un caso criminal.

1.1.3. Factura electr�onica

La factura electr�onica es un tipo de comprobante �scal digital, donde ca-da factura que se emita cuenta con un sello digital que la identi�ca como�unica. Este tipo de documento �scal agiliza la comprobaci�on de la informa-ci�on contable, reduce costos y errores en el proceso de generaci�on, capturay almacenamiento. Los comprobantes �scales digitales utilizan la tecnolog��a


de �rma electr�onica. En el caso del Sistema de Administraci�on Tributaria(SAT) de M�exico se utiliza la �rma electr�onica avanzada.

1.2. Criptograf��a


Los inicios de la criptograf��a se remontan a miles de a~nos atr�as pero parala d�ecada de los a~nos 60 la proliferaci�on de computadoras y de sistemas decomunicaci�on fomentaron la investigaci�on enfocada a la seguridad y comoconsecuencia a la criptograf��a. La criptograf��a (del griego kryptos, \ocul-tar", y grafos, \escribir", literalmente \escritura oculta") es el arte o cienciade cifrar y descifrar informaci�on utilizando t�ecnicas matem�aticas que haganposible el intercambio de mensajes de manera que s�olo puedan ser le��dos porlas personas a quienes van dirigidos. Una forma muy simple pero insu�cientede de�nir criptograf��a es como la ciencia de ocultar mensajes de forma segura[28].

1.2.2. Servicios de seguridad

En los sistemas de comunicaci�on existen amenazas tales como, interrup-ci�on, intercepci�on, generaci�on o modi�caci�on de la informaci�on que se trans-mite. Para contrarrestar tales amenazas se de�nen una serie de serviciospara proteger la informaci�on y minimizar cualquier ataque. Los servicios deseguridad son:

1. Con�dencialidad. La con�dencialidad asegura que la informaci�on sen-sible s�olo puede ser consultada o manipulada por usuarios, entidades oprocesos autorizados.

2. Autenticaci�on. La autenticaci�on asegura que la identidad de los partici-pantes es verdadera. La autenticaci�on se logra veri�cando dichas identi-dades usando mecanismos como contrase~nas, �rmas digitales, certi�ca-dos digitales o caracter��sticas biom�etricas. El no contar con este serviciocompromete a los servicios antes mencionados dado que cualquier enti-dad o usuario no autorizado puede realizar alg�un ataque a la seguridad.En el caso de los usuarios se pueden evaluar tres aspectos para auten-ticarlos, el primer aspecto es veri�car algo que el usuario tiene, por

1.2. CRIPTOGRAF�IA 17

ejemplo una llave privada con la cual puede emitir �rmas digitales; elsegundo aspecto es poner a prueba al usuario sobre algo que sabe, estoes, pedirle una contrase~na y, �nalmente, el tercer aspecto es veri�caralgo que el usuario es, por ejemplo, analizar sus huellas dactilares o suretina.

3. Integridad. La integridad da la certeza de que la informaci�on no ha sidomodi�cada por entidades no autorizadas para hacerlo.

4. No repudio. El no repudio ofrece protecci�on a un usuario o entidadfrente otro usuario que niegue posteriormente que en realidad se reali-z�o cierta transacci�on. Esta protecci�on se efect�ua por medio de una colec-ci�on de evidencias irrefutables que permitir�an la resoluci�on de cualquierdisputa.

Con m�as precisi�on, cuando se habla de esta �area de conocimiento comociencia se deber��a hablar de criptolog��a, que engloba las t�ecnicas de cifrado,la criptograf��a propiamente dicha y algunas t�ecnicas complementarias como:el criptoan�alisis, que estudia los m�etodos que se utilizan para romper textoscifrados con objeto de recuperar la informaci�on original en ausencia de laclave.

La �nalidad de la criptograf��a es, primero, garantizar el secreto en la co-municaci�on entre dos entidades (personas, organizaciones, etc.) y, segundo,asegurar que la informaci�on que se env��a es aut�entica en un doble sentido:que el remitente sea realmente quien dice ser y que el contenido del mensajeenviado, no haya sido modi�cado en su tr�ansito.

De�nici�on Un mensaje M se transforma en un criptograma C medianteun algoritmo de cifrado E utilizando una llave digital k

Los mensajes cifrados C = E(M;k) se transforman en el mensaje originalcon un algoritmo de descifrado M = D(C; k).

Un criptosistema en general se re�ere a un conjunto de primitivas crip-togr�a�cas usada para proveer informaci�on en los servicios de seguridad. Usa-das frecuentemente con primitivas que proveen con�dencialidad.

Un criptosistema es la qu��ntupla (P;C;K; �; �) donde:P es el conjunto �nito de los posibles textos en claro;C es el conjunto �nito de los posibles textos cifrados;K es el espacio de llaves, es decir, el conjunto �nito de todas las posibles


llaves;� es el conjunto de transformaciones de cifrado o familia de funciones quese aplica a cada elemento de P para obtener un elemento de C. Existe unatransformaci�on diferente Ek para cada valor posible de la clave k;� es el conjunto de transformaciones de descifrado, an�alogo a E.8� 2 K 9EK 2 �(regla de cifrado), 9DK 2 �(regla de descifrado)Cada EK : P ! C yDK : C ! P son funciones tales que 8m 2 P;DK(EK(m)) = mExisten dos categor��as en los que se pueden clasi�car los m�etodos de cifra-do/descifrado y, por consiguiente, a la criptogra�a. Tales esquemas son:cifradores sim�etricos o criptograf��a de llave secreta y cifradores asim�etricos ocriptograf��a de llave p�ublica, los cuales ser�an explicados a continuaci�on.

1.2.3. Criptograf��a sim�etrica

Es un m�etodo que usa una misma llave para cifrar y descifrar mensajes.Las dos partes que se comunican han de ponerse de acuerdo de antemano so-bre la llave a usar. Una vez que ambas tienen acceso a esta llave, el remitentecifra un mensaje us�andola, lo env��a al destinatario, y �este lo descifra con lamisma llave. Este proceso se muestra en la �gura 1.1

De�nici�on Consideremos un esquema de cifrado que consiste en dos con-juntos de transformaciones de cifrado y descifrado. fEe : e 2 Kg y fDd : d 2 Kgrespectivamente, donde K es el espacio de llave. Se dice que el esquema decifrado es de llave sim�etrica si para cada par de llaves (e; d) de asociaci�onde cifrado/descifrado, es computacionalmente \f�acil"determinar d conocien-do s�olo e y determinar e desde d. Dado que e = d, en la mayor��a de losesquemas pr�acticos de cifrado, el t�ermino llave sim�etrica se vuelve apropiado[28].

Ejemplo (cifrado de llave sim�etrica) Sea A = fA;B;C; :::; X; Y; Zg elalfabeto a utilizar. Sea M y C el conjunto de todas las cadenas de longitudcinco sobre A de mensajes en claro y cifrados. La llave e es elegida para hacerla permutaci�on en A. Para cifrar, un mensaje es dividido en grupos de cincoletras y una permutaci�on e es aplicada para cada letra. Para descifrar, lapermutaci�on inversa d = n� e donde n es la longitud del alfabeto utilizadoes aplicada a cada letra del texto cifrado. Por ejemplo, supongamos que lallave e es elegida para hacer la permutaci�on que convierte cada letra en laque est�a tres posiciones a la derecha como se muestra a continuaci�on.


Figura 1.1: Esquema general de la criptograf��a sim�etrica

e =

�A B C D E F G H I J K L M N O P Q R S T U V W X Y ZD E F G H I J K L M N O P Q R S T U V W X Y Z A B C

�:

Entonces, el mensaje:

m = ESTEC IFRAD ORPUE DENOS ERSEG URO

es cifrado como:

c = Ee(m) = HVWHF LIUDG RUSXH GHQRV HUV HJ XUR

1.2.4. Criptograf��a asim�etrica

En 1976 Di�e y Hellman publicaron el art��culo New Directions in Criptog-raphy [10] en donde se introduce el concepto de criptograf��a de llave p�ublica.Este es un m�etodo que usa un par de llaves para el env��o de mensajes. Lasdos llaves pertenecen a la persona que ha enviado el mensaje. Una llave esp�ublica y se puede entregar a cualquier persona. La otra llave es privada y elpropietario debe guardarla de modo que nadie tenga acceso a ella. El remi-tente usa la llave p�ublica del destinatario para cifrar el mensaje, y una vez


Figura 1.2: Esquema general de la criptograf��a asim�etrica

cifrado, s�olo la llave privada del destinatario puede descifrar este mensaje.V�ease �gura 1.2

De�nici�on Sea fEe : e 2 Kg un conjunto de transformaciones de cifra-do, y fDd : d 2 Kg el conjunto de las correspondientes transformaciones dedescifrado, donde K es el espacio de llave. Consideremos cualquier par detransformaciones asociadas de cifrado/descifrado (Ee; Dd) y suponga que ca-da par tiene la propiedad de conocer Ee, dado cualquier texto cifrado c 2 C,es computacionalmente inalcanzable encontrar el mensaje m 2 M tal queEe(m) = c. Esta propiedad implica que dado e, es inalcanzable determinar lacorrespondiente llave de descifra d. (Claro que e y d signi�can las funcionesde cifra y descifra respectivamente) [28].

Ejemplo Bajo estas de�niciones, consideremos una comunicaci�on entredos partes, Alicia y Beto. Beto selecciona el par de llaves (e; d). Beto env��a lallave de cifrado e(llamada llave p�ublica) a Alicia sobre cualquier canal, peromantiene la llave de descifrado d (llamada llave privada) segura y secreta.Alicia puede enviar un mensaje m a Beto aplicando el cifrado determinadopor la llave p�ublica de Beto para obtener c = Ee(m). Beto descifra el textocifrado c aplicando la transformaci�on inversa Dd �unicamente determinadapor d.


1.2.5. Funci�on Picadillo

Una de las primitivas fundamentales en la criptograf��a moderna son lasfunciones picadillo o funciones hash com�unmente llamadas funciones picadillode s�olo ida. Un algoritmo de hash es una funci�on matem�atica que toma unacadena de longitud variable y la convierte a una cadena de longitud �ja.Es una manera de obtener una \huella digital" o \digesto"de los datos. Eldigesto es la representaci�on del texto en forma de una cadena de d��gitos,creado con una f�ormula de hash de una s�ola direcci�on.

De�nici�on Para una funci�on picadillo con una salida de n-bits (por ejem-plo n=128), la probabilidad que una cadena aleatoria se transforme en undigesto de n-bits en particular es de 2�n. Una funci�on hash es elegida talque sea computacionalmente inalcanzable encontrar 2 entradas distintas quetengan el mismo digesto (por ejemplo, se produce una colisi�on si 2 entradasx y y tienen el mismo valor h(x) = h(y) ), y dado un valor hash y, es com-putacionalmente inalcanzable encontrar una entrada x tal que h(x) = y [28].

1.2.6. Firma Digital

Debido a la necesidad de evitar la alteraci�on de datos electr�onicos, sur-gen m�etodos como las �rmas digitales, que permite que documentos digitalesadquieran la misma validez legal que alcanzar��an si hubiesen sido realizadassobre papel y con �rma aut�ografa. Los documentos electr�onicos �rmados digi-talmente poseen tres propiedades b�asicas: integridad, identidad y no repudio.La autenticaci�on es el mecanismo por el cual una entidad A se asegura deveri�car que la identidad de una entidad B sea aquella que dice ser y vice-versa. Si este servicio no se cumple, cabe la posibilidad de que una entidaddesconocida asuma una identidad que no le corresponde y con ello se com-prometa la privacidad y la integridad de la informaci�on que se intercambia.Un esquema usado para proveer los servicios de autenticaci�on y no repudio esel de �rma digital. El prop�osito de una �rma digital es proveer a una entidadun medio para enlazar su identidad a una pieza de informaci�on.

La �rma digital es un procedimiento que se basa en t�ecnicas criptogr�a�cas,combinando dos m�etodos distintos:

Funciones picadillo.

Criptograf��a asim�etrica.


La funci�on picadillo permite que el env��o sea m�as r�apido aun cuando losdatos sean de gran tama~no. Esta funci�on crea un resumen de longitud �jade los datos de longitud variable. El proceso de �rma se hace con base enla utilizaci�on de un cifrador asim�etrico, se utiliza la llave privada para cifrarel digesto y se usa la llave p�ublica para descifrar el digesto. Los pasos paracrear una �rma digital son los siguientes:

1. El mensaje se hace pasar por una funci�on picadillo para obtener suhuella digital o digesto.

2. La huella digital se cifra utilizando la llave privada de la entidad A.

3. La �rma digital se concatena con el mensaje original y es enviado a laentidad B.

4. La entidad B hace pasar el mensaje original por la misma funci�on hashque haya utilizado la entidad A.

5. B toma la �rma digital y la descifra utilizando la llave p�ublica de laentidad A.

6. Las dos huellas digitales se comparan y si son id�enticas es que la �rmaes v�alida (se ha autenticado a la entidad A) y el mensaje est�a ��ntegro(el mensaje original no sufri�o ninguna alteraci�on en la transmisi�on).

Este proceso se ilustra en la �gura 1.3

1.2.7. Certi�cado Digital

Un Certi�cado Digital es un documento digital mediante el cual un tercerocon�able (una autoridad certi�cadora) garantiza la relaci�on entre una entidady su clave p�ublica. Si bien existen varios formatos de certi�cado digital, losm�as com�unmente empleados se rigen por el est�andar UIT-T X.509v3. Uncerti�cado digital incluye la llave p�ublica, informaci�on acerca de la identidaddel suscriptor que posee la llave privada, un periodo de validez del certi�cadoy la �rma digital de la autoridad certi�cadora. La �gura 1.4 muestra laestructura de un certi�cado digital X.509v3.


Figura 1.3: Funcionamiento de la �rma digital

Figura 1.4: Estructura del certi�cado digital X.509v3.


1.3. Conclusiones

La Notar��a Digital esta basada en diferentes conceptos, que juntos nospermiten comprender el funcionamiento de esta. Es importante tener presentecada una de las herramientas que vamos a utilizar para la implementaci�onde una Notar��a Digital puesto que si alguna de estas no le damos la debidaatenci�on pueden debilitar la seguridad del sistema y comprometerlo en sutotalidad. Los conceptos como Firma Digital y Certi�cado Digital son m�ascomplejos porque est�an formados por varios m�odulos.

Cap��tulo 2

Infraestructura PKI

En este cap��tulo se describe la infraestructura de llave p�ublica la cualnos permite el intercambio de llaves de una manera segura. Se describe sufuncionamiento de una manera muy general y se mencionan algunas de lasarquitecturas que se pueden utilizar para su implementaci�on. Para lograr quelos algoritmos de cifrado sean seguros hay que tomar en cuenta un punto muyimportante, esto es, el intercambio de llaves. Si no se tiene la seguridad en elintercambio de llaves no importa que todo lo dem�as sea seguro; el sistema esvulnerable y puede ser comprometido.

Para que la criptograf��a de llave p�ublica sea un criptosistema seguro esnecesario crear una infraestructura que trate de prevenir las vulnerabilidadesque presenta. Esta infraestructura tiene una implementaci�on conocida comoPublic Key Infraestructure [4] (Infraestructura de Llave P�ublica). Actual-mente el uso de la infraestructura de llave p�ublica es uno de los aspectosm�as importantes en las aplicaciones criptogr�a�cas, especialmente en la inter-conexi�on de la Internet.

Los algoritmos asim�etricos por s�� solos son vulnerables a diversos proble-mas que han sido divididos en 4 �areas [27]:

Autenticidad de llave. El objetivo primario de la autenti�caci�on dela llave p�ublica de una entidad es, fundamentalmente, evitar ataquescomo intruso de en medio y usurpaci�on de identidad.

Revocaci�on de llaves. Cuando se compromete la llave privada esnecesario que todos conozcan que esa llave va a ser reemplazada porotra (esta acci�on es llamada revocaci�on de llaves), por lo que es nece-

25

26 CAP�ITULO 2. INFRAESTRUCTURA PKI

sario de�nir un mecanismo que nos permita saber si una llave ha sidorevocada.

No-repudio. Uno de los prop�ositos de la �rma digital es asegurar elno-repudio. Si A mantiene su llave privada en secreto, signi�ca quenadie m�as puede generar una �rma digital de un documento m�as queA mismo. Sin embargo, A puede no aceptar su �rma digital a�rmandosimplemente que la llave con la cual se gener�o la �rma no es la suya.El problema es que no hay forma de probar que la llave particular quegener�o la �rma digital pertenece realmente a A.

Aplicaci�on de pol��ticas de seguridad. Supongamos que una com-pa~n��a quiere utilizar las ventajas de la Criptograf��a de llave p�ublica.Quiere asignar un par de llaves a cada empleado, de manera tal quecada empleado puede cifrar y �rmar informaci�on. Los requerimientosnecesarios son los siguientes:

1. Cada empleado debe de tener �unicamente un par de llaves.

2. Todas las llaves p�ublicas deben de estar registradas de maneracentralizada.

3. Las llaves utilizadas deben de usar un tama~no de longitud de llaveadecuada.

4. Cada par de llaves debe ser cambiado despu�es de un determinadoper��odo de validez.

5. Si un empleado deja de laborar en la compa~n��a, su respectiva llavep�ublica/privada debe de ser revocada autom�aticamente.

El problema para implementar las pol��ticas anteriormente descritas esque solamente pueden ser cumplidas con ayuda de sistemas externosconocidos como infraestructura de llave p�ublica (PKI por sus siglas eningles).

2.1. Componentes PKI

La Infraestructura de Llave P�ublica (PKI) es una combinaci�on de soft-ware, tecnolog��as de cifrado, y servicios que permiten proteger la seguridadde las transacciones de informaci�on en un sistema distribuido. PKI integra

2.1. COMPONENTES PKI 27

certi�cados digitales, criptograf��a de llave p�ublica y autoridades de certi�-caci�on en una arquitectura de seguridad [32]. A continuaci�on se listan loscomponentes fundamentales [19] que conforman la infraestructura PKI:

Entidad �nal. Es el t�ermino gen�erico para denotar a los usuarios�nales o cualquier entidad que pueda ser identi�cada (personas, servi-dores, compa~n��as, etc.) mediante un certi�cado digital expedido poruna Autoridad Certi�cadora.

Autoridad Certi�cadora (AC). La AC es la entidad que expide loscerti�cados digitales, as�� como tambi�en la lista de revocaci�on (por sussiglas en ingles CRL 1). Adicionalmente puede soportar funciones ad-ministrativas, aunque generalmente �estas son delegadas a una o variasAutoridades de Registro.

Autoridad de Registro (AR). Una AR es componente opcional quepuede asumir funciones administrativas de la AC. Las funciones de laAR est�an frecuentemente asociadas con la a�liaci�on de las entidades�nales, pero adicionalmente puede asistir en otras �areas.

Repositorio. El repositorio es el t�ermino gen�erico utilizado para de-notar cualquier m�etodo para almacenamiento de certi�cados y listasde revocaci�on (CRLs) que permita el acceso por parte de las entidades�nales a dichos documentos.

Emisor CRL. El emisor CRL es un componente opcional el cual puedeser utilizado por una AC para delegar las tareas de publicaci�on de laslistas de revocaci�on.

2.1.1. Autoridades Certi�cadoras (ACs)

Una Autoridad Certi�cadora es el componente fundamental de la in-fraestructura de llave p�ublica. Es una combinaci�on de hardware, software,y personas que conforman una arquitectura de seguridad. La AC es conocidapor sus dos atributos m�as importantes: su llave p�ublica e identi�cador.

La AC expide certi�cados de llave p�ublica para cada entidad, con�rman-do plenamente la identidad del suscriptor con sus respectivos documentos deidentidad. Un certi�cado digital incluye la llave p�ublica, informaci�on acerca

1Es una lista de certi�cados revocados que han sido emitidos por la AC


de la identidad del suscriptor que posee la llave privada, un per��odo de validezdel certi�cado, y la �rma digital de la propia autoridad certi�cadora. El certi-�cado puede contener otros campos como por ejemplo: informaci�on adicionalsobre la autoridad certi�cadora o informaci�on acerca de usos recomendadospara la llave p�ublica. Un suscriptor es un individuo o entidad de negocio queha contratado a una AC para recibir un certi�cado digital el cual le permitaveri�car su identidad para transacciones �rmadas digitalmente.

Una AC tambi�en debe de expedir y procesar listas de revocaci�on de certi-�cados (CRLs), las cuales son listas de los certi�cados que han sido invalida-dos. Los certi�cados pueden ser revocados por distintas razones, por ejemplo,si un propietario ha perdido su llave privada; la compa~n��a que posee el cer-ti�cado cambia de nombre; o simplemente el propietario de la llave privadaabandona la empresa para la cual trabaja. Las CRLs tambi�en deben de do-cumentar el estado de revocaci�on de los certi�cados; al igual que el periodode validez de un certi�cado digital, la lista de revocaci�on debe de especi�carla fecha exacta en la cual el certi�cado fue revocado.

Una Autoridad Certi�cadora desempe~na cuatro funciones b�asicas en PKI:

Expedici�on de certi�cados digitales.

Expedici�on de listas de revocaci�on.

Publicaci�on de sus certi�cados digitales y su lista de revocaci�on.

Almacenamiento del estado de los certi�cados expirados que ha expe-dido.

La AC inserta su nombre en cada certi�cado y CRL que genera, y los �rmacon su llave privada. Una vez que los usuarios establecen que conf��an en la AC(directamente, o a trav�es de una ruta de certi�caci�on) ellos pueden con�aren los certi�cados expedidos por dicha AC. Los usuarios pueden identi�carf�acilmente los certi�cados expedidos por la AC simplemente por la compara-ci�on del nombre. Para asegurar que el certi�cado es genuino, ellos puedenveri�car la �rma utilizando la llave p�ublica de la AC.

2.1.2. Autoridad de Registro (AR)

Una AR se dise~na para veri�car el contenido de un certi�cado para laAC. El contenido del certi�cado puede re ejar informaci�on presentada por laentidad solicitante del certi�cado as�� como informaci�on de una tercera parte.

2.1. COMPONENTES PKI 29

La AR conjunta estos datos de entrada y proporciona la informaci�on de unaforma digerida a la AC.

Cada AC mantiene una lista de las ARs acreditadas; es decir, las ARsque son con�ables. Una AR es conocida por la AC por su nombre y llavep�ublica. Mediante la veri�caci�on de la �rma digital de la AR una AC puedeestar segura que la AR es una entidad acreditada. Al igual que una AC, laAR debe de tener un cuidado extremo en la protecci�on de su llave privada.

2.1.3. Repositorio

Es el met�odo para almacenamiento y recuperaci�on de informaci�on referen-te a PKI tal como los certi�cados de llave p�ublica y las CRLs. Un repositoriopuede estar basado en la especi�caci�on X.500 con acceso para clientes a trav�esdel protocolo protocolo ligero para acceder al servicio de directorio (LDAPpor sus siglas en ingl�es) o incluso puede estar basado en algo mucho m�as sen-cillo como la descarga de un archivo plano de un servidor remoto v��a FTP oHTTP.

El grupo de trabajo IETF PKIX [17] se ha dedicado al desarrollo deprotocolos operacionales para facilitar la distribuci�on de certi�cados de llavep�ublica y CRLs, incluyendo LDAP, HTTP y FTP.

Tambi�en es posible delegar ciertas funciones de los sistemas del cliente aterceras partes con�ables. Por ejemplo, el protocolo OCSP Online Certi�cateStatus Protocol [24], puede ser usado para preguntar a una tercera parteacerca del estado de revocaci�on de los certi�cados.

2.1.4. Emisor CRL

Es el encargado de emitir la lista de revocaci�on. Generalmente la ACque expide los certi�cados es la responsable de expedir la lista de revocaci�onasociada con esos certi�cados. Sin embargo, es posible para una AC delegaresa funcionalidad a otra entidad.

2.1.5. Entidades Finales

Las entidades �nales PKI son organizaciones o individuos que usan PKI,pero no emiten certi�cados. Los entidades dependen de otros componentesPKI para obtener certi�cados y para veri�car certi�cados de otras entidades.


Las entidades �nales se encuentran ligadas a los certi�cados y �estas debende inscribirse a la infraestructura de llave p�ublica antes que puedan participarcomo miembros PKI.

2.2. Arquitecturas PKI

Las entidades �nales de PKI pueden obtener certi�cados de diferentesACs, dependiendo de la organizaci�on o comunidad en la cual ellos son miem-bros. Una PKI est�a generalmente compuesta de muchas ACs vinculadas porrutas de con�anza. Una ruta de con�anza conecta a un componente con�ablecon una o m�as terceras partes con�ables, de tal forma que todas las partespuedan tener con�anza en la validez de un certi�cado. Es importante resaltarque los usuarios �nales conf��an en sus respectivas ACs que a su vez conf��anen otras ACs, de aqu�� el t�ermino de ruta de con�anza.

Lo que se busca es utilizar la infraestructura de llave p�ublica de tal formaque pueda ser utilizada a trav�es de empresas o agencias gubernamentales.Existen dos arquitecturas PKI tradicionales las cuales permiten alcanzar estameta, las arquitecturas jer�arquica y de malla. Con la necesidad de interactuarcon diversas entidades, varias empresas est�an buscando vincular sus propiasPKIs con las de sus socios de negocio. Un tercer m�etodo es la arquitecturade puente que est�a siendo desarrollado para atacar este problema.

2.2.1. Jer�arquica

Las Autoridades son organizadas jer�arquicamente bajo una AC ra��z queexpide certi�cados a las ACs subordinadas. Esta arquitectura tiene forma de�arbol en donde se debe tener con�anza en todas las hojas, destacando quese centra la con�anza en la ra��z por ser el primer emisor. Estas ACs puedenexpedir certi�cados a las ACs y/o usuarios de nivel inferior a su jerarqu��a.En el modelo jer�arquico de PKI, cada parte conoce la llave p�ublica de la ACde nivel superior. Cualquier certi�cado puede ser veri�cado a trav�es de laruta de certi�caci�on establecida entre la AC subordinada y la AC ra��z.

2.2.2. Malla

En este esquema las ACs se certi�can una con otra, resultando en unamalla de relaciones de con�anza entre las ACs. En este caso existen diversos

2.3. CONCLUSIONES 31

caminos de certi�caci�on al estar unidas todas las AC. No existe una ACcentral por lo que no se responsabiliza a una �unica identidad de la con�anzaque da el usuario. Se debe con�ar en todas las ACs

2.2.3. Puente

La arquitectura de puente fue dise~nada para conectar diversas PKIs sinimportar su arquitectura. Esto es realizado mediante la introducci�on de unanueva AC, llamada AC puente, la cual tiene el �unico prop�osito de establecerrelaciones entre las diversas PKIs. A diferencia de las otras arquitecturas, laAC puente no expide certi�cados directamente a entidades �nales. La ideab�asica es que todos los usuarios de PKI consideren la AC puente como unintermediario capaz de establecer relaciones uno a uno con las diferentesPKIs.

Si el dominio de con�anza es implementado como una PKI jer�arquica, laAC puente establece una relaci�on con la AC ra��z. Si el dominio es implemen-tado como una PKI de malla, la AC puente establece una relaci�on con s�olouna de las ACs.

2.3. Conclusiones

En este cap��tulo se vio una breve descripci�on de la infraestructura PKI,se comenta acerca de por que es necesaria, las ventajas que nos brinda y lasarquitecturas que se pueden manejar. Se describen los servicios que ofrecey de manera muy general las estructuras de datos necesarias para su im-plementaci�on. El manejo de llaves es una parte fundamental para prevenirataques al criptosistema de llave p�ublica, una soluci�on propuesta es el usode PKI, el cu�al nos brinda soporte para �este y otros posibles ataques que sepueden presentar en el criptosistema de llave p�ublica. Para que la criptograf��ade llave p�ublica pueda ser utilizada con �exito en aplicaciones comerciales enredes como Internet y prevenir ataques, es necesario contar una infraestruc-tura que mantenga v��nculos con las llaves p�ublicas utilizadas y sus respectivasentidades que las posean. La infraestructura de llave p�ublica (PKI) vinculallaves con entidades a trav�es de certi�cados digitales, permite que otras en-tidades veri�quen los v��nculos con las llaves p�ublica, y provee los serviciosnecesarios para la administraci�on de las llaves en un sistema distribuido.


La infraestructura de llave p�ublica utilizada en Internet est�a basada en elest�andar X.509 [17] propuesto por la IETF.

Cap��tulo 3

Notar��a Digital

En este cap��tulo se describe el funcionamiento de una Notar��a Digitalas�� como los diversos protocolos que la integran. La Notar��a Digital persiguela meta de certi�car datos sobre un periodo de tiempo a trav�es de un r�egimende mecanismos t�ecnicos dise~nados para soportar la solicitud de prueba deveracidad de los datos. Los mecanismos necesarios para poder realizar estaspruebas son:

Servidor de Estampas de Tiempo

Protocolo de almacenamiento a largo plazo

Registro de evidencia

Estampa de Tiempo de Almacenamiento

Cadenas de Estampas de Tiempo y Secuencias de Estampas de Tiempo

3.1. Servidor de Estampas de Tiempo

Un servicio de Estampas de tiempo prov�ee una prueba de existencia paraun dato en un instante en el tiempo. Una Autoridad de Estampas de Tiempo(AET) puede operar como un servicio de terceras partes aunque otros mo-delos de operaci�on pueden ser usados tambi�en, por ejemplo una organizaci�onpuede requerir un AET para uso interno. El servicio de no repudio requierela habilidad de establecer la existencia de datos en un punto espec��co en

33

34 CAP�ITULO 3. NOTAR�IA DIGITAL

el tiempo. Para asociar un dato con un punto particular en el tiempo, unaAutoridad de Estampas de Tiempo puede ser usada.

Algunos ejemplos son:

Veri�car que una �rma digital fue aplicada a un mensaje antes que elcerti�cado correspondiente fuera revocado.

Indicar el tiempo de env��o en una fecha �nal cr��tica.

Indicar el tiempo de una transacci�on de entradas en un registro desucesos.

3.1.1. Estampas de Tiempo

Las estampas de tiempo es una t�ecnica que previene la corrupci�on de fechay hora. En ocasiones se requiere la comprobaci�on en tiempo de la existenciade un documento, por ejemplo en derechos de autor o en una disputa depatentes la parte que produjo primero la copia del trabajo es la que obtieneel derecho.

Un notario puede �rmar y guardar las copias de un documento en papely determinar la legalidad del documento a partir de la fecha estampada. Encambio, con un documento digital es complicado, no hay manera de examinarde manera con�able que un documento fue creado en una fecha determinada,porque �esta pudo ser modi�cada.

Para buscar una soluci�on a este problema se desean cumplir los siguientesrequerimientos [12]:

Los datos deben de tener la estampa de tiempo dentro de la informa-ci�on.

Que sea posible que al cambiar un s�olo bit del documento se detecte elcambio.

Que sea posible no poder poner en el documento una hora y fechadiferente de la actual.

Algunas propuestas para solucionar este problema son las siguientes:

1. Soluci�on por arbitraje: la autoridad estampa y almacena una copia delarchivo

3.1. SERVIDOR DE ESTAMPAS DE TIEMPO 35

2. Soluci�on por arbitraje mejorada: la autoridad estampa y �rma un di-gesto del archivo

3. Protocolo ligado: la autoridad estampa y �rma un digesto del archivo.Liga la estampa con la anterior, que es el �ultimo digesto estampado. Alestar ligadas las estampas, para modi�car una es necesario modi�cartodas.

4. Protocolo distribuido: se utilizan varias autoridades de estampas detiempo en donde cada una genera una estampa parcial, la autoridadque recibe la petici�on integra las estampas parciales y forma la estampacompleta [1].

3.1.2. Autoridades de Estampas de Tiempo (AET)

El prop�osito principal de una autoridad de estampas de tiempo es probarque un determinado documento fue generado en la fecha y hora indicada sinhaber sufrido alteraciones. Una autoridad de estampas de tiempo tiene queoperar como un servicio con�able de terceras partes.El protocolo Internet X.509 Public Key Infrastructure Time-Stamp Protocol(TSP) [2] de�ne una autoridad de estampas de tiempo, especi�ca la petici�ondel servicio y la respuesta que debe ser generada, as�� como los errores, losm�etodos de seguridad que se deben de utilizar, las pol��ticas, las estructurasde los datos y requerimientos de una autoridad certi�cadora.Un servicio de estampas de tiempo soporta peticiones de veri�caci�on, queconsiste en demostrar que un dato existi�o en una fecha y hora determinada.

Los pasos principales seguidos por este protocolo son (ver �gura 3.1):

1. Enviar la huella generada por el algoritmo hash del archivo a validar.

2. Generar una respuesta que contenga el valor hash, el tiempo, y el cer-ti�cado de la autoridad.

Para validar la respuesta recibida se tienen que veri�car los siguientespuntos:

Se veri�ca que el estado recibido no sea error.

Se veri�ca que la huella recibida coincida con la huella mandada.


Figura 3.1: Funcionamiento de la Autoridad de Estampas de Tiempo

Se veri�ca que el certi�cado sea el de la Autoridad de Estampas deTiempo.

Se veri�ca el tiempo incluido en la respuesta contra una referencia detiempo local.

Se veri�ca que el estado del certi�cado no sea revocado.

Se veri�ca que las pol��ticas sean las de�nidas por el cliente.

Si alguna de estas veri�caciones falla, la respuesta recibida no es v�alida.

Otro protocolo de�nido en [1] agrega medidas de seguridad como un bo-leto para evitar a usuarios no permitidos acceder al servicio, tambi�en agregaservidores de estampas que se dividen la creaci�on de la estampa de tiempo,en donde cada servidor genera una estampa de tiempo parcial y al �nal elservidor que recibe la respuesta junta las estampas parciales y genera la es-tampa completa, lo cual hace m�as con�able al AET ya que no es una entidad�unica.

3.2. PROTOCOLO DE ALMACENAMIENTO A LARGO PLAZO 37

3.2. Protocolo de almacenamiento a largo pla-

zo

La conservaci�on de los documentos es importante, pues uno puede decirque las reglas de almacenamiento apropiadas son un prerrequisito para quelos datos se conviertan en un documento. El almacenamiento tiene diver-sos aspectos, por ejemplo un documento puede ser conservado y despu�es deun cierto periodo puede ser destruido, o bien, su tiempo de vida extendido.Asimismo un documento puede ser accesible por cualquiera o tener restric-ciones y s�olo ser accesible para un conjunto de entidades autorizadas.

El protocolo utilizado en este trabajo permite el uso de un servicio es-pecializado para la conservaci�on de documentos electr�onicos [18]. El serviciocrea y entrega su�ciente informaci�on para demostrar la existencia, integri-dad y autenticidad de datos digitales sobre un periodo de tiempo. El servicioasume la responsabilidad de entregar y almacenar datos para su conservaci�on,crear y almacenar evidencia que garantice la integridad de los datos y man-tener accesibilidad a los datos y la evidencia creada. La conservaci�on de do-cumentos es generalmente desarrollada por servicios especializados, aunquegeneralmente en la peque~na empresa no se tiene cuidado con este aspecto.Se debe de tener una estructura y pol��ticas que nos permitan el correctoalmacenamiento de los documentos digitales. El rol principal de un serviciode Almacenamiento a Largo Plazo es generar y proveer informaci�on para laexistencia de datos almacenados en un punto en el tiempo, demostraci�on deintegridad y autenticidad sobre un periodo largo de tiempo. La conservaci�onconsiste en algo m�as que s�olo almacenar el documento. Cuando el tiempo devida es muy largo, se deben de tomar medidas apropiadas para asegurar laintegridad de los documentos.


Un servicio de Almacenamiento a Largo Plazo est�a compuesto por va-rios m�odulos. Algunos de estos m�odulos no son considerados por el protocoloLTANS propuesto en [15]. Ejemplos de estos m�odulos son, la red de comuni-caci�on, el dispositivo de almacenamiento y manejo de archivos, entre otros. Elservicio implementa la forma de interactuar entre entidades, maneja objetosde almacenamiento y registros de evidencia.

Los objetos de almacenamiento est�an de�nidos por una estructura l�ogica


que consiste en:

Datos de almacenamiento (incluye meta datos u otros datos relaciona-dos).

Proceso de almacenamiento relacionado a la informaci�on.

Evidencia de la informaci�on.

El dato de almacenamiento puede ser de cualquier tipo, por ejemplo datosplanos, datos �rmados, datos cifrados o estampas de tiempo, todos ellosse encuentran de�nidos en [35]. Los datos de almacenamiento pueden estarasociados con informaci�on adicional o atributos como datos adicionales de lainformaci�on principal o �rmas digitales.

Los datos generados o coleccionados por el servicio para el proceso dealmacenamiento relacionado con la informaci�on incluyen demostraci�on de lainformaci�on y evidencia. Cierta informaci�on adicional debe ser almacenadapara diversos prop�ositos, por ejemplo para validar las �rmas digitales puedeser necesario almacenar informaci�on legal. La informaci�on puede incluir elnombre del due~no, organizaci�on, direcci�on, etc.

La informaci�on de demostraci�on es almacenada, como su nombre lo indicapara, demostrar hechos de los datos almacenados. Esta informaci�on puedeser metadatos de la �rma digital. El protocolo usa recursos externos paraintegrar esta informaci�on usualmente sin intervenci�on del usuario. Los datosde evidencia son generados por entidades externas, por ejemplo una autoridadde estampas de tiempo.

El servicio proporciona mantenimiento constante a los objetos de alma-cenamiento generados con el prop�osito de demostrar la integridad de la in-formaci�on en un punto en el tiempo, por ejemplo pruebas de lectura, copiasde material nuevo, renovaci�on de estampas de tiempo.

El protocolo consiste en dos capas, la capa superior de�ne las funcionesdisponibles, la capa inferior de�ne las reglas para el intercambio de mensajespara todas las funciones.

3.2.2. Servicios proporcionados

La meta principal del protocolo es permitir una interacci�on formal entreel usuario y el Servicio de Almacenamiento a Largo Plazo. El resultado deesta interacci�on es realizar procedimientos mediante el servicio. La interfazdel servicio permite al usuario desarrollar al menos las siguientes operaciones:

3.3. REGISTRO DE EVIDENCIA 39

1. ALMACENAMIENTO: Enviar datos a un Servicio de Almacenamientoa Largo Plazo y solicitar la creaci�on de informaci�on de evidencia paralos datos.

2. ESTADO: Informar acerca del estado de los datos.

3. VERIFICACI�ON: Determinar la integridad y validez de los datos al-macenados.

4. EXPORTACI�ON: Solicitar datos (incluyendo datos almacenados, metainformaci�on y evidencia de la informaci�on) de un servicio de Almace-namiento a Largo Plazo.

5. BORRADO: Remover datos o evidencia de la informaci�on del servicio.

Estas operaciones son el m��nimo conjunto que debe ser implementado porun servicio de Almacenamiento a Largo Plazo. Se pueden proponer serviciosadicionales, ya sea extendiendo las operaciones con par�ametros adicionales ode�niendo nuevas operaciones.

3.3. Registro de evidencia

En diversas �areas de aplicaci�on de intercambio de datos, debe ser posiblecontar con el servicio de no-repudio de la existencia de datos digitales. Enalgunos casos esta prueba debe sobrevivir largos periodos de tiempo, muyespecialmente la �rma digital.

Durante el periodo de almacenamiento de los datos �rmados digitalmente,los algoritmos hash y algoritmos de llave p�ublica pueden ser comprometidoso los certi�cados pueden expirar. Estos eventos complican la con�anza endatos �rmados digitalmente despu�es de muchos a~nos. Para evitar la p�erdi-da de la seguridad derivada de la �rma digital, es necesario probar que losdatos �rmados digitalmente existieron antes de que los algoritmos fuerancomprometidos. Esto puede lograrse usando estampas de tiempo. Sin embar-go algunas estampas de tiempo se basan en mecanismos que ser�an sujetosa los mismos problemas. Para solucionar estos problemas las estampas detiempo son renovadas simplemente obteniendo una nueva estampa de tiem-po que cubra a la anterior. Es necesario estandarizar los formatos de datosy procedimientos para las estampas de tiempo con la �nalidad de ser capazde veri�car y comunicar la evidencia de la informaci�on.


Un acercamiento fue hecho en [25] donde el atributo opcional ArchiveTimeStamp fue especi�cado para integrarse en �rmas digitales basadas enCryptographic Messages Syntax (CMS) [13].

La Sintaxis de Evidencia de Registro (SER) [5] aumenta y generaliza elacercamiento para datos en cualquier formato y toma en cuenta los reque-rimiento de almacenamiento a largo plazo [36]. SER especi�ca una sintaxispara el Registro de Evidencia que contiene un conjunto de estampas de tiem-po y datos adicionales as�� como los procesos de generaci�on y veri�caci�on dela Evidencia de Registros. Las bases de SER son Estampas de Tiempo deAlmacenamiento, las cuales pueden cubrir un s�olo objeto [2] o pueden cubrirun grupo de objetos. Los grupos de objetos de datos son direccionados con�arboles hash descritos por Merkle [23]. Las caracter��sticas de un �arbol hashson:

Las hojas del �arbol son valores hash de los objetos en el grupo.

Una solicitud de Estampa de Tiempo es solicitada s�olo para la ra��z del�arbol.

La eliminaci�on de un objeto en el �arbol no in uenc��a a los otros.

Para cualquier objeto particular el �arbol puede ser reducido a un con-junto de valores hash que es su�ciente para probar la existencia de uns�olo objeto.

El �arbol hash puede ser reducido para probar la existencia de un con-junto de datos, cuando todos los miembros del grupo de datos tienenel mismo nodo padre en el �arbol.

Antes de que los algoritmos criptogr�a�cos usados en la estampa de tiem-po de almacenamiento sean comprometidos o los certi�cados usados para�rmar la estampa de tiempo sean revocados, la estampa de tiempo de alma-cenamiento debe ser renovada, generando una nueva estampa de tiempo dealmacenamiento.

SER distingue dos maneras de renovaci�on: de estampa de tiempo de al-macenamiento y de �arbol hash.

Dependiendo de las situaciones se realiza la renovaci�on, por ejemplo si lallave privada de la estampa de tiempo ha sido comprometida, se realiza larenovaci�on de estampa de tiempo. En caso que el algoritmo hash usado para

3.3. REGISTRO DE EVIDENCIA 41

construir el �arbol sea comprometido se debe realizar la renovaci�on de �arbolhash.

En el caso de una renovaci�on de estampa de tiempo, �esta tiene que serresumida y estampada por una nueva estampa de almacenamiento. Esto esusado cuando no se tiene que acceder a los objetos que cubre la estampa. Porejemplo si el certi�cado de la autoridad de estampas de tiempo est�a cerca deexpirar.

Si el algoritmo hash usado para crear el �arbol es comprometido es nece-sario realizar una renovaci�on de �arbol hash, toda la evidencia de los datosdebe ser accesada y estampada de nuevo. Esto incluye todos los objetos quecubre la Estampa de Tiempo.

Un Registro de Evidencia es una unidad de datos, la cual puede ser usadapara probar la existencia de un objeto de dato almacenado o de un grupo dedatos almacenados. Este registro de evidencias contiene Estampas de Tiempode Almacenamiento, generadas durante un periodo largo de almacenamientoy posiblemente datos para la validaci�on.

3.3.1. Generaci�on

Los pasos para generar el Registro de evidencia (Ver �gura 3.2) son lossiguientes:

1. Seleccionar un objeto de dato o un grupo de objetos de datos a alma-cenar.

2. Crear una Estampa de Tiempo de Almacenamiento inicial.

3. Actualizar la Estampa de Tiempo de Almacenamiento cuando sea nece-sario por cualquier tipo de renovaci�on.

3.3.2. Veri�caci�on

La veri�caci�on de la Evidencia (Ver �gura 3.3) se describe a continuaci�on:

1. Seleccionar un objeto o grupo de objetos de datos almacenados.

2. Volver a cifrar el objeto, si el campo de cifrado es usado.

3. Veri�car la secuencia de la Estampa de tiempo de Almacenamiento.


Figura 3.2: Generaci�on del Registro de Evidencia

Figura 3.3: Generaci�on del Registro de Evidencia

3.4. ESTAMPA DE TIEMPO DE ALMACENAMIENTO 43

3.4. Estampa de Tiempo de Almacenamiento

Una Estampa de Tiempo de Almacenamiento es una estampa de tiempo yun conjunto de listas de valores hash. Las listas de valores hash son generadaspor reducci�on de un �arbol hash Merkle ordenado [23]. Las hojas son los valoreshash de los objetos. Cada nodo interno es un valor generado por el resumende la concatenaci�on de los valores hash hijos. La ra��z hash del �arbol querepresenta todos los objetos es estampada.


La lista de los valores hash puede ser generada construyendo y reduciendoun �arbol hash Merkle de la siguiente manera:

1. Juntar los datos objetos a ser estampados.

2. Seleccionar un algoritmo seguro H y generar los valores hash para losdatos objeto. Estos valores ser�an las hojas del �arbol.

3. Para cada grupo de datos que contienen m�as de un documento, surespectivo hash se ordena de forma binaria ascendente, concatenados yresumidos.

4. Si hay m�as de un valor hash, se colocan en grupos y se ordena cadagrupo en orden binario ascendente. Se concatenan estos valores y segeneran nuevos valores hash, los cuales son los nodos internos del �arbol.Repetir este paso hasta que s�olo exista un valor hash, el cual es la ra��zdel �arbol.

5. Se obtiene una estampa de tiempo para la ra��z del �arbol.

Un ejemplo de un �arbol hash para 3 grupos de datos (Ver �gura 3.4),donde los grupos de datos 1 y 3 s�olo contienen un documento, y el grupode datos 2 contiene 3 documentos. Los documentos est�an organizados de lasiguiente manera:

h1 = H (d1) donde d1 es el �unico objeto del grupo 1

h3 = H (d3) donde d3 es el �unico objeto del grupo 3

h12 = H (concatenaci�on y ordenaci�on binaria de (h1, h2abc))


Figura 3.4: �Arbol hash de 3 grupos de datos

h123 = H (concatenaci�on y ordenaci�on binaria de (h12, h3))

h2abc = H (concatenaci�on y ordenaci�on binaria de (h2a, h2b, h2c))

El �arbol puede ser reducido a una lista de valores hash necesarios paratener una prueba de la existencia para un s�olo objeto de datos. Los pasospara realizar la reducci�on del �arbol hash son los siguientes:

1. Generar el valor hash h del objeto dato, usando el algoritmo hash Hdel �arbol.

2. Seleccionar todos los valores hash, los cuales tienen el mismo padre queel nodo h. Genera la primera lista de valores hash juntando los valoreshash en orden binario ascendente. Repetir este paso para el nodo padrehasta que se llegue a la ra��z. Los nodos padres no son guardados en lalista, si no m�as bien estas son calculadas, es decir que se pueden generara partir de la concatenaci�on de los nodos hijo y el valor hash de �estaes el nodo padre.

3. La lista de todos los valores hash concatenados representan el �arbolreducido.

4. Agregar la estampa de tiempo y la informaci�on del algoritmo hash.

3.4. ESTAMPA DE TIEMPO DE ALMACENAMIENTO 45

Figura 3.5: �Arbol hash reducido para el grupo de datos 1

Asumiendo que el orden binario de la �gura 3.4 es h2abc < h1 entoncesel �arbol hash reducido para el grupo de datos 1 (d1) se muestra en la �gura3.5

El pseudo c�odigo en ASN.1 para el �arbol reducido rht1 queda como sigue:

rht1 = SEQ(pht1, pht2)

pht1 = SEQ (h2abc, h1)

pht2 = SEQ (h3)


Una Estampa de Tiempo de Almacenamiento prueba que un objeto datoexisti�o en cierto tiempo. Esto puede ser veri�cado como sigue:

1. Calcular el valor hash h del objeto dato con el algoritmo H.

2. Buscar el valor hash en la primer lista del �arbol reducido, si no est�a pre-sente, el proceso termina con un resultado negativo.

3. Concatenar el valor hash de la lista actual de los valores hash en ordenbinario ascendente y calcular el valor h0 con el algoritmo H. Este valorh0 debe ser miembro de la siguiente lista de valores hash. Continuareste paso hasta calcular la ra��z.

4. Comprobar que la estampa de tiempo, el algoritmo y el valor hash dela estampa coincidan.


3.5. Cadenas de Estampas de Tiempo y Se-

cuencias de Estampas de Tiempo

Una estampa de tiempo de almacenamiento provee una prueba de exis-tencia de un s�olo objeto o de un grupo en cierto tiempo. Sin embargo, puedellegar a volverse inv�alida si alg�un algoritmo utilizado para su generaci�on escomprometido o si el certi�cado de la autoridad de estampas de tiempo esrevocado. Para evitar que esto suceda, la estampa debe ser renovada. Estopuede ser efectuado de dos maneras:

Renovaci�on de estampa de tiempo: Una nueva estampa de tiempo dealmacenamiento es generada, la cual cubre la estampa anterior. Unao m�as estampas de tiempo de almacenamiento forman una cadena deestampas de tiempo.

Renovaci�on de �arbol hash: Una nueva estampa de tiempo de alma-cenamiento es generada, la cual cubre todas las estampas anterioresas�� como los objetos de datos. Una nueva cadena de estampas de tiem-po es comenzada. Una o m�as cadenas de estampas de tiempo formanuna Secuencia de estampas de tiempo.


En el caso de la renovaci�on de estampa de tiempo, el hash de la estampaanterior debe ser resumido y estampado por la nueva estampa de tiempo, elalgoritmo hash debe de ser el mismo que el anterior. La nueva estampa debeser agregada a la cadena de estampas.

En el caso de la Renovaci�on del �arbol hash, la Estampa de tiempo y losobjetos que cubre la Estampa de tiempo deben de ser resumidos y estampadosde nuevo, como se describe a continuaci�on:

1. Seleccionar un algoritmo hash seguro H.

2. Seleccionar objetos dato d(i) referenciados por la estampa inicial. Ge-nera valores hash h(i) = H(d(i)). Si hay grupos de datos con m�as deun documento, entonces se tiene m�as de un hash para un grupo, porejemplo h(ia); h(ib); :::; h(in) para un grupo con n documentos.

3.5. CADENAS DE ESTAMPAS DE TIEMPOY SECUENCIAS DE ESTAMPAS DE TIEMPO47

3. atsc(i) es la secuencia de estampas codi�cada, es decir la concatenaci�onde todas las cadenas de estampas relacionadas al objeto d(i). Generarel valor hash ha(i) = H(atsc(i)).

4. Concatenar cada h(i) con ha(i) y generar valores hash h(i)0 = H(h(i)+ha(i)). Para grupos de documentos, h(ia)

0 = H(h(ia) + ha(i)), h(ib)0 =

H(h(ib) + ha(i)), ..., h(in)0 = H(h(in) + ha(i)).

5. Construir una nueva estampa de tiempo para cada h(i)0.

6. Crear una nueva cadena de estampas conteniendo las nuevas estampasde tiempo, y agregar esta cadena a la secuencia actual.

Un ejemplo de la renovaci�on (ver �gura 3.6) siendo H el nuevo algoritmohash seguro, quedar��a de la siguiente manera;

ha(1), ha(2), ha(3) est�a de�nido en el paso 4.

h1'= H( concatenaci�on y ordenaci�on binaria de (H(d1), ha(1))) donded1 es el documento original.

h3'= H( concatenaci�on y ordenaci�on binaria de (H(d3), ha(3))) donded3 es el documento original.

h2a'= H( concatenaci�on y ordenaci�on binaria de (h2a, ha(2)))

h2abc = H( concatenaci�on y ordenaci�on binaria de (h2a', h2b', h2c'))


Para obtener una prueba de no-repudio de que un dato existi�o en ciertotiempo, las cadenas de estampas y sus relaciones con cada una de ellas y conlos objetos datos deben de ser probadas como sigue:

1. Veri�car que la primera estampa de tiempo de almacenamiento de laprimera Cadena de Estampas de Tiempo contiene el valor hash del datoobjeto.


Figura 3.6: �Arbol hash con renovaci�on tipo �arbol hash

2. Veri�car cada Cadena de Estampa de Tiempo. El primer valor hash dela lista de cada estampa debe de contener el valor hash de la estam-pa anterior. Cada estampa debe ser validada en relaci�on a la siguienteestampa es decir, est�as deben ser consecutivas en relaci�on a la fecha. To-das las estampas en una cadena deben usar el mismo algoritmo hash yeste algoritmo debe ser seguro al tiempo de colocar la primera estampade la siguiente cadena.

3. Veri�car el primer valor hash de la lista de valores de la primera estampade todas las cadenas contiene un valor hash de la concatenaci�on del hashdel objeto dato y el valor hash de todas las cadenas anteriores. Veri�caque esta estampa fue generada antes de la �ultima estampa de la cadenase volviera no valida.

La �ultima estampa debe ser v�alida en el tiempo que la veri�caci�on esrealizada.

Algunas de las estructuras usadas en la estampa de tiempo de Almace-namiento se muestran en la �gura 3.7

3.6. CONCLUSIONES 49

Figura 3.7: Estructuras de la estampa de tiempo de almacenamiento

3.6. Conclusiones

En est�e cap��tulo revisamos el protocolo de Notar��a Digital que se utiliz�o enesta tesis. Tambi�en el funcionamiento de un servidor de Estampas de Tiempo.Se realiz�o una descripci�on de todos los pasos a seguir para la generaci�on yveri�caci�on de evidencia sobre los datos.

Cap��tulo 4

Comprobantes Fiscales

Digitales del SAT

En este cap��tulo se describe el funcionamiento de los Comprobantes Dis-cales Digitales implementados por el SAT. Durante los �ultimos 20 a~nos hemossido testigos de los avances tecnol�ogicos, tales como el Internet, que han cam-biado nuestra vida diaria. En la actualidad, Internet es usado para transmitirvoz, video y programas de televisi�on, publicar peri�odicos, realizar transac-ciones electr�onicas, etc. Una de las aplicaciones novedosas que hace uso delas herramientas de la tecnol�ogia de la informaci�on es llamada e-gobierno.

E-gobierno puede ser informalmente de�nido como el uso de las tec-nolog��as de informaci�on para el intercambio de informaci�on y servicios conciudadanos, empresas y otras entidades gubernamentales. El objetivo prin-cipal de e-gobierno es mejorar la e�ciencia interna, as�� como los serviciosp�ublicos y/o procesos de un gobierno democr�atico.

Varios pa��ses en Am�erica Latina han establecido un marco legal para re-gular las transacciones comerciales a trav�es de Internet. Por ejemplo, PuertoRico estableci�o una normativa que entr�o en vigencia en 1998, le sigui�o Colom-bia en 1999, M�exico y Per�u en el 2000, y Argentina y Venezuela durante el2001.

En el caso espec��co de M�exico, desde enero del 2005 el gobierno mexi-cano a trav�es del Sistema de Administraci�on Tributaria (SAT) ha ofrecido alos contribuyentes un sistema para el manejo de Comprobantes Fiscales Di-gitales (CFD) o com�unmente conocidos como facturas digitales. El serviciode CFDs tiene como objetivo la automatizaci�on del proceso contable para elpago de impuestos de personas f��sicas y personas morales, permitiendo a los

51

52 CAP�ITULO 4. COMPROBANTES FISCALES DIGITALES DEL SAT

contribuyentes acceso al sistema de CFDs por Internet.

Desde el 2005, el servicio de CFDs ha obtenido gradualmente mayor im-portancia, entre otras razones, por el incremento de empresas mexicanas ypersonas f��sicas que buscan automatizar sus procesos contables. Por ejemploen el caso del Gobierno Federal de M�exico la lista de dependencias que usanfacturas electr�onicas son: Banco de M�exico, Secretar��a de la Funci�on P�ublica,Secretar��a de Econom��a, Instituto Mexicano del Seguro Social. Del 5 de enerode 2005 al 16 de marzo de 2007. Una cantidad de 1,909 contribuyentes hanoptado por el esquema de CFD, 254 son personas f��sicas y 1,657 son personasmorales. Adem�as existen 4,136,707 CFD emitidos en el pa��s [9].

La Firma Electr�onica Avanzada FIEL conocida anteriormente como FEAes la implementaci�on de una �rma digital basada en el est�andar PKI [4]. Deacuerdo con las reformas al C�odigo Fiscal de la Federaci�on, publicadas en [31],todos los contribuyentes est�an obligados a tramitar la FIEL. Actualmenteexisten varios servicios que tienen o tendr�an como uso obligatorio la FIEL,para algunos otros es opcional [9].

La factura electr�onica en M�exico es la representaci�on digital de un tipode comprobante �scal digital, que utiliza los est�andares de�nidos por el SAT[29] en cuanto a forma y contenido. La seguridad en un documento �rmadopor la FIEL se obtiene cuando el emisor �rma una factura digital con su llaveprivada y el receptor la veri�ca con la llave p�ublica de acuerdo al proced-imiento en la �gura 1.2. Adem�as se deben de almacenar los 5 a~nos posteriorespor si existe alguna requisici�on y para poder ser destruidas tiene que pasarun periodo de 10 a~nos m��nimo [9]. Para poder emitir CFDs el SAT obliga alcontribuyente a llevar la contabilidad de manera electr�onica, Adicionalmentela transacci�on en el sistema electr�onico debe ser generado en el mismo tiempoque se crea el CFD. Debe de ser garantizado que la fecha, hora, minuto ysegundo en el registro contable es el mismo que en el CFD.

4.1. Descripci�on del Sistema

A continuaci�on se describe el sistema del SAT para el manejo de compro-bantes �scales digitales, el cual esta integrado por los siguientes m�odulos:

1. Solicitud de Certi�cados Digitales (SOLCEDI)

2. Sistema de Certi�caci�on del SAT (CERTISAT WEB)

4.1. DESCRIPCI �ON DEL SISTEMA 53

Figura 4.1: Sistema de CFD del SAT

3. Sistema Integral de Comprobantes Fiscales (SICOFI)

El m�odulo de SOLCEDI puede ser ejecutado desde cualquier m�aquinaque tenga sistema operativo Windows, los m�odulos CERTISAT y SICOFIson accedidos a trav�es de Internet bajo el protocolo de TLS [16] (Ver �gura4.1).

4.1.1. Solicitud de Certi�cados Digitales (SOLCEDI)

El contribuyente tiene a su disposici�on la aplicaci�on Solicitud del Certi-�cado Digital (SOLCEDI) para utilizarla como herramienta auxiliar, princi-palmente, en la generaci�on del archivo de requerimiento para obtener el certi-�cado digital de �rma electr�onica avanzada. Con el archivo de requerimiento,el contribuyente puede realizar en las instalaciones de la administraci�on localde atenci�on al contribuyente que le corresponda el proceso de obtenci�on delCerti�cado que utiliza ante el SAT en sus movimientos �scales, al cual nosreferiremos como certi�cado de �rma electr�onica avanzada. Esta aplicaci�ontambi�en contempla otras necesidades como son: la generaci�on de archivos de


requerimiento para solicitar certi�cados de sellos digitales y las herramientaspara construir archivos de seguridad que ser�an enviados al SAT por medio deInternet. Los archivos de seguridad son de dos tipos: a) uno que contiene unrequerimiento de certi�cado de �rma electr�onica avanzada para su renovaci�onllamada formato REN, que se ensobreta y b) otro que contiene un paquetede varios requerimientos de certi�cados de sellos digitales ensobretados. Enla p�agina del SAT en Internet el contribuyente cuenta con una liga, donde sepuede obtener el programa ejecutable.

Generaci�on de llaves y solicitud de certi�cados

Una llave RSA de 1024 bits es generada en un archivo electr�onico de 1024bits con extensi�on *.key, de�nida en el est�andar PKCS#8 [21] y cifrada bajolas especi�caciones del est�andar PKCS#1 [22]. La llave p�ublica y privada seobtiene a trav�es de una aplicaci�on desarrollada por el SAT que est�a disponibleen Internet llamada SOLCEDI(solicitud de certi�cados digitales) que utilizala librer��a criptogr�a�ca de c�odigo abierto OPENSSL. Tambi�en se puede ge-nerar con alguna otra librer��a que utilice el est�andar especi�cado.

El certi�cado FIEL es un documento electr�onico con extensi�on *.cer enformato X.509 V3 [14] generado por el SAT. El certi�cado liga informaci�ondel usuario (tal como nombre, direcci�on, organizaci�on, etc) a su llave p�ublica.Para garantizar su integridad y validez es �rmado por el SAT.

Funcionamiento pr�actico

A continuaci�on, se describen las opciones que componen la aplicaci�onSOLCEDI y los productos que se pueden obtener:

1. Generaci�on del requerimiento para solicitar el certi�cado de �rma elec-tr�onica avanzada:

Producto 1. Archivo de requerimiento de certi�cado de �rma elec-tr�onica avanzada que contiene los datos m��nimos para la genera-ci�on del certi�cado digital. Este archivo tiene extensi�on (*.req).

Producto 2. Archivo de la llave privada del solicitante. Cuya ex-tensi�on ser�a (*.key).

2. Renovaci�on


Producto 3. S�olo si se solicita el tr�amite de renovaci�on se creaun archivo con extensi�on (*.ren), el cual es enviado, a trav�es delmodulo CERTISAT.

3. Generaci�on del requerimiento para solicitar certi�cados de sellos digi-tales. Para poder generar este tipo de requerimientos es necesario contarcon un certi�cado de �rma electr�onica avanzada otorgado por el SAT.

Producto 4. Archivo de requerimiento de certi�cado de sello digitalque contiene datos extra��dos del certi�cado de FEA y al cual se leagrega el nombre que distinga a la Unidad o Sucursal a la cual se leotorgar�a el certi�cado de sello digital. Este archivo tiene extensi�on(*.req).

Producto 5. Archivo de la llave privada del solicitante para el usodel certi�cado de sello digital cuya extensi�on es (*.key).

4. Ensobretar Sellos

Producto 6. La solicitud de generaci�on de certi�cados de sellosdigitales s�olo se realiza a trav�es de la liga en la p�agina de Internetdel SAT, donde se recibe un archivo con extensi�on (*.sdg). Paraello se generan los requerimientos para certi�cado de sello digitalque necesite el contribuyente y con la herramienta de ensobretarsellos, se unen en un s�olo archivo y se env��a al SAT.

4.1.2. Sistema de Certi�caci�on del SAT (CERTISATWEB)

El SAT pone a disposici�on del contribuyente el sistema para la solicitudde certi�cados de sello digital y recuperaci�on de certi�cados a trav�es de In-ternet llamado CERTISAT WEB. Para ingresar a este servicio se utiliza laClave de Identi�caci�on Electr�onica Con�dencial (CIEC) o Firma Electr�onicaAvanzada (FIEL nombrada anteriormente como FEA).

Revocaci�on

La revocaci�on de los certi�cados puede ser de dos maneras, la primera espor el m�odulo de CERTISAT y la segunda es acudir a cualquier o�cina del


SAT con la documentaci�on correspondiente [9]. Para realizar la revocaci�onpor CERTISAT es necesario contar con la clave de revocaci�on y el certi�cado.Es posible revocar el certi�cada de FIEL y el certi�cado de solicitud de folios.La CRL [14] y OCSP [24] son opciones que el SAT implementara por Internet(web services), que se esperaban para el tercer trimestre del 2005 y no hansido liberadas o fueron canceladas.

Funcionamiento pr�actico

Las opciones con las que cuenta el sistema son las siguientes:

1. Revocaci�on de certi�cados. Se encarga de recibir las solicitudes parapoder revocar certi�cados. El sistema solicita datos que s�olo conoce elcontribuyente que desea dejar inactivo el certi�cado.

2. Seguimiento a solicitud de certi�cados. Es posible veri�car el esta-do en que se encuentran las solicitudes de certi�cados, generalmente loscerti�cados de sellos digitales, que permiten obtener folios para emitircomprobantes �scales digitales.

3. Recuperaci�on y descarga de certi�cados. Permite descargar loscerti�cados con los que cuenta un usuario del SAT, ya sea los propioso los de otros contribuyentes, es importante poder descargar los certi-�cados de otros contribuyentes puesto que con ellos es posible veri�carque la llave privada que usan para �rmar es valida.

4. Env��o de Solicitud de Certi�cados de Sello Digital. Es necesarioensobretar (*.sdg) los archivos de requerimientos de Sello Digital usan-do la Firma Electr�onica Avanzada con el m�odulo SOLCEDI. Se env��ael archivo .sdg a trav�es de la aplicaci�on CERTISAT Web.

Sistema Integral de Comprobantes Fiscales (SICOFI)

El m�odulo del emisor de comprobantes �scales digitales (Facturas Elec-tr�onicas) del Sistema Integral de Comprobantes Fiscales (SICOFI) es el en-cargado de la administraci�on de los folios y de la recepci�on del reporte men-sual de las facturas digitales.


Folios

El contribuyente tiene la obligaci�on de solicitar folios electr�onicos al SAT,los cuales est�an compuestos por una serie y n�umero. En caso de aprobaci�onel SAT otorga un n�umero de aprobaci�on por rango de folios otorgados.

La solicitud de folios se realiza en dos pasos principales, primero se solicitaun certi�cado de folios y despu�es se solicita la serie y rango de folios. La so-licitud del certi�cado de folios se realiza con programa SOLCEDI, generandoun archivo *.req y un *.key bajo los mismos est�andares de la solicitud de uncerti�cado de FIEL. El archivo *.req es encapsulado con el certi�cado FIEL,bajo la sintaxis de PKCS#7 [20] creando un archivo *.sdg el cual ser�a envia-do a trav�es de Internet mediante el modulo SICOFI. Al obtener el certi�cadode folios es posible solicitar la serie y folio requeridos.

Para mantener el uso de los folios el contribuyente debe preparar sussistemas administrativos para registrar folios y series. Adicionalmente, esnecesario hacer las validaciones pertinentes para evitar duplicidad de foliosy folios fuera del rango permitido en el sistema contable.

Reporte Mensual

Cada vez que el sistema contable emite un CFD no se avisa inmediata-mente al SAT de esta transacci�on si no que cada mes se deber�an reportaral SAT los CFD emitidos en el mes anterior. El reporte mensual se reali-zar�a a trav�es de la p�agina de Internet del SAT (SICOFI). El reporte mensualdebe contener la fecha, hora, minuto y segundo que se registr�o en el asientocontable y en la Factura Electr�onica. El formato de�nido para el reporte defolios est�a especi�cado en [29]. El reporte es �rmado por el SAT mediante elmodulo SICOFI.

4.1.3. Funcionamiento pr�actico

A continuaci�on se describen las opciones que presenta el m�odulo SICOFI:

1. Acceso de usuarios a trav�es de su Firma Electr�onica Avanzada utilizan-do la llave privada, certi�cado y contrase~na. En la emulaci�on del SATesta opci�on no est�a disponible debido a que se compromete la seguridadde la llave privada (ver ap�endice C), se accede mediante el RFC y unaclave.


2. Solicitud de folios: Solicitud de aprobaci�on para la asignaci�on de rangosde folios y series en su caso de comprobantes �scales digitales (FacturasElectr�onicas). Si se cuenta con el certi�cado de sello digital, entonces elsiguiente paso es solicitar un rango de folios y series en su caso al Ser-vicios de Administraci�on Tributaria. Esta solicitud de folios tiene comoobjetivo proporcionar al contribuyente folios v�alidos para usarlos en suproceso de facturaci�on electr�onica. Para poder realizar esta solicitud esnecesario que el usuario proporcione la siguiente informaci�on:

Registro Federal de Causante (RFC).

Serie y rango de folios.

Certi�cado de Firma Electr�onica Avanzada.

Llave privada.

3. Firmado de reporte mensual de los comprobantes �scales digitales, emi-tidos por Impresores Autorizados o AutoImpresores.

4. Env��o de archivos de reportes mensuales �rmados y solicitud de asig-naci�on de folios y series en su caso de comprobantes �scales digitales alServicios de Administraci�on Tributaria para su aprobaci�on o rechazo.

En este m�odulo del Sistema Integral de Comprobantes Fiscales (SICOFI)se puede enviar la siguiente informaci�on:

Solicitud de folios para comprobantes �scales digitales.

Reporte de comprobantes �scales.

5. Consulta de folios de comprobantes �scales digitales otorgados al Con-tribuyente.

Si cuenta con asignaciones de folios para comprobantes �scales digitalesy requiere realizar una consulta sobre los folios solicitados, se puedeconsultar el detalle de los rangos de folios asignados.

6. Consulta de reportes, consulta del estatus de los reportes enviados alServicios de Administraci�on Tributaria.

En esta opci�on se puede consultar el estado de los reportes mensuales decomprobantes �scales digitales enviados al Servicio de Administraci�onTributaria.


4.1.4. Consideraciones Generales

Formato XML

La generaci�on, interpretaci�on y conservaci�on de un comprobante �scaldigital, como lo es la factura digital, debe seguir el formato en lenguajeXML. La versi�on 1 de este formato fue publicada en [29], y la versi�on 2[31]. Cualquiera de los dos puede usarse de manera indistinta. El esquemaXML est�a de�nido �unicamente para contener los datos �scales. La informa-ci�on adicional (ejemplo: informaci�on comercial, c�odigo de barras, descuentos,promociones, n�umero de orden de compra que se factura, estampa de tiem-po, etc.), puede ser insertada dentro de la factura en una etiqueta llamada\addenda".

Comunicaci�on con el SAT

A la fecha actual es necesario realizar una conexi�on directa a la p�agi-na web del SAT para validar folios, validar certi�cados digitales y emitirReporte Mensual. El SAT supuestamente ofrecer��a a los contribuyentes loscomponentes necesarios para ejecutar la validaci�on autom�atica a trav�es deInternet (por ejemplo servicios web). Esta herramienta estaba proyectadapara el 2005 pero todav��a no ha sido liberada.

Almacenamiento

Toda factura electr�onica generada y/o recibida deber�a guardarse en suformato original XML. En [6] se estipula que el contribuyente (tanto el emisorcomo el receptor), deber�a almacenar el archivo XML en su domicilio �scalpor un per��odo de 5 a~nos para efectos �scales. El receptor puede guardar enpapel o digitalmente el formato en lenguaje XML. Es importante aclarar queel resguardo debe hacerse en el domicilio �scal del contribuyente registradoante el SAT. En caso contrario, deber�a noti�carse a la autoridad. El SAT noconsidera el almacenamiento seguro de la informaci�on, es deber del usuarioestablecer pol��ticas sobre los documentos electr�onicos.

Impresi�on de la Factura Electr�onica

En [30] se estipula que la impresi�on de la Factura Electr�onica, adem�asde los requisitos especi�cados en [7], deber�a contener la cadena original, el


n�umero de serie del certi�cado de sello digital, el sello digital y la leyenda:\Este documento es una impresi�on de un comprobante �scal digital".

4.2. Conclusiones

En este cap��tulo se describe el protocolo utilizado por el SAT para elmanejo de la �rma digital, especi�camente para el uso de los comprobantes�scales digitales. Se mencionan los m�odulos que utiliza la interfaz del SATpara el correcto uso del CFD. Se describe la arquitectura y la comunicaci�onde las interfaces que se muestran al p�ublico. Se describen los pasos que sedeben realizar para utilizar los comprobantes �scales digitales.

Cap��tulo 5

Implementaci�on

En este cap��tulo se describe la forma en que se implemento la Notar��aDigital, los m�odulos que la integran dentro de la arquitectura propuesta.As�� como la integraci�on al sistema del SAT. El sistema que se desarrollo esuna Notar��a Digital (Ver �gura 5.2) y la emulaci�on del sistema del SAT (Ver�gura 4.1) para manejo de facturas digitales fueron implementadas con ellenguaje de programaci�on Cn C++, la cual permite la generaci�on de docu-mentos certi�cados y la evidencia para probar su validez. El sistema incluyeun m�odulo para generar facturas electr�onicas y poder certi�carlas y almace-narlas. Estas facturas son generadas en lenguaje XML basadas en el est�andarde�nido por el SAT 1 en formato XSD. Las facturas electr�onicas que ya hansido certi�cadas deben almacenarse el tiempo que indica el SAT. Al utilizar elsistema de Notar��a Digital se pueden prevenir ataques, por ejemplo renovan-do los algoritmos utilizados. El sistema completo est�a formado por diversosm�odulos independientes mostrados en la �gura 5.1 que juntos forman la em-ulaci�on del SAT y la Notar��a Digital.

Si se tiene la necesidad de certi�car un documento en papel se recurrea un notario el cual da f�e de su legalidad. El notario legaliza y guarda unacopia del documento con la �nalidad de probar su autenticidad. Si se requierecerti�car un documento digital se recurre a una autoridad certi�cadora queveri�ca y legaliza la autenticidad de la �rma pero no del documento.

La introducci�on de comprobantes �scales digitales en el formato de fac-tura electr�onica facilita la comprobaci�on de gastos, aunque al ser �estas undocumento digital son f�aciles de falsi�car o de modi�car. La comprobaci�on

1El formato se encuentra en http://www.sat.gob.mx/sitio internet/cfd/2/cfdv2.xsd

61

62 CAP�ITULO 5. IMPLEMENTACI �ON

Figura 5.1: Arquitectura propuesta de una Notar��a Digital y emulaci�on delSAT

de las facturas es necesaria en el a~no de la declaraci�on de impuestos, adem�asse deben de almacenar los 5 a~nos posteriores por si existe alguna requisici�on;por otro lado para poder ser destruidas tiene que pasar un periodo de almenos 10 a~nos.

Las empresas para poder emitir comprobantes �scales digitales deben deutilizar un sistema contable electr�onico. Se debe realizar la emisi�on de loscomprobantes y los movimientos contables con una hora y fecha id�entica.El SAT exige la entrega de un resumen mensual de todos los comprobantesemitidos.

>C�omo garantizar que un comprobante �scal fue emitido en la fecha yhora que tiene marcado? Realizando la certi�caci�on del comprobante anteuna Notar��a Digital que nos permita la veri�caci�on de hasta 10 a~nos.

Utilizando una arquitectura cliente servidor para una Notar��a Digital (Ver�gura 5.2) y usando mecanismos criptogr�a�cos como �rmas digitales y es-tampas de tiempo, se puede crear una autoridad que realice la certi�caci�on dedocumentos digitales de cualquier ��ndole, en este caso de facturas digitales.En esta tesis se realiz�o la implementaci�on de un prototipo que cumple conesta arquitectura.

5.1. ARQUITECTURA PROPUESTA DE NOTAR�IA DIGITAL 63

Figura 5.2: Arquitectura propuesta de una Notar��a Digital

5.1. Arquitectura propuesta de Notar��a Digi-

tal

La arquitectura de Notar��a digital que se propone (ver �gura 5.2) cuentacon los siguientes m�odulos:

Notar��a Digital

Autoridad Certi�cadora

Autoridad de Estampas de Tiempo

Base de Datos

Generador de Comprobantes Fiscales Digitales (GENCFD)

5.1.1. Notar��a Digital

Es el m�odulo encargado de generar la evidencia de los archivos digitalesen este caso en espec��co de los comprobantes �scales digitales, se basa en elprotocolo LTAP [18]. En la implementaci�on realizada se establece la comuni-caci�on de un cliente con un servidor, funciona como un servicio independiente


que se comunica con la autoridad certi�cadora, la autoridad de estampas detiempo y la base de datos. Las funciones m��nimas necesarias que establece elprotocolo de almacenamiento, estado, veri�caci�on, exportaci�on y borrado seincluyen en la implementaci�on. El sistema utiliza el servidor WEB Apache,y para la aplicaci�on cliente se puede utilizar cualquier explorador WEB quemaneje el protocolo HTTPS para conexiones seguras. La forma en c�omo seconectan se muestra en la �gura 5.1

Proceso de generaci�on de factura digital

Para la generaci�on de la factura digital se siguen los siguientes pasos:

1. Capturar los datos en lenguaje XML correspondientes a la transacci�ondel comprobante �scal digital que exige la ley, basados en el formatoXSD.

2. Generar la cadena original que es el resumen de todos los datos que secapturaron en el formato de comprobante �scal digital.

3. Solicitar la estampa de tiempo a la autoridad de estampas de tiempoenviando el hash de la cadena original.

4. Adquirir la estampa de tiempo y anexar a la cadena original el tiemporecibido por la estampa.

5. Anexar la estampa de tiempo [2] al documento XML del comprobante�scal digital en el campo para extensiones que en el caso de los CFDsse llama addenda.

6. Firmar la cadena original que incluye el tiempo de la estampa con lallave privada.

7. Anexar al documento XML la �rma en el campo de sello digital.

8. Se env��a el comprobante �scal digital completo y el certi�cado digitalmediante la interfaz de Notar��a Digital.

9. La Notar��a Digital genera la evidencia de los documentos y los alma-cena.


Proceso de generaci�on de evidencia

Al recibir el comprobante �scal digital y el certi�cado digital la Notar��aDigital genera la evidencia para poder ser comprobados cuando se requiera,los pasos para generar la evidencia son los siguiente:

1. Crear el �arbol hash de los documentos recibidos.

2. Resumir el �arbol hash.

3. Solicitar una estampa de tiempo para la ra��z del �arbol.

4. Al realizar estos pasos se obtiene una estampa de tiempo de almace-namiento

5. Almacenar la estampa de tiempo de almacenamiento.

6. Si es necesario renovar la estampa de tiempo de almacenamiento, repe-tir los pasos del 1 al 5, tomando como documento la estampa anterior.

7. Almacenar las estampas en una cadena de estampas de tiempo de al-macenamiento.

8. Si es necesario renovar el �arbol hash, repetir los pasos del 1 al 5, toman-do como documento la �ultima estampa de la �ultima cadena.

9. Almacenar las cadenas en una secuencia de estampas de tiempo dealmacenamiento.

10. Realizar las renovaciones que sean necesarias para evitar que se com-prometan los datos.

Proceso de comprobaci�on de la evidencia

Para comprobar que un documento es valido se veri�ca mediante los si-guientes pasos:

1. Veri�car la estampa de tiempo de almacenamiento mas reciente con laautoridad de estampas de tiempo.

2. Si es v�alida, realizar un proceso de veri�caci�on en la cadena de estampasde tiempo revisando la estampa m�as reciente hasta la primera estampade la cadena.


3. Si es valida realizar u proceso de veri�caci�on en la secuencia de estam-pas de tiempo, repetir el paso 2 para todas las cadenas que se incluyanen la secuencia.

4. Si hay mas de una secuencia, repetir el paso 3 hasta llegar a la primeraestampa de tiempo de almacenamiento generada.

5. Repetir todo el proceso para cada documento el cual necesite la veri�-caci�on.

Proceso de comprobaci�on del documento �scal digital

Para poder comprobar que el DFD o factura digital es valida se realizanlos siguientes pasos:

1. Veri�car la evidencia del documento.

2. Veri�car el sello digital que se encuentra en el documento con el cer-ti�cado correspondiente. No importa que el certi�cado se encuentrerevocado o expirado, debido a que ya fue veri�cado con la evidencia.

3. Veri�car el tiempo en el CFD con el de la estampa de tiempo.

4. Veri�car la estampa de tiempo con la autoridad de estampas de tiempo.

5. Si alguna de las veri�caciones falla, el documento no es valido.

5.1.2. Autoridad Certi�cadora

Este m�odulo se encarga de desarrollar la infraestructura PKI, realiza laemisi�on de certi�cados as�� como la administraci�on de estos, si un certi�cadoes comprometido, se revoca inmediatamente. Se encarga de todos los aspectosde�nidos por el est�andar PKI. Se conecta a todos los m�odulos y almacenaun repositorio en la Base de Datos, donde almacena los certi�cados y suestado. La conexi�on se realiza con los m�odulos de la �gura 5.1. La autoridadest�a implementada en base a la autoridad certi�cadora de�nida en la librer��aOPENSSL [33], donde se especi�ca una autoridad y el funcionamiento de�esta. Se delimita las funciones que realiza y se especi�ca los protocolos quesoporta.


Funciones realizadas por la autoridad certi�cadora

Las funciones que realiza la AC son las siguientes:

Registro y generaci�on de certi�cados digitales x.509v3.

Almacenamiento y publicaci�on de certi�cados digitales.

Publicaci�on de listas de revocaci�on de certi�cados digitales.

5.1.3. Autoridad de Estampas de Tiempo

Este m�odulo realiza el estampado de la informaci�on conforme se va re-quiriendo. Se env��a una huella del documento digital y se regresa la respuestaincluyendo la huella, la estampa de tiempo y la �rma de la autoridad de es-tampas de tiempo. Si existe alg�un problema con el proceso de estampadode tiempo no se puede realizar la renovaci�on de la evidencia de los datos,ni el almacenamiento del comprobante �scal digital. La estampa de tiempoest�a estructurada en formato ASN.1 [11] que nos permite el intercambio deinformaci�on de manera transparente y sencilla, ya que el c�odigo se encuentraen formato hexadecimal.

El proceso para otorgar una estampa de tiempo es el siguiente:

1. Recibir el digesto hash del documento que se desea estampar.

2. Crear una estructura de estampa de tiempo y agregar el digesto y eltiempo actual del servidor de la autoridad de estampas de tiempo.

3. Firmar el digesto y el tiempo dentro y agregarla a la estampa de tiempo.

4. Entregar la estampa de tiempo al usuario.

El proceso para comprobar que la estampa de tiempo es valida es elsiguiente:

1. Recibir la estampa de tiempo.

2. Comprobar que el certi�cado de la �rma no ha sido revocado o expirado.

3. Comprobar la �rma de la estampa de tiempo.


4. Realizar el resumen hash del archivo al cual se le asigno la estampa detiempo.

5. Comprobar que el digesto es igual al digesto �rmado que se encuentraen la estampa de tiempo.

6. Si alguno de estos pasos falla, la estampa no es valida.

5.1.4. Base de Datos

La base de datos se encarga de almacenar las estructuras de los datosnecesarios, as�� como proporcionarlos en cuanto sean requeridos. La base dedatos tiene un rol muy importante en el sistema, ya que cubre las necesidadesde informaci�on de todos los m�odulos. La conexi�on entre los m�odulos se debeen gran medida a la estandarizaci�on del uso de la misma Base de Datos. Semaneja una base de datos central y en esta se encuentran todas las estructurasgeneradas que son certi�cados digitales, datos de los usuarios incluyendo susclaves y la evidencia de los documentos digitales certi�cados.

5.1.5. Generador de Comprobantes Fiscales Digitales(GENCFD)

Este m�odulo se encarga de generar comprobantes �scales digitales, uti-liza un formato de captura de los datos m��nimos necesarios as�� como otrosopcionales. Genera el archivo XML y lo deja listo para poder estamparlo conuna estampa de tiempo y �rmarlo.

5.2. Arquitectura de la aplicaci�on

Se describen las bibliotecas y los lenguajes utilizados para el desarrollode la arquitectura de Notar��a Digital

5.2.1. OPENSSL

OpenSSL es un proyecto de software desarrollado por los miembros dela comunidad Open Source para libre descarga y est�a basado en SSLeaydesarrollado por Eric Young y Tim Hudson. Consiste en un robusto paquetede herramientas de administraci�on y librer��as relacionadas con la criptograf��a.

5.2. ARQUITECTURA DE LA APLICACI �ON 69

El uso principal de estas bibliotecas es para la generaci�on y comprobaci�onde los elementos necesarios para la Firma Elect�onica, estampas de tiempo ygenerar la evidencia descrita en el protocolo de Almacenamiento a largo plazo.Tambi�en se utiliza una mini autoridad certi�cadora que se basa en esta libre-r��a la cual nos permite realizar algunas de las funciones de la infraestructurade PKI.

5.2.2. Sintaxis de Notaci�on Abstracta Uno(AbstractSyntax Notation One ASN.1)

Es una forma de representaci�on de los datos que no esta apegada a ningu-na plataforma en espec��co. Se encuentra en formato hexadecimal y nos per-mite el transporte de la informaci�on sin problemas de codi�caci�on. Se puederepresentar en Base64 o en binario.

5.2.3. XML

Permite de�nir la gram�atica de lenguajes espec��cos. Por lo tanto XMLno es realmente un lenguaje en particular, sino una manera de de�nir lengua-jes para diferentes necesidades. XML no ha nacido s�olo para su aplicaci�on enInternet, sino que se propone como un est�andar para el intercambio de infor-maci�on estructurada entre diferentes plataformas. Se puede usar en bases dedatos, editores de texto, hojas de c�alculo, etc. XML es una tecnolog��a sen-cilla que tiene a su alrededor otras que la complementan y la hacen muchom�as grande y con unas posibilidades mucho mayores. Tiene un papel muyimportante en la actualidad ya que permite la compatibilidad entre sistemaspara compartir la informaci�on de una manera segura, �able y f�acil. El uso delXML es obligatorio por parte del SAT para la generaci�on de comprobantes�scales digitales. De hecho los datos requeridos y opcionales se encuentrande�nidos en este lenguaje.

En este cap��tulo se muestra la propuesta de la arquitectura de Notar��aDigital integrada a el Sistema de manejo de CFD del SAT. Se de�nen losm�odulos que integran la Emulaci�on de CFD del SAT y la implementaci�on deun prototipo de arquitectura de Notar��a Digital.


5.3. Conclusiones

En este cap��tulo revisamos la arquitectura de la implementaci�on de laNotar��a Digital junto con la emulaci�on del SAT, se vio como funcionan lasdiferentes autoridades y los procesos que ejecuta cada una de estas parapoder certi�car un documento digital. El proceso de Notar��a digital dependede muchas entidades que trabajan independientes, en este caso se manejo demanera centralizado porque se trat�o de emular la forma en que funciona elSAT, pero ser��a conveniente utilizar entidades separadas y especializadas enrealizar las operaciones necesarias. El prototipo implementado esta apegadoa los comprobantes �scales digitales pero se puede independizar de estos sinnecesidad de grandes cambios en el prototipo.

Cap��tulo 6

Conclusiones

La migraci�on de los datos es importante, en especial cuando se trata demigrar a una nueva tecnolog��a que no tiene relaci�on alguna con la anteriorpero siempre se tiene que considerar todas las implicaciones que esto conlle-va. En nuestro, caso al realizar la migraci�on hacia documentos digitales, lacerti�caci�on de �estos es una consideraci�on que no se debe dejar pasar, sobretodo para documentos que son de almacenamiento a largo plazo. La Notar��aDigital permite certi�car documentos y veri�car que estos documentos nohan sido comprometidos.

Al almacenar un documento es muy importante considerar que los datosno sean alterados y que el documento permanezca en su estado original. Altransmitir el documento es necesario poder comprobar que el documento noha sido alterado o interceptado por alguna entidad no autorizada.

En el trabajo desarrollado en esta tesis, se program�o un sistema que escapaz de certi�car y almacenar documentos a largo plazo espec��camentedocumentos �scales digitales en su formato de factura digital que estableceel SAT. La tesis se basa en los protocolos desarrollados por el grupo detrabajo LTANS del IETF.

Para el desarrollo de este sistema se utilizaron varias t�ecnicas criptogr�a�-cas que son ampliamente usadas como criptograf��a de llave p�ublica, funcioneshash, �rma digital, autoridades certi�cadoras y autoridades de estampas detiempo. Tambi�en el protocolo tiene la capacidad de actualizar algunas de last�ecnicas usadas lo que nos permite que la seguridad de los documentos nosea comprometida.

71

72 CAP�ITULO 6. CONCLUSIONES

6.1. Contribuciones

Las contribuciones que se obtuvieron durante el desarrollo de esta tesisson las siguientes:

Un prototipo del protocolo de Notar��a Digital y almacenamiento a largoplazo basado en los documentos del grupo de trabajo LTANS del IETF.

La certi�caci�on y almacenamiento de comprobantes �scales digitales.

El uso de una arquitectura para el protocolo usando herramientas crip-togr�a�cas como una autoridad certi�cadora y una autoridad de estam-pas de tiempo.

Emulaci�on de la interfaz y comunicaci�on del uso de Firma Digital yComprobantes Fiscales Digitales del Sistema de Administraci�on Tribu-taria de M�exico.

Reporte de problemas de seguridad que se pueden presentar en la in-terfaz y comunicaci�on de la Firma Digital y Comprobantes FiscalesDigitales mostrados en el ap�endice C.

Desarrollo de un sistema que puede certi�car documentos y almacenar-los de manera segura a largo plazo.

6.2. Trabajo futuro

Los siguientes puntos se pueden considerar para realizar mejoras a estetrabajo de tesis:

Se utiliz�o una mini autoridad certi�cadora basada en OPENSSL, sepodr��a implementar con una autoridad certi�cadora completa.

En la autoridad de estampas de tiempo se utiliz�o el reloj del servidor,se podr��a implementar un reloj GPS que tenga comunicaci�on con lossat�elites.

Se certi�can s�olo documentos �scales digitales en formato de facturaelectr�onica, se puede ampliar a cualquier tipo de documento.

Se podr��a agregar algoritmos de curvas el��pticas y se puede migrar laNotar��a Digital a plataformas m�oviles.

Ap�endice A

Conversi�on de ASN.1 a

hexadecimal en lenguaje C

En este ap�endice se muestra la forma de codi�caci�on de la especi�caci�onen ASN.1 a formato hexadecimal en lenguaje de programaci�on C.

A continuaci�on se muestra un ejemplo de C�odigo en ASN.1

TimeStampReq ::= SEQUENCE fversion INTEGER f v1(1) g,messageImprint MessageImprint,reqPolicy TSAPolicyId OPTIONAL,nonce INTEGER OPTIONAL, g

MessageImprint ::= SEQUENCE fhashAlgorithm AlgorithmIdenti�er,hashedMessage OCTET STRING g

TSAPolicyId ::= OBJECT IDENTIFIER

La codi�caci�on en hexadecimal en C queda de la siguiente manera:lenstr=0;index=0;ASN1[0]=0x30;//sequence TimeStampReqASN1[1]=((max-1)+lenstr)&0x�;//longitud secuenciaASN1[2]=0x02;// integer versi�onASN1[3]=0x01;// longitud de versi�onASN1[4]=0x01;//valor de versi�on

73

74AP�ENDICE A. CONVERSI �ON DE ASN.1 A HEXADECIMAL EN LENGUAJE C

ASN1[5]=0x30;//5sequence MessageimprintASN1[6]=(lenstr+9)&0x�;;//longitud MessageImprintASN1[7]=0x06;//;AlgorithmIdenti�er SHA1 OID = 06 05 2B 0E 03 02 1AASN1[8]=0x05;//lenASN1[9]=0x2B;//valor OID;ASN1[10]=0x0E;// valor OID;ASN1[11]=0x03;// valor OID;ASN1[12]=0x02;//valor OID;ASN1[13]=0x1A;//valor OID;ASN1[14]=0x04;//Octect stringASN1[15]=lenstr&0x�;//longitud octectfor(i=0;i<lenstr;i++)fASN1[16+i]=ArregloHash[i]&0x�;gindex=lenstr;ASN1[16+index]=0x06;//OID TSApolicyIDASN1[17+index]=0x01;//len OID TSApolicyIDASN1[18+index]=0;//valor de OID TSApolicyID;ASN1[19+index]=0x2;//integer nonceASN1[20+index]=0x1;//tama~no boolean nonceASN1[21+index]=0x1;//valor boolean nonce

Ap�endice B

Formato de Comprobante

Fiscal Digital certi�cado

A continuaci�on se presenta un ejemplo de formato de un comprobante�scal digital certi�cado en XML:<?xml version = \1;0"encoding = \UTF � 8"? >< Comprobante xmlns = \http : ==www:sat:gob:mx=cfd=2"xmlns : xsi = \http : ==www:w3:org=2001=XMLSchema� instance"xsi : schemaLocation = \http : ==www:sat:gob:mx=cfd=2http : ==www:sat:gob:mx=sitiointernet=cfd=2=cfdv2:xsd"version = \2;0"serie = \abc"folio = \001"fecha = \2007� 03� 23T16 : 23 : 31"sello = \pKSu8amnKoQ2EV8yaGXGraK9c9dP1Q9ZuEQOBrQ6bKhr1yLsY3aJKOA0uS5eFZAr

nbhnJk+r91YSiCEOAds5lK7sYd72C6nm6qazqUQQx4uCYcKKojbBZkZf17hGDSql

QaFpYgrlT18TpTB3CV4cP516kCBtJMxc1zUKhvfs5ZzKw+ECU963zz8TRcYpK3lZ

GG4cWkYmINSHE8PnEgwIm8PW7bNuwEQgqcriVQlDkiUAe3fLoFCj6lLali6meLe/

cGgKBZ0jvS/AHSn7lIOrz1pEUut5Q5ocDsmB6Vtd83H1+jq6LXsj�/j3IhnYDhy

3/jBYI5bDZjQgZ/soPk++Q=="noAprobacion = \001"anoAprobacion = \2007"tipoDeComprobante = \ingreso"formaDePago = \EL PAGO DE ESTA FACTURA (CONTRAPRESTA-CION) SE EFECTUARA EN UNA SOLA EXHIBICION, SI POR ALGU-

75

76AP�ENDICE B. FORMATODE COMPROBANTE FISCAL DIGITAL CERTIFICADO

NA RAZON NO FUERA ASI, EMITIREMOS LOS COMPROBANTES DELAS PARCIALIDADES RESPECTIVAS"noCertificado = \01234567890123456789"subTotal = \100"total = \115" >< Emisorrfc = \GOGV 810402GH1"nombre = \V LADIMIR" >< DomicilioF iscalcalle = \TLAPA"noExterior = \21"colonia = \INMECAFE"municipio = \XALAPA"estado = \V ERACRUZ"pais = \MEXICO"codigoPostal = \91190"= >< =Emisor >< Receptorrfc = \GOGV 810402GH1"nombre = \V LAS" >< Domiciliocalle = \GEL"colonia = \LUZ"municipio = \XALAPA"estado = \V ER"pais = \MEX"= >< =Receptor >< Conceptos >< Conceptocantidad = \2"descripcion = \lata"valorUnitario = \10"importe = \20"= >< Conceptocantidad = \2"descripcion = \lata"valorUnitario = \10"importe = \20"= >< Conceptocantidad = \2"descripcion = \lata"valorUnitario = \10"importe = \20"= >< Conceptocantidad = \2"descripcion = \lata"

77

valorUnitario = \10"importe = \20"= >< Conceptocantidad = \2"descripcion = \lata"valorUnitario = \10"importe = \20"= >< =Conceptos >< Impuestos >< Traslados >< Trasladoimpuesto = \IV A"tasa = \15;0"importe = \15"= >< =Traslados >< =Impuestos >< Addenda >< EstampaT iempo >|{BEGIN PKCS7|{

MIIIiQYJKoZIhvcNAQcCoIIIejCCCHYCAQExCzAJBgUrDgMCGgUAMFoGCSqGSIb3

DQEHAaBNBEswSQIBAQYBADAdBgUrDgMCGgQUZonbrzUlikyJbT6gWunRBqbQCHYC

AQEYDjIwMDcwMzIzMTYyMzMxMAkCAQECAQECAQEBAQECAQGgggTtMIIE6TCCA9Gg

AwIBAgIJAIXUbhCU733qMA0GCSqGSIb3DQEBBQUAMIIBKTELMAkGA1UEBhMCTVgx

GTAXBgNVBAgTEERpc3RyaXRvIEZlZGVyYWwxETAPBgNVBAcTCENveW9hY2FuMQ4w

DAYDVQQREwUwNjMwMDEVMBMGA1UELRMMU0FUOTcwNzAxTk4zMS4wLAYDVQQKEyVT

ZXJ2aWNpbyBkZSBBZG1pbmlzdHJhY2lvbiBUcmlidXRhcmlhMTYwNAYDVQQLEy1B

ZG1pbmlzdHJhY2lvbiBkZSBTZWd1cmlkYWQgZGUgbGEgSW5mb3JtYWNpb24xNzA1

BgNVBAMTLkEuQy4gZGVsIFNlcnZpY2lvIGRlIEFkbWluaXN0cmFjaW9uIFRyaWJ1

dGFyaWExJDAiBgkqhkiG9w0BCQEWFXZsYXNsYW5kMkBob3RtYWlsLmNvbTAeFw0w

NjEwMjUxNzE3MDNaFw0xNjEwMjIxNzE3MDNaMIIBKTELMAkGA1UEBhMCTVgxGTAX

BgNVBAgTEERpc3RyaXRvIEZlZGVyYWwxETAPBgNVBAcTCENveW9hY2FuMQ4wDAYD

VQQREwUwNjMwMDEVMBMGA1UELRMMU0FUOTcwNzAxTk4zMS4wLAYDVQQKEyVTZXJ2

aWNpbyBkZSBBZG1pbmlzdHJhY2lvbiBUcmlidXRhcmlhMTYwNAYDVQQLEy1BZG1p

bmlzdHJhY2lvbiBkZSBTZWd1cmlkYWQgZGUgbGEgSW5mb3JtYWNpb24xNzA1BgNV

BAMTLkEuQy4gZGVsIFNlcnZpY2lvIGRlIEFkbWluaXN0cmFjaW9uIFRyaWJ1dGFy

aWExJDAiBgkqhkiG9w0BCQEWFXZsYXNsYW5kMkBob3RtYWlsLmNvbTCCASIwDQYJ

KoZIhvcNAQEBBQADggEPADCCAQoCggEBANBW4rolbh+3gauHwxJ6jG6EIf3Rc1EE

fy6jJm5CPsGRsOlyrIfIZSo6YOAerGoQiRIoNs8fyBGSRuWoJq3dAZdjMfhdXFvb

UOEwLib+mACmHZp4Fk+nHhtGaCq+deTb/iEFQvYJQ3SW5jPl/dOR1N5Z4J0XcU3l

26eaT/Mt7IoO6RXlptYHnRFm4xa+OvYV4BT6T3wItUD3N0O3K6xuKnVkq1Y7smVe

78AP�ENDICE B. FORMATODE COMPROBANTE FISCAL DIGITAL CERTIFICADO

64R/IphM/NvdWGB/OA7NTgJnCltOZ7EmRtThOLUEtcFdsCEwGr1SRmKqtax0CxKC

LtQcSkCbj6GF7pJdzwSgz14mO0sQfsFyVH2HTQhvGtPIO/ahmwHiDYkCAwEAAaMQ

MA4wDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOCAQEAoi4Oim8hM6J0LYO8

XlWRuaihtEBYf3QOxTmAAxAGZanGlbkCJDR2+OfDJ8gU43EneMk+69ulSBMYtJs+

rZnIw5fWrqr2YWUvkilAdmyXKk01tiRDAIr9FSfbHs64Zmtl6W9kE7ckit1AN+PA

9ax6Tg/bCw18ihc7ye4zZCVFo4XQxmqYQgA6YTK3ZaoQz3KYaZgVqG44p4xvEB2a

1EmXL+yl2p0uw3O/FmaAnkUYVwtS9tdtw7rSaZXvqjpEzm58VJT1tnycleo/rant

hlb+kNYPCXKpgrFglavjwKu+Uxsl2THNpp+USFrSfKepnkfHtNMe/0tCybPa2OV0

TnDhoTGCAxUwggMRAgEBMIIBODCCASkxCzAJBgNVBAYTAk1YMRkwFwYDVQQIExBE

aXN0cml0byBGZWRlcmFsMREwDwYDVQQHEwhDb3lvYWNhbjEOMAwGA1UEERMFMDYz

MDAxFTATBgNVBC0TDFNBVDk3MDcwMU5OMzEuMCwGA1UEChMlU2VydmljaW8gZGUg

QWRtaW5pc3RyYWNpb24gVHJpYnV0YXJpYTE2MDQGA1UECxMtQWRtaW5pc3RyYWNp

b24gZGUgU2VndXJpZGFkIGRlIGxhIEluZm9ybWFjaW9uMTcwNQYDVQQDEy5BLkMu

IGRlbCBTZXJ2aWNpbyBkZSBBZG1pbmlzdHJhY2lvbiBUcmlidXRhcmlhMSQwIgYJ

KoZIhvcNAQkBFhV2bGFzbGFuZDJAaG90bWFpbC5jb20CCQCF1G4QlO996jAJBgUr

DgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF

MQ8XDTA3MDMyMzIyMjMzMVowIwYJKoZIhvcNAQkEMRYEFNvbHhssL+4ZW+sOE1jf

WenISi9oMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC

AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqG

SIb3DQEBAQUABIIBAB20A0ponfRpcPibZvW5S61seCFkd3yY/kWJKUZxpWyqxLi+

MaJ6lfaQiMPPD12o1++u5n8beIdmciXghZbFgIK9s9VQ0SLwglBZRfeqe1nBzhrF

LDGoFnlbhf+mJdn/ImxstRg/ZB+DvuUxTC5tIn0c+X1XxT7HTf2OPpPyD9Q/vkW6

SJwvLgng0CQcK6Qnuj8d2iOHl2a7gxrXMvy5OmaZYCPM2Np0NMX2OOUhIV0EJQnU

5VmL8qrePO2cWjOX6BCx067wVZYOol8lmwLZiusdcnlgZy8ZoSnbR68LetGj462x

x4kncK+9pZMmGDBY9GAavw0lG9QRmoX7j6fhpKQ=

|{END PKCS7|{

< =EstampaT iempo >< =Addenda >< =Comprobante >

Dentro del PKCS7 se encuentra la informaci�on de la estampa de tiempo

Ap�endice C

Errores en la interfaz del SAT

de CFD

A continuaci�on se describen los problemas de seguridad encontrados enel sistema de manejo de comprobantes �scales digitales utilizado por el SAT.Tambi�en se plantean posibles soluciones a estos problemas.

C.1. Problemas

C.1.1. Autenticaci�on con llave privada

Para acceder a algunos servicios del SAT, es necesario realizar la autenti-caci�on con CIEC (Clave de Identi�aci�on Electr�onica Con�dencial) o con FIEL(Firma Electr�onica Avanzada). Al autenticar con la CIEC s�olo es necesariotener el RFC y la clave almacenada anteriormente.

En el caso de FIEL el sistema nos pide el certi�cado, la llave secreta y laclave de la llave secreta, lo cual es inaceptable porque la llave secreta y suclave nunca deben de ser revelados a ninguna entidad, en especial al gobierno.si la llave privada y su clave son enviadas a trav�es de Internet su seguridadpuede ser comprometida con ataques del tipo del \intruso de en medio". A�uncuando el ataque no es realizado por un oponente an�onimo, personal del SATpuede tener acceso a las llaves privadas y sus claves de los contribuyentes,con esto ellos podr��an �rmar a nombre del contribuyente.

Se piensa que este error debe de ser corregido inmediatamente, porqueniega la privacidad a todos los contribuyentes que manejen comprobantes

79

80 AP�ENDICE C. ERRORES EN LA INTERFAZ DEL SAT DE CFD

�scales digitales.

C.1.2. Falsi�caci�on de fechas

Como se describe en la secci�on 4.1., cuando se genera un CFD se reali-za una afectaci�on simultanea. La fecha y hora incluida tanto en el registrocontable como en el CFD est�a controlada por el programa que utilice el con-tribuyente, entonces se puede cambiar la fecha y hora actual en cualquiermomento, sin conocimiento del SAT . Esto da lugar a que se falsi�quen losdocumentos en aquellos casos que exista contubernio entre el cliente y elproveedor.

C.1.3. Uso de certi�cados

La infraestructura de PKI obliga la publicaci�on peri�odica de Listas deCerti�cados Revocados (CRL). Existen varias maneras para atacar este sis-tema en caso de que la CRL no sea actualizada peri�odicamente [34]. Por otrolado, realizar la revocaci�on de certi�cados en l��nea es �util para los certi�cadosde sellos digitales, pero es un problema para los certi�cados de FIEL ya queun atacante malicioso puede ser capaz de revocar el certi�cado e invalidarlas facturas emitidas sin que el usuario se de cuenta. Resulta peor si conocela llave secreta y su clave, debido a que puede renovar el certi�cado FIELcon sus datos. Un problema t�ecnico es obligar al usuario a llevar el archivode requerimiento la primera vez que se solicita el certi�cado FIEL en un dis-co magn�etico de 3;5 pulgadas, lo cual obliga a que se recurra a tecnolog��aobsoleta.

C.1.4. Algoritmos de criptograf��a

La FIEL y los certi�cados de folios son generados usando algoritmos crip-togr�a�cos que son actualmente obsoletos o que pronto lo ser�an. Por ejemplo,el algoritmo picadillo MD5 ha sido comprometido [26]. Tambi�en, se ha es-peculado que dada la tecnolog��a actual y el estado del arte de los algoritmosde factorizaci�on, RSA de 1024 bits no durar�a m�as de 5 a~nos. Despu�es de esepunto todos los est�andares recomendar�an moverse a RSA de 2048 bits, paragarantizar un margen de seguridad razonable.

C.2. RECOMENDACIONES 81

C.1.5. Carencia de almacenamiento seguro

El almacenamiento de los archivos se realiza en el domicilio �scal por unperiodo de 5 a~nos seg�un el [6] de no ser as�� se debe de avisar al SAT. Al rea-lizar el almacenamiento de CFD se efect�ua en formato XML. Sin embargo,como se menciona arriba se pueden comprometer los algoritmos criptogr�a�cosutilizados en la infraestructura del SAT y como consecuencia se vuelven vul-nerables los CFDs almacenados. Es importante tener un mecanismo que nospermita el almacenamiento seguro de la informaci�on as�� como la renovaci�onde los algoritmos criptogr�a�cos cuando se comprometen.

C.2. Recomendaciones

C.2.1. Autenticaci�on del contribuyente

La autenticaci�on por medio de la llave privada puede ser realizada sincomprometer la llave privada. Una soluci�on simple es la siguiente:

El contribuyente pide una sesi�on segura al SAT, enviando su certi�cadodigital.

El SAT env��a una llave de sesi�on cifrada con la llave p�ublica del con-tribuyente como un reto.

El contribuyente descifra el reto con su llave privada.

El contribuyente autentica en la pagina web del SAT usando la llavede sesi�on.

Estos pasos s�olo requieren que el contribuyente use un programa que le per-mita descifrar el mensaje reto con su llave privada, lo cual puede ser realizadode manera transparente.

C.2.2. Generaci�on de comprobantes �scales digitales

Una autoridad de estampas de tiempo prueba que el documento fue gene-rado en la fecha y hora indicada sin haber sufrido alteraciones. Una autoridadde estampas de tiempo tiene que operar como un servicio con�able de ter-ceras partes.


CriptosistemaNivel de seguridad en bits

SHA-1 (80) 3DES (112) AES (128) AES (192) AES (256)ECC 160 224 256 384 512RSA 1024 2048 3072 8192 15360

Cuadro C.1: Equivalencia de seguridad entre criptograf��a de llave p�ublica ycriptograf��a de llave privada

El protocolo Internet X.509 Public Key Infrastructure Time-Stamp Protocol(TSP) [2] de�ne una autoridad de estampas de tiempo, especi�ca la petici�ondel servicio y la respuesta que debe ser generada, as�� como los errores, losm�etodos de seguridad que se deben de utilizar, las estructuras de los datosy requerimientos de una autoridad certi�cadora. Un servicio de estampas detiempo soporta peticiones de veri�caci�on, que consiste en demostrar que undato existi�o en una fecha y hora determinada. Al utilizar un servidor de es-tampas de tiempo podemos asegurar que el registro contable va a conteneruna fecha y hora que se puedan veri�car con la autoridad de estampas detiempo. si se utiliza este mecanismo evitamos que se pueda falsi�car el tiempodel CFD ya sea de manera maliciosa o accidental.

C.2.3. Otros algoritmos de criptograf��a

Una alternativa para el criptosistema de llave p�ublica RSA es Cripto-esquema de Curvas El��pticas(ECC). ECC ha sido cuidadosamente analizadodurante 20 a~nos y expertos en seguridad creen que ECC puede ofrecer lamisma seguridad que RSA usando tama~nos de llave que son 10 veces menores.Tener menor tama~no en las llaves es una ventaja importante en t�erminosde ejecuci�on y e�ciencia. De manera similar existen varias propuestas parafunciones picadillo, aparte de MD5 y SHA-1, que no han sido comprometidas.

Para cali�car la importancia crucial de seleccionar el conjunto de algorit-mos criptogr�a�cos correctos se muestran las siguientes de�niciones.

Se de�ne el grado de fortaleza de seguridad de un cifrador fuerte de bloquesim�etrico con tama~no de llave n-bit como el poder computacional necesitadopara probar todas las posibles llaves, un ataque tradicionalmente conocidocomo ataque de fuerza bruta.

Se dice que un algoritmo criptogr�a�co de llave p�ublica con tama~no dellave m-bit tiene un equivalente de grado de fortaleza de n-bit, con m > n,

C.2. RECOMENDACIONES 83

si el ataque mejor conocido, requiere un esfuerzo computacional comparablecon el asociado al ataque de fuerza bruta sobre un cifrador sim�etrico fuerte detama~no de llave m-bit. El cuadro C.1 (el cual ha sido adaptado de [8]), mues-tra la equivalencia de seguridad entre dos criptosistemas de llaves p�ublicas,llamadas, RSA(La que se emplea en FIEL y certi�cados) y ECC; en contraun algoritmo de picadillo SHA-1 y dos cifradores sim�etricos llamados, 3DESy AES.

Principalmente por razones de funcionalidad o compatibilidad, algoritmosde diferentes grados de fortaleza y tama~nos de llaves son frecuentemente usa-dos en la misma aplicaci�on. En general, el algoritmo y tama~no de llave m�asd�ebil usado para la protecci�on ciptogr�a�ca determina el grado de fortalezapara toda la protecci�on del sistema. Por ejemplo, si una funci�on picadillopoderosa con 128 bits de grado de fortaleza es combinada con RSA de 1024bits, entonces la seguridad integral del sistema de factura electr�onica ten-dr�a una fortaleza de s�olo 80 bits. Como se muestra en el cuadro C.1 si laaplicaci�on requiere 128 bits de seguridad entonces necesita una llave RSAde 3072 bits. De la misma manera, ECC con 256 bits puede ser usada parasustituir RSA como algoritmo de criptograf��a p�ublica, brindando el mismogrado de fortaleza.

C.2.4. Almacenamiento seguro

Si se tiene la necesidad de certi�car un documento en papel se recurrea un notario el cual da fe de su legalidad. El notario legaliza y guarda unacopia del documento con la �nalidad de probar su autenticidad. Si se requierecerti�car un documento digital se recurre a una autoridad certi�cadora queveri�ca y legaliza la autenticidad de la �rma pero no del documento. Sinembargo,>C�omo garantizar que un comprobante �scal fue emitido en la fecha y horaque tiene marcado?

La respuesta a esta pregunta es realizando la certi�caci�on del compro-bante ante una Notar��a Digital que usa algoritmos criptogr�a�cos validos den-tro de los pr�oximos 10 a~nos a su emisi�on. Por esa raz�on, se propone el uso deherramientas criptogr�a�cas tales como �rmas digitales y estampas de tiempopara crear una Notar��a Digital. Esta autoridad puede certi�car documentosdigitales, especif��camente facturas digitales.�Por �esta raz�on es posible usaruna arquitectura cliente servidor como se muestra en la �gura 5.2. La Notar��aDigital va a almacenar el CFD y su certi�cado digital utilizando la sintaxis


de registro de evidenciaERS [5] y el protocolo de comunicaci�on LTAP [18]de�nido por el grupo de trabajo LTANS [15].

Bibliograf��a

[1] A. Takura and S. Ono and S. Naito. A Secure and Trusted Time Stamp-ing Authority. 1999 Internet Workshop, pages 88{93, 1999.

[2] C. Adams, P. Cain, D. Pinkas, and R. Zuccherato. Internet X.509 PublicKey Infrastructure Time-Stamp Protocol (TSP). RFC 3161, InternetEngineering Task Force (IETF), August 2001.

[3] Asociaci�on Nacional de Notariado Mexicano A.C. Principios fundamen-tales del sistema notariado. http://www.notariadomexicano.org.mx/menu/principios.htm.

[4] B. Kaliski and J. Staddon. PKCS #1: RSA Cryptography Speci�ca-tions Version 2.0. Internet Draft, October 1998. http://www.faqs.

org/rfcs/rfc2437.html.

[5] R. Brandner, U. Pordesch, and T. Gondrom. Evidence Record Syntax(ERS) draft-ietf-ltans-ers-03. Internet Draft, November 2005.

[6] C�amara de Diputados del H. congreso de la Uni�on. C�odigo Fiscal de laFederaci�on, art��culo 30.

[7] C�amara de Diputados del H. congreso de la Uni�on. C�odigo Fiscal de laFederaci�on, art��culo 29, Diciembre 2006.

[8] D. Hankerson and A. Menezes and S. Vanstone. Guide to Elliptic CurveCryptography. Springer, 2003.

[9] Servicio de Administraci�on Tributaria. SAT(M�exico). Internet page.http://www.sat.gob.mx.

[10] Whit�eld Di�e and Martin E. Hellman. New directions in cryptography.IEEE Transactions on Information Theory, IT-22(6):644{654, 1976.

85

86 BIBLIOGRAF�IA

[11] Olivier Dubuisson. ASN.1 Communication Between Heterogeneous Sys-tems. Morgan Kaufmann Publishers, 2000.http://asn1.elibel.tm.fr/en/book/.

[12] S. Haber and W. S. Stornetta. How to Time-Stamp a Digital Document.Journal of Cryptology, 2:99{111, 1991.

[13] R. Housley. Cryptographic Message Syntax (CMS). RFC 3852, InternetEngineering Task Force (IETF), July 2004.

[14] R. Housley, W. Ford, T. Polk, and D. Solo. Internet X.509 Public KeyInfrastructure Certi�cate and Certi�cate Revocation List (CRL) Pro�le.RFC 3280, Internet Engineering Task Force (IETF), April 2002.

[15] Internet Engineer Task Force. Long-Term Archive and Notary Services.http://www.ietf.org/html.charters/ltans-charter.html.

[16] Internet Engineer Task Force. Transport Layer Security (tls). http:

//www.ietf.org/html.charters/tls-charter.html.

[17] Internet Engineer Task Force. Public-Key Infrastructure (X.509) (pkix),1995. http://www.ietf.org/html.charters/pkix-charter.html.

[18] A. Jerman-Blazic and P. Sylvester. Long-Term Archive Protocol (LTAP)Draft-IETF-LTANS-LTAP-00. Internet Draft, September 2005.

[19] R. Kuhn, V. Hu, T. Polk, and S. Chang. Introduction to Public KeyTechnology and the Federal PKI Infrastructure. Technical report, Na-tional Technical Information Service, February 2001.

[20] RSA Laboratories. PKCS #7: Cryptographic Message Syntax Standard.Technical Note PKCS7, RSA Laboratories, November 1993.

[21] RSA Laboratories. PKCS #8: Private-Key Information Syntax Stan-dard. Technical Note PKCS8, RSA Laboratories, November 1993.

[22] RSA Laboratories. PKCS #1 v2.1: RSA Cryptography Standard. Tech-nical Note PKCS1, RSA Laboratories, June 2002.

[23] R. Merkle. Protocols for Public Key Cryptosystems. In Proceedingsof the 1980 IEEE Symposium on Security and Privacy, page 122, April1980.

BIBLIOGRAF�IA 87

[24] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams. X.509Internet Public Key Infrastructure Online Certi�cate Status Protocol -OCSP. RFC 2560, Internet Engineering Task Force (IETF), June 1999.

[25] D. Pinkas, J. Ross, and N. Pope. Electronic Signature Formats for LongTerm Electronic Signatures. RFC 3126, Internet Engineering Task Force(IETF), September 2001.

[26] F. Rodr��guez-Henr��quez, Nazar A. Saqib, A. D��az-P�erez, and C�etinK. Ko�c. Cryptographic Algorithms on Recon�gurable Hardware.Springer, 1st edition, 2007.

[27] K. Schmeh. Cryptography and Public Key Infrastructure on the Internet.John Wiley & Sons, 2003.

[28] B. Schneier. Applied cryptography: protocols, algorithms, and source codein C. Wiley, New York, 2nd edition, 1996.

[29] Secretar��a de Hacienda y Cr�edito P�ublico. Diario O�cial de la Federaci�onde M�exico, anexo 20, 1 de Septiembre 2004.

[30] Secretar��a de Hacienda y Cr�edito P�ublico. Diario O�cial de la Federaci�onde M�exico, regla 2.22.8, 31 de Mayo 2004.

[31] Secretar��a de Hacienda y Cr�edito P�ublico. Diario O�cial de la Federaci�onde M�exico, 28 de Junio al 27 de Diciembre 2006.

[32] Guillermo Mart��nez Silva. Dise~no e implementaci�on de una autoridadcerti�cadora en plataformas m�oviles. Master's thesis, CINVESTAV,2005.

[33] The OpenSSL Project. The open source toolkit for ssl/tls. http://www.openssl.org.

[34] W. Stallings. Cryptography and network security. Prentice Hall, 1998.

[35] C. Wallace, U. Pordesch, and R. Brandner. Long-Term Archive ServiceRequirements draft-ietf-ltans-reqs-05. Internet Draft, November 2005.

[36] C. Wallace, U. Pordesch, and R. Brandner. Long-Term Archive Ser-vice Requirements. RFC 4810, Internet Engineering Task Force (IETF),March 2007.

Laboratorio Nacional de Informatica Avanzada Centro de...

Documents

Transcript of Laboratorio Nacional de Informatica Avanzada Centro de...