Your SlideShare is downloading. ×

Tesis rodrigojurado

484

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
484
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. ´ CENTRO DE INVESTIGACION Y DE ESTUDIOS AVANZADOS ´ DEL INSTITUTO POLITECNICO NACIONAL Unidad Zacatenco Departamento de Computaci´n o “An´lisis y dise˜ o de una aplicaci´n segura de a n o facturaci´n electr´nica para dispositivos m´viles” o o o Tesis que presenta Rodrigo Jurado Barrera para obtener el Grado de Maestro en Ciencias en Computaci´n o Directores de Tesis Dr. Adriano de Luca Pennacchia Dr. Mois´s Salinas Rosales e M´xico, D.F. e Febrero 2012
  • 2. ii
  • 3. Resumen El uso de facturaci´n electr´nica en M´xico se ha extendido en los ultimos a˜os o o e ´ n desde su implantaci´n en el 2004. El Sistema Tributario Mexicano (SAT) ha ino cluido ciertos mecanismos criptogr´ficos para verificar la legitimidad de una factura a electr´nica. Sin embargo, el uso de estos mecanismos no resuelven todos los problemas o de seguridad en el desarrollo de una sistema de facturaci´n electr´nica. El desarroo o llo de una aplicaci´n segura, implica el uso de practicas, procesos, herramientas y o t´cnicas que aborden los problemas de seguridad en cada fase del ciclo de vida de e desarrollo de software. En este trabajo se abordar´n los problemas asociados a los riesgos de seguridad a que pueda presentar una aplicaci´n de facturaci´n electr´nica para ambientes m´vio o o o les, y presentar as´ una propuesta para aminorar los riesgos de seguridad que conlleve ı desarrollar una aplicaci´n de esta ´ o ındole. Tambi´n se propondr´ el dise˜o e implee a n mentaci´n segura de un esquema de facturaci´n electr´nica para generar facturas o o o electr´nicas para dispositivos m´viles. Como parte del an´lisis se hace la descripci´n o o a o de los requerimientos de este tipo de aplicaciones, agregando a esta etapa procesos para la obtenci´n y especifici´n de los requerimientos de seguridad. Una vez obtenidos o o estos requerimientos se realiza la descripci´n del dise˜o presentando una propuesta o n de una arquitectura que incluye el modelado de componentes de seguridad por medio de la herramienta UMLSec. Por ultimo se muestra la implementaci´n de la aplicaci´n ´ o o explicando la descripci´n de los componentes de seguridad que se desarrollaron. o iii
  • 4. iv RESUMEN
  • 5. Abstract The use of electronic invoice in Mexico has spread in the last years since its introduction in 2004. The Mexican Tributary System (SAT) has included some cryptographic mechanism to verify the legitimacy of an electronic invoice. However, the use of these mechanisms do not solve all security issues in the development of an electronic invoice application. In order to make an application secure, the security analysis has to be an integral part of the system development process. The development of a secure application entails using practices, processes, tools, and techniques to address issues in every phase of the software development cycle. In this work, we address the problems associated with security risks that may be present in an electronic invoice application for mobile environments, and show a proposal to lessen the security risks that entail the development of an application of this nature. Also it will be proposed the design and implementation of a secure electronic invoice scheme that generate electronic invoices for mobile devices. As part of the analysis, it is made a description of the requirements of these kind of applications adding to this phase, processes for eliciting and specifying the security requirements. Once obtained these requirements it is performed the design description which presents a proposal for an architecture that includes the modeling of security components through UMLsec.Finally, it is presented the implementation of the application stating the description of the security components that were developed. v
  • 6. vi ABSTRACT
  • 7. Agradecimientos Agradezco al CINVESTAV, ya que durante este tiempo curse materias que me apasionaron y pude ampliar mi percepci´n sobre las Ciencias de la Computaci´n. o o Agradezco al CONACYT, por el apoyo econ´mico proporcionado a trav´s de su o e programa de becas durante mi estancia en el Departamento de Computaci´n del o CINVESTAV. Un sincero agradecimiento a mis directores de tesis, el Dr. Adriano de Luca Pennacchia y el Dr. Mois´s Salinas Rosales por todo la ayuda y el apoyo que me fueron e brindados durante la realizaci´n de este trabajo. o A Sofia Reza y a todo el personal secretarial por todo el apoyo brindado durante mi estancia en el Departamento de Computaci´n. o Agradezco infinitamente a mi madre y abuelos por todo su apoyo, orientaci´n, o comprensi´n, amor y por estar en cada momento que los he necesitado. Sin olvidarme o por supuesto de mi hermano y mi tio Octavio, quienes fueron parte importante en esta meta. Agradezco a todos mis amigos de la maestr´ por su apoyo cuando este fue requeıa rido, adem´s por brindarme su compa˜ia creando incontables momentos de diversi´n a n o y varios buenos recuerdos. A mis amigos y familiares por toda la confianza que depositaron en mi y me hayan alentado para llevar a cabo esta meta. Por utimo, quiero hacer expresa mi gratitud de forma especial a todas las personas ´ que jam´s dudaron de m´ y que incondicionalmente brindaron su apoyo a´n en las a ı, u situaciones m´s dif´ a ıciles. vii
  • 8. viii AGRADECIMIENTOS
  • 9. ´ Indice general Resumen III Abstract V Agradecimientos VII ´ Indice de figuras IX ´ Indice de tablas XI 1. Dise˜ o de la investigaci´n n o 1 1.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2. Problema y propuesta de soluci´n . . . . . . . . . . . . . . . . . . . . o 2 1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4. Justificaci´n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 4 1.5. Metodolog´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ıa 4 1.6. Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.6.1. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.6.2. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.7. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Facturaci´n Electr´nica en M´xico o o e 7 2.1. Comprobantes Fiscales Digitales . . . . . . . . . . . . . . . . . . . . . 7 2.1.1. Definici´n Normativa . . . . . . . . . . . . . . . . . . . . . . . o 8 2.1.2. Arquitectura de un Comprobante Fiscal Digital . . . . . . . . 8 2.2. Herramientas T´cnologicas asociadas a los Comprobantes Fiscales Die gitales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 ix
  • 10. ´ INDICE GENERAL x 2.2.1. Criptograf´ . . . . . . . . . . . . . . . . . . . . . . . . . . . . ıa 11 2.2.2. Criptografi´ de llave secreta . . . . . . . . . . . . . . . . . . . a 11 2.2.3. Criptograf´ de llave p´blica . . . . . . . . . . . . . . . . . . . ıa u 12 2.2.4. Funciones Picadillo . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2.5. Firma Electr´nica . . . . . . . . . . . . . . . . . . . . . . . . . o 14 2.2.6. Infraestructura de llave p´blica (PKI) . . . . . . . . . . . . . . u 15 2.2.7. Certificados Digitales . . . . . . . . . . . . . . . . . . . . . . . 17 2.3. Plataforma tecnol´gica de la factura electr´nica en M´xico . . . . . . o o e 17 2.3.1. Generaci´n de la Firma Electr´nica Avanzada (FIEL) y cerfifio o cado de firma electr´nica . . . . . . . . . . . . . . . . . . . . o 18 2.3.2. Certificados de Sello Digital (CSD) . . . . . . . . . . . . . . . 18 2.3.3. Folios Digitales . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.3.4. Modelo Operativo . . . . . . . . . . . . . . . . . . . . . . . . . 19 3. Desarrollo de Software Seguro 21 3.1. Metodolog´ de Desarrollo de Software . . . . . . . . . . . . . . . . . ıas 21 3.1.1. Modelo en cascada . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.2. Modelo en prototipado . . . . . . . . . . . . . . . . . . . . . . 21 3.1.3. Modelo en espiral . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.1.4. Proceso de Unificado de Rational . . . . . . . . . . . . . . . . 22 3.1.5. Desarrollo ´gil de software . . . . . . . . . . . . . . . . . . . . a 22 3.1.6. Capability Maturity Model Integration . . . . . . . . . . . . . 23 3.2. Desarrollo de Software Seguro . . . . . . . . . . . . . . . . . . . . . . 23 3.2.1. Ciclo de vida de Software Seguro . . . . . . . . . . . . . . . . 23 3.2.2. Ciclo de vida de Desarrollo Confiable de Microsoft . . . . . . . 24 3.2.3. Ciclo de vida de seguridad mejorado de McGraw . . . . . . . . 25 3.3. Herramientas de desarrollo seguro . . . . . . . . . . . . . . . . . . . . 26 3.3.1. SQUARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.3.2. STRIDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.3.3. UMLSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.4. T´cnicas de Codificaci´n Segura . . . . . . . . . . . . . . . . . e o 29 3.3.5. Herramientas de An´lisis de c´digo est´tico . . . . . . . . . . a o a 30 3.3.6. Pr´cticas de codificaci´n . . . . . . . . . . . . . . . . . . . . . a o 30 3.4. Pruebas de seguridad de software . . . . . . . . . . . . . . . . . . . . 30
  • 11. ´ INDICE GENERAL xi 4. An´lisis y dise˜ o de un sistema seguro de facturaci´n electr´nica a n o o 33 4.1. An´lisis de Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . a 33 4.1.1. Perspectiva del producto . . . . . . . . . . . . . . . . . . . . . 33 4.1.2. Funciones del producto . . . . . . . . . . . . . . . . . . . . . . 33 4.1.3. Caracter´ ısticas del usuario . . . . . . . . . . . . . . . . . . . . 34 4.1.4. Suposiciones y dependencias . . . . . . . . . . . . . . . . . . . 34 4.1.5. Requerimientos Funcionales . . . . . . . . . . . . . . . . . . . 34 4.1.6. Requerimientos no funcionales . . . . . . . . . . . . . . . . . . 37 4.2. Requerimientos de Seguridad con SQUARE . . . . . . . . . . . . . . 38 4.2.1. Consenso sobre los conceptos y su definici´n. . . . . . . . . . . o 38 4.2.2. Identificaci´n de metas de seguridad . . . . . . . . . . . . . . o 39 4.2.3. Obtenci´n y priorizaci´n de los requerimientos de seguridad . o o 40 4.2.4. Resultados de la metodolog´ SQUARE Lite . . . . . . . . . . ıa 48 4.3. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.3.1. Criterios de dise˜o . . . . . . . . . . . . . . . . . . . . . . . . n 51 4.3.2. An´lisis del dise˜o . . . . . . . . . . . . . . . . . . . . . . . . a n 52 4.3.3. Arquitectura de seguridad . . . . . . . . . . . . . . . . . . . . 57 5. Implementaci´n y pruebas o 65 5.1. Codificaci´n Segura . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 65 5.1.1. Revisi´n de c´digo . . . . . . . . . . . . . . . . . . . . . . . . o o 66 5.2. Implementaci´n de componentes de seguridad . . . . . . . . . . . . . o 68 5.2.1. Control de acceso . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.2.2. Canal Confiable . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.2.3. Contenedor Seguro . . . . . . . . . . . . . . . . . . . . . . . . 72 5.2.4. Autoprueba del sistema . . . . . . . . . . . . . . . . . . . . . 76 5.2.5. Firma electr´nica . . . . . . . . . . . . . . . . . . . . . . . . . o 77 5.2.6. Bloqueo de la aplicaci´n . . . . . . . . . . . . . . . . . . . . . o 78 5.3. Pruebas de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 5.3.1. Pruebas funcionales . . . . . . . . . . . . . . . . . . . . . . . . 80 5.3.2. Pruebas de penetraci´n . . . . . . . . . . . . . . . . . . . . . . o 81
  • 12. ´ INDICE GENERAL xii 6. Conclusiones y trabajo a futuro 87 6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 6.2. Trabajo a futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 A. Definiciones de seguridad 89 B. Identificaci´n de metas de seguridad o 93 B.1. Confidencialidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 B.2. Disponibilidad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 B.3. Integridad de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 B.4. Seguimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 C. Casos de uso 95 D. Casos de maluso 107 E. Arboles de ataque 119 Bibliograf´ ıa 122
  • 13. ´ Indice de figuras 2.1. Elementos de un Comprobante Fiscal Digital . . . . . . . . . . . . . . 10 2.2. Esquema de criptogr´ de llave privada . . . . . . . . . . . . . . . . . ıa 12 2.3. Esquema de criptogr´ de llave p´blica . . . . . . . . . . . . . . . . . ıa u 13 2.4. Esquema de firma digital . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.5. Modelo operativo de la Facturaci´n Electr´nica . . . . . . . . . . . . o o 20 3.1. Ciclo de vida de seguridad de McGraw y Taylor . . . . . . . . . . . . 26 4.1. Modelo operativo de la Facturaci´n Electr´nica . . . . . . . . . . . . o o 45 4.2. C´lculo de impacto . . . . . . . . . . . . . . . . . . . . . . . . . . . . a 47 4.3. Arquitectura en capas . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.4. Diagrama de relaci´n entre Activity, View, recursos y manifesto . . . o 52 4.5. Ejemplo de dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.6. Ejemplo de barra de accion . . . . . . . . . . . . . . . . . . . . . . . 54 4.7. Ejemplo de barra de busqueda . . . . . . . . . . . . . . . . . . . . . . 54 4.8. Patr´n fachada para cfd . . . . . . . . . . . . . . . . . . . . . . . . . o 55 4.9. Diagrama de secuencia: persistencia de datos . . . . . . . . . . . . . . 56 4.10. Patr´n de persistencia DAO . . . . . . . . . . . . . . . . . . . . . . . o 57 4.11. Componentes de seguridad . . . . . . . . . . . . . . . . . . . . . . . . 58 4.12. Subsistema de comunicaciones . . . . . . . . . . . . . . . . . . . . . . 59 4.13. Diagrama de Secuencia: control de acceso . . . . . . . . . . . . . . . . 60 4.14. Diagrama de Clases: control de acceso . . . . . . . . . . . . . . . . . . 61 4.15. Diagrama de secuencia: contenedor seguro . . . . . . . . . . . . . . . 62 4.16. Diagrama de clase: contenedor seguro . . . . . . . . . . . . . . . . . . 62 4.17. Diagrama de clase: Autoprueba . . . . . . . . . . . . . . . . . . . . . 63 xiii
  • 14. xiv ´ INDICE DE FIGURAS 4.18. Diagrama de clase: Firma electr´nica . . . . . . . . . . . . . . . . . . o 64 4.19. Diagrama de clase: Bloquear aplicaci´n . . . . . . . . . . . . . . . . . o 64 5.1. Errores encontrado por FindBugs . . . . . . . . . . . . . . . . . . . . 67 5.2. Revisi´n de c´digo FindBugs . . . . . . . . . . . . . . . . . . . . . . . o o 67 5.3. SSL/TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.4. Mecanismo PBE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.5. Falla de autoprueba del sistema . . . . . . . . . . . . . . . . . . . . . 76 5.6. Bloqueo de la aplicaci´n . . . . . . . . . . . . . . . . . . . . . . . . . o 79 5.7. Diagrama de estado: Bloqueo de la aplicaci´n . . . . . . . . . . . . . o 80 5.8. Visualizaci´n de nuestra contrase˜a de usuario . . . . . . . . . . . . . o n 83 5.9. Visualizaci´n de nuestra llave del contenedor seguro . . . . . . . . . . o 83 5.10. Busqueda de peticiones https con wireshark . . . . . . . . . . . . . . 84 5.11. Busqueda de peticiones http con wireshark . . . . . . . . . . . . . . . 84 ´ E.1. Arbol de ataque: crear factura . . . . . . . . . . . . . . . . . . . . . . 120 ´ E.2. Arbol de ataque: Modificar/Eliminar CFD . . . . . . . . . . . . . . . 120 ´ E.3. Arbol de ataque: Modificar/Eliminar datos . . . . . . . . . . . . . . . 121
  • 15. ´ Indice de cuadros 4.1. Metodolog´ SQUARE-Lite . . . . . . . . . . . . . . . . . . . . . . . ıa 39 4.4. Generaci´n de factura electr´nica . . . . . . . . . . . . . . . . . . . . o o 43 4.5. Caso del Mal Uso MC-01 . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.6. Priorizaci´n de los casos de abuso . . . . . . . . . . . . . . . . . . . . o 46 4.7. Estimaci´n de riesgo . . . . . . . . . . . . . . . . . . . . . . . . . . . o 47 4.8. Acciones del adversario . . . . . . . . . . . . . . . . . . . . . . . . . . 59 C.1. Caso de Uso CU-01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 C.2. Caso de Uso CU-02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 C.5. Caso de Uso CU-03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 C.6. Caso de Uso CU-04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 C.7. Caso de Uso CU-05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 C.8. Caso de Uso CU-06 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 C.9. Caso de Uso CU-07 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 C.10.Caso de Uso CU-08 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 C.11.Caso de Uso CU-09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 C.12.Caso de Uso CU-10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 D.2. Caso del Mal Uso MC-01 . . . . . . . . . . . . . . . . . . . . . . . . . 108 D.3. Caso del Mal Uso MC-02 . . . . . . . . . . . . . . . . . . . . . . . . . 108 D.4. Caso del Mal Uso MC-03 . . . . . . . . . . . . . . . . . . . . . . . . . 109 D.5. Caso del Mal Uso MC-04 . . . . . . . . . . . . . . . . . . . . . . . . . 110 D.6. Caso del Mal Uso MC-05 . . . . . . . . . . . . . . . . . . . . . . . . . 111 D.7. Caso del Mal Uso MC-06 . . . . . . . . . . . . . . . . . . . . . . . . . 112 D.8. Caso del Mal Uso MC-08 . . . . . . . . . . . . . . . . . . . . . . . . . 114 xv
  • 16. xvi ´ INDICE DE CUADROS D.9. Caso del Mal Uso MC-09 . . . . . . . . . . . . . . . . . . . . . . . . . 115 D.10.Caso del Mal Uso MC-10 . . . . . . . . . . . . . . . . . . . . . . . . . 116 D.11.Caso del Mal Uso MC-11 . . . . . . . . . . . . . . . . . . . . . . . . . 117
  • 17. Cap´ ıtulo 1 Dise˜ o de la investigaci´n n o Este cap´ ıtulo se dedica a explicar el marco metodol´gico desde donde se aborda o el contexto de este trabajo. Se hace una descripci´n del problema, el objetivo y la o formulaci´n general de la metodolog´ que se llevar´ acabo para resolver el problema o ıa a planteado. 1.1. Antecedentes El gobierno electr´nico o e-gobierno es un concepto que incluye el uso de tecnoo log´ de la informaci´n para proporcionar a los ciudadanos facilidad en procesos de ıas o gesti´n p´blica y as´ aumentar la eficiencia de los servicios p´blicos reduciendo costos o u ı u en consulta de informaci´n, tr´mites y servicios burocr´ticos. o a a En M´xico a nivel Federal y Estatal se est´ participando activamente en impore a tantes esfuerzos de iniciativas de e-gobierno para integrar soluciones de tecnolog´ ıa que ayuden a sustituir funciones tradicionales para as´ facilitar las operaciones de los ı gobiernos con el uso de tecnolog´ de la informaci´n. Como parte de estas iniciativas ıas o en el a˜o 2004 el Servicio de Administraci´n Tributaria (SAT) propuso un esquema n o de masificaci´n para la emisi´n de Comprobantes Fiscales Digitales[2] (CFD) en su o o formato de factura electr´nica que permite otorgar un medio de respaldo de las operao ciones comerciales que realiza los contribuyentes y as´ remplazar las facturas de papel ı que se utilizan en la actual normativa. Contar con documentos digitales de este estilo tiene muchos beneficios entre los que se encuentran: agilizan la informaci´n contable, o almacenamiento en formato digital, as´ como la reducci´n de costos y errores en el ı o proceso de generaci´n captura, entrega y almacenamiento. o Sin embargo debido a la aparici´n de este tipo de documentos digitales existe la o obligaci´n de replantearse muchas cuestiones de los documentos tradicionales en pao pel, surgiendo nuevos problemas, e incluso agudizando algunos de los ya existentes. En esta lista de problemas, se plantean cuestiones que van, desde la validez legal de los documentos digitales, la alteraci´n de la informaci´n contenida en estos o que la o o 1
  • 18. 2 Cap´ ıtulo 1 informaci´n sea comprometida. Debido a esto el SAT ha incorporado mecanismos pao ra certificar e identificar de manera leg´ ıtima el autor[2] de un CFD, a este mecanismo se le conoce como firma digital que es tratada tal y como si fuese la firma aut´grafa. o Sin embargo, la firma digital por s´ misma es susceptible a varios ataques como lo ı son ataques de repetici´n, usurpaci´n de identidad o ataques de hombre en el medio. o o Es por esta raz´n que el SAT incorpora el uso de esta´dar X.509 de PKI (Infraeso n tructura de Llave P´blica [8]) el cu´l nos ayuda a evitar los ataques anteriormente u a mencionados. La infraestructura de llave p´blica (PKI) es un conjunto de hardware, software, u pol´ ıticas y procedimientos necesarios para crear, manejar, distribuir y revocar certificados digitales basados en criptograf´ asim´trica [27] . El principal objetivo por el ıa e cu´l se desarroll´ el concepto de PKI es para habilitar la adquisici´n de llaves p´blicas a o o u de manera segura, conveniente y eficiente. A pesar de que el SAT incorpor´ el uso de estas herramientas criptogr´ficas en el a a esquema de facturaci´n electr´nica, est´s herramientas s´lo resuelven ciertos probleo o a o mas de seguridad. El dise˜o de un sistema que involucre los componentes de seguridad n anteriormente mencionados a´n incorporando estas herramientas puede ser suscepu tible a diversos ataques que comprometan la funcionalidad del mismo. El desarrollo de este tipo de sistemas de seguridad resulta ser una tarea dif´ ya que muchos son ıcil dise˜ados e implementados sin satisfacer los requisitos de seguridad y esto trae como n consecuencia ataques y vulnerabilidades en el sistema. 1.2. Problema y propuesta de soluci´n o Las aplicaciones que prestan servicios a trav´s de dispositivos m´viles se han ine o crementado debido a la creciente proliferaci´n de tecnolog´ de c´mputo. Con la o ıas o generalizaci´n de algunos servicios m´viles, como el pago por m´vil o la banca m´vil o o o o es necesario proporcionar mecanismos que nos permitan proteger informaci´n cr´ o ıtica en este tipo de aplicaciones. El uso de aplicaciones m´viles conlleva riesgos cr´ o ıticos de seguridad en la informaci´n la cu´l es particularmente importante para los sisteo a mas m´viles, debido a la vulnerabilidad inherente de estos dispositivos. Para hacer o frente a estos riesgos y permitir que la aplicaci´n tenga el menor n´mero de fallos de o u seguridad, analizar y modelar las amenazas potenciales que enfrenta una aplicaci´n o es un paso importante en el proceso de una aplicaci´n segura. El proceso de an´lisis o a y modelado de aplicaciones trata de identificar cada uno de los problemas de seguridad relacionados al sistema: c´digo, l´gica del programa, flujo de informaci´n, datos, o o o permisos de usuario y autenticaci´n. Este proceso de an´lisis debe ser incorporado o a desde etapas tempranas de desarrollo e irse refinando en etapas posteriores. Por esta raz´n, tiene sentido identificar y documentar amenazas en tecnolog´ o aplicaciones o ıas espec´ ıficas y as´ proporcionar directrices a proveedores de software de como mitigar ı los riesgos de seguridad. CINVESTAV Departamento de Computaci´n o
  • 19. Dise˜o de la investigaci´n 3 n o Por otra parte con el advenimiento de servicios digitales se est´ tratando realizar a la migraci´n de documentos de car´cter legal a su forma digital por esta raz´n existe o a o la necesidad de implementar ciertas t´cnicas para garantizar la legalidad de estos y e proporcionar la mismas caracter´ ısticas intr´ ınsecas que su contraparte en papel. Este trabajo de maestr´ abordar´ por una parte, los problemas asociados a los ıa a riesgos de seguridad que pueda presentar una aplicaci´n de facturaci´n electr´nica pao o o ra ambientes m´viles, y presentar as´ una propuesta para aminorar los riesgos de seguo ı ridad que implica desarrollar una aplicaci´n de esta ´ o ındole. Tambi´n se propondr´ el e a desarrollo e implementaci´n segura de un esquema de facturaci´n electr´nica para o o o generar facturas electr´nicas para dispositivos m´viles. o o 1.3. Objetivos General Elaborar el an´lisis, dise˜o e implementaci´n de un prototipo de un sistema que a n o genere comprobantes fiscales electr´nicos en su modalidad de factura electr´nica aproo o vechando la tecnolog´ de los dispositivos m´viles para la automatizaci´n del proceso ıa o o contable para el pago de impuestos de personas f´ ısicas y morales, utilizando metodolog´ de modelado seguro de aplicaciones. ıas Particulares 1. Realizar un an´lisis de requerimientos de seguridad utilizando la metodoloa gi´ SQUARE para una aplicaci´n de facturaci´n electr´nica. a o o o 2. Realizar una propuesta basada en los requerimientos de seguridad que aminore los riesgos de seguridad en una aplicaci´n de facturaci´n electr´nica en disposio o o tivos m´viles. o 3. Dise˜ar una arquitectura robusta para ambientes m´viles que realice facturaci´n n o o electr´nica utilizando la herramienta de modelado UMLSec. o 4. Implementar componentes para la arquitectura propuesta de facturaci´n electr´nio o ca para ambientes m´viles. La aplicaci´n ser´ capaz de generar comprobantes o o a fiscales digitales en su modalidad de factura electr´nica. o 5. Realizar pruebas de seguridad y valorar resultados del producto obtenido. CINVESTAV Departamento de Computaci´n o
  • 20. 4 Cap´ ıtulo 1 1.4. Justificaci´n o La masificaci´n en el uso de t´lefonos m´viles inteligentes y el aumento consideo e o rable en su poder de c´mputo ha dado lugar al desarrollo de aplicaciones m´viles o o ˜ o nmente son utilizadas en una computadora avanzadas. Las aplicaciones que comA de escritorio est´n siendo migradas a sus versiones m´viles. Estas aplicaciones van a o desde verificar el correo electr´nico hasta aplicaciones m´s avanzadas de comercio o a electr´nico. o Un problema grave dentro de estas aplicaciones m´viles es que existe la posibilidad o de poder acceder a datos confidenciales tales como informaci´n personal o datos de o negocio. Es por est´ raz´n que para desarrollar aplicaciones m´viles seguras es necesaa o o rio el incorporar el uso de nuevas pr´cticas adoptando nuevas t´cnicas y metodolog´ a e ıas en el ciclo de desarrollo convencional. Por otra parte, cada aplicaci´n m´vil requiere distintos servicios de seguridad o o y tomando esto en cuenta resulta interesante incorporar el uso de metodolog´ de ıas desarrollo seguro en el desarrollo de una aplicaci´n de facturaci´n electr´nica, ya que o o o puede estar expuesta a ataques como lo son: suplantaci´n de identidad, elevaci´n de o o privilegios, repudiaci´n de la informaci´n, entre otros. o o 1.5. Metodolog´ ıa Para facilitar la tarea del an´lisis y dise˜o de aplicaciones seguras existen metoa n dolog´ que facilitan el modelado de componentes cr´ ıas ıticos y amenazas que puedan presentarse en un sistema de informaci´n con el fin de mitigar en medida de lo posible o dichas amenazas. Para el modelado de procesos de amenazas en el desarrollo de esta tesis se integrar´n al ciclo de vida de convencional las siguientes fases de seguridad: a 1. Recolecci´n de Requerimientos de Seguridad: Se har´ identificaci´n de o a o especificaciones formales de requerimientos y se hace una priorizaci´n de los obo jetivos de seguridad de la aplicaci´n, valorando y clasificando riesgos utilzando o la metodolog´ SQUARE. ıa 2. Aseguramiento del Dise˜ o: Se especificar´ como ser´ el manejo de las piezas n a a de datos y de material criptogr´fico.A trav´s de t´cnicas de modelado seguro a e e como UMLSec donde se har´ una especificaci´n de dise˜o de los componentes a o n de seguridad. 3. An´lisis a nivel implementaci´n: Se har´ un revisi´n del c´digo en busa o a o o ca de fallas de implementaci´n, convenciones de seguridad y se har´ uso de o a herramientas de an´lisis est´tico. a a CINVESTAV Departamento de Computaci´n o
  • 21. Dise˜o de la investigaci´n 5 n o 4. Pruebas de seguridad: Se har´n pruebas espec´ a ıficas para encontrar efectos colaterales en la aplicaci´n. Estas pruebas consisten en realizar pruebas funcioo nales y de penetraci´n o 1.6. Recursos Para la realizaci´n de este proyecto se consideraron el uso de las siguientes herrao mientas: 1.6.1. Software Sistema operativo Android Android es un sistema operativo nacido de la alianza de 30 organizaciones del sector de los dispositivos m´viles, como fabricantes de hardware, operadores y emo presas de software, comprometidos a ofrecer un mejor tel´fono m´vil al mercado. El e o resultado es un sistema operativo y entorno de desarrollo de aplicaciones libre capaz de ejecutarse en distintos dispositivos. Android esta basado en el kernel de Linux y t´ ıpicamente es programado con el lenguaje de programac´n Java, lo que reduce la o curva de aprendizaje y proporciona la facilidad y la seguridad del desarrollo de este lenguaje. As´ mismo Android proporciona un conjunto de herramientas de abstracci´n ı o variadas como lo son: interfaces de usuario, ciclo de vida de la aplicaci´n, mecanismos o de control entre procesos (IPC), y permisos. Herramientas de desarrollo Para la programaci´n de aplicaciones sobre la plataforma Android es necesario el o uso del SDK (Software Development Kit) de Android. El SDK ofrece herramientas para desarrollar y depurar aplicaciones incluyendo soporte para desarrollos en Linux, Windows y OSX. El SDK cuenta con un emulador bastante vers´til que emula un a dispositivo basado en ARM similar a un T-Mobile G1, aunque los par´metros de a configuraci´n de hardware virtual pueden ser modificados. El c´digo que se desarrolla o o en la SDK se ejecuta sobre m´quina virtual Dalvik y es posible depurar el c´digo a o ya sea en el emulador o en un dispositivo f´ ısico. Para el desarrollo de aplicaciones sobre la plataforma Android puede ocuparse cualquier entorno de programaci´n sin o embargo para la realizaci´n de este proyecto y debido a su integraci´n con el SDK de o o Android se ha optado por la utilizaci´n de Eclipse. o CINVESTAV Departamento de Computaci´n o
  • 22. 6 Cap´ ıtulo 1 Software Adicional Adicionalmente para el desarrollo de este trabajo se utilizaron las siguientes herramientas de software: Servidor Tomcat Apache 6.0 Herramientas para an´lisis de c´digo est´tico a o a 1.6.2. Hardware Para comprobar la funcionalidad de nuestro sistema se utiliz´ las siguientes tero minales de c´mputo: o Terminal M´vil o La terminal m´vil utilizada como terminal de desarrollo fue un LG-OptimusOne o (LG-p500h). El cu´l tiene las siguiente carater´ a ısticas: Sistema Operativo Android 2.2 Procesador de 600 MHz 512 MB en RAM Terminal Servidor Para realizar ciertas funciones de sincronizaci´n de datos se utiliz´ una terminal o o con las siguientes caracter´ ısticas: Sistema Operativo GNU-Linux kernel 2.6 Procesador Intel Core Duo de 2 GHz 2GB en RAM 1.7. Alcance El sistema Generador de comprobantes fiscales digitales m´vil est´ dise˜ado para o a n ser utilizado por aquellos peque˜os puntos de venta que no cuenten con la infraestrucn tura para poder montar un sistema de facturaci´n a gran escala. Por otra parte, el o desarrollo del sistema ser´ a trav´s de software libre, se podr´ contar con la memoria a e a de dise˜o del software el cu´l utiliz´ t´cnicas y herramientas de modelado seguro lo n a o e cual enriquece a la aplicaci´n ya que aminorar´ los riesgos que se puedan presentar o a una aplicaci´n de este tipo. o CINVESTAV Departamento de Computaci´n o
  • 23. Cap´ ıtulo 2 Facturaci´n Electr´nica en M´xico o o e En este cap´ ıtulo se abordar´n las nociones b´sicas sobre las cu´les se fundamenta a a a la facturaci´n electr´nica, as´ como las herramientas t´cnologicas que son utilizadas o o ı e para garantizar la integridad, autencidad y no repudio de este tipo de documentos. Una vez introducidos estos conceptos se explicar´ como el Servicio de Administraci´n a o Tributaria (SAT) implementa estos elementos en una plataforma tecnol´gica para auo tomatizar el proceso contable para el pago de impuestos de personas f´ ısicas y morales en M´xico. e 2.1. Comprobantes Fiscales Digitales Un Comprobante Fiscal Digital es un mecanismo alternativo de comprobaci´n o de ingresos, egresos y propiedad de mercanc´ en traslado por medios electr´nicos. ıas o Maneja est´ndares de seguridad internacionalmente reconocidos, que garantizan que a el comprobante es aut´ntico, ´ e ıntegro, unico y que es aceptado igual que el comprobante ´ fiscal impreso [5]. Un Comprobante Fiscal Digital puede ser extensible a los siguientes tipos de comprobantes fiscales: Factura Electr´nica o Nota de Cr´dito e Nota de Cargo Recibo de Honorarios Recibo de Arrendamiento Carta Porte Recibo de donativo 7
  • 24. 8 Cap´ ıtulo 2 Para la realizaci´n de esta tesis se tomar´ como caso de estudio el uso de el o a comprobante fiscal digital en su formato factura electr´nica. En la siguiente secci´n o o se explicar´ de manera breve el marco jur´ a ıdico sobre el cu´l se regula este tipo de a documentos. 2.1.1. Definici´n Normativa o Una factura electr´nica es la representaci´n digital de un tipo de Comprobante o o Fiscal Digital (CFD), que est´ apegada a los est´ndares definidos por el SAT en a a el Anexo 20 de la Resoluci´n de Miscel´nea Fiscal, y la cual puede ser generada, o a transmitida y resguardada utilizando medios electr´nicos. Cada factura electr´nica o o emitida cuenta con un sello digital a trav´s de la Firma Electr´nica Avanzada (FIEL) e o que corrobora su origen y le da validez ante el SAT, una cadena original que funciona como un resumen del contenido de la factura, y un folio que indica el n´mero de u la transacci´n. La factura electr´nica est´ regulada por los siguientes reglamentos y o o a estatutos: Anexo 20 de la Miscel´nea Fiscal, publicada en el Diario Oficial de la Federaci´n a o junio 11, 2010. Art. 29 en el C´digo Fiscal de la Federaci´n, publicado en el Diario Oficial de o o la Federaci´n el 07 de diciembre de 2009. o Resoluci´n Miscel´nea Fiscal del 2010. o a 2.1.2. Arquitectura de un Comprobante Fiscal Digital Un comprobante fiscal digital debe de cumplir con los requisitos en el C´digo Fiscal o de la Federaci´n as´ como las reglas de la Resoluci´n Miscel´nea Fiscal y deber´ de o ı o a a contar al menos con los siguientes datos: Datos del Emisor: raz´n social, domicilio fiscal y RFC (Registro Federal de o Contribuyentes). Folio y en su caso serie. Lugar y fecha de expedici´n. La fecha deber´ incluir la hora minuto y segundo o a en el siguiente formato: aaaa-mm-ddThh:mm:ss Datos del Receptor: RFC, en caso de ser un Comprobante Fiscal Digital global que amparen operaciones efectuadas de p´blico en general se deber´ utilizar el u a RFC gen´rico (XAXX010101000). e Descripci´n de la mercanc´ y unidad de medida. o ıa CINVESTAV Departamento de Computaci´n o
  • 25. Facturaci´n Electr´nica en M´xico 9 o o e Valor unitario, importe total y monto de los impuestos. La cadena original con la que se gener´ el sello digital. o Sello digital correspondiente al comprobante fiscal digital. N´mero de serie del certificado de sello digital. u Leyenda. N´mero y a˜o de aprobaci´n de los folios. u n o Cadena Original y Sello Digital: Se entiende como Cadena Original a la secuencia de datos formada con la informaci´n fiscal contenida dentro de cualquier o Comprobante Fiscal Digital, la cual debe ser generada bajo las especificaciones establecidas por el SAT en el Rubro C de su Anexo 20. Se entiende como Sello Digital al conjunto de datos asociados al emisor y a los datos del documento por lo tanto es unico e irrepetible por documento. Es el elemento de seguridad en una factura ya ´ que a trav´s de ´ste se puede detectar: si un mensaje ha sido alterado (integridad), e e determinar qui´n es el autor del documento (certidumbre de origen) y capacidad de e impedir que el autor del sello digital niegue haber sellado el mensaje (no repudio). Ambos elementos deber´n estar presentes en la representaci´n impresa de la factura a o electr´nica. o Leyenda: Todas las facturas electr´nicas que sean impresas deber´n portar la leo a yenda: “Este documento es una impres´n de un comprobante fiscal digital”. o En la figura 2.1 se muestra un ejemplo de una versi´n impresa de un Comproo bante Fiscal Digital en su formato factura electr´nica presentando sus componentes o principales: 1. Informaci´n del cliente o 2. Certificado, n´mero de aprobaci´n y a˜o de aprobaci´n u o n o 3. Serie, folio, fecha y hora de emisi´n o 4. Sello digital 5. Cadena original 6. Leyenda CINVESTAV Departamento de Computaci´n o
  • 26. 10 Cap´ ıtulo 2 Figura 2.1: Elementos de un Comprobante Fiscal Digital CINVESTAV Departamento de Computaci´n o
  • 27. Facturaci´n Electr´nica en M´xico 11 o o e 2.2. 2.2.1. Herramientas T´cnologicas asociadas a los Come probantes Fiscales Digitales Criptograf´ ıa La criptograf´ es el estudio de t´cnicas matem´ticas relacionadas a aspectos de ıa e a la seguridad de la informaci´n tales como la confidencialidad, la integridad de datos, o la autenticaci´n de entidad y la autenticaci´n del origen de datos [21]. o o El objetivo principal de la criptograf´ es el de mandar datos de forma segura entre ıa dos entidades atrav´s de un canal de comunicaci´n, protegiendo as´ los datos intere o ı cambiados ante posibles ataques en nuestro canal de comunicaci´n. Para satisfacer o esta premisa, la criptograf´ ofrece los siguientes servicios de seguridad [21]: ıa Confidencialidad: Es un servicio usado para mantener el contenido de la informaci´n secreto de todos exceptuando entidades autorizadas. o Integridad de datos: Este servicio se encarga de prevenir la alteraci´n no o autorizada en los datos. Autenticaci´n: Este servicio consiste en identificar las entidades que paro ticipan en un canal de comunicaci´n. Adicionalmente este servicio provee la o verficaci´n de la informaci´n que es entregada sobre un canal autenticando su o o origen, fecha de origen, etc. No repudio: Mediante este servicio se garantiza que el emisor no pueda negar la creaci´n de cierto mensaje o de las acciones que realiz´. o o Los m´todos criptogr´ficos est´n catalogados en dos, seg´n la forma en que se mae a a u nejan las llaves criptogr´ficas: los de llave secreta o tambi´n llamados de llave privada a e y los de llave p´blica. Los m´todos de llave privada son aquellos donde dos entidades u e tienen un m´todo de cifrado/descifrado y ambos comparten una llave secreta. Por e otra parte, los m´todos de llave p´blica al igual que los de llave secreta comparten e u una llave secreta (com´nmente llamada llave privada), pero tambi´n cuentan con una u e llave p´blica. u 2.2.2. Criptografi´ de llave secreta a Como se hab´ mencionado con anterioridad la criptograf´ de llave privada o ıa ıa sim´trica es un m´todo criptogr´fico donde se utiliza la misma llave tanto para cifrar e e a y descifrar los mensajes. El esquema b´sico de m´todo criptogr´fico se muestra en la a e a figura 4.19. Este sistema es sim´trico con respecto a dos propiedades: e CINVESTAV Departamento de Computaci´n o
  • 28. 12 Cap´ ıtulo 2 Figura 2.2: Esquema de criptogr´ de llave privada ıa La misma llave secreta es usada para cifrar y descifrar. La funci´n de cifrado y descifrado son muy similares. o Los algoritmos de cifrado sim´tricos modernos tales como AES (Advanced Encrye ption Standard ) o 3DES (Triple Data Encryption Standard) son muy seguros, r´pidos a y usados ampliamente. Sin embargo, existen ciertas limitantes asociadas con los esquemas de cifrado sim´trico, como los son[24]: e Problema de la distribuici´n de llaves: La llave secreta debe de ser estableo cida entre las dos entidades en un canal de comunicaci´n seguro. Cabe resaltar o que enlace de comunicaci´n para el envi´ de mensajes no es seguro, as´ que o o ı enviar la llave sobre este canal directamente es infactible. Administraci´n de el n´ mero de llaves: Si cada par de usuarios necesitan o u un par de llaves en una red con n usuarios, entonces existen n·(n−1) . Por ejemplo, 2 en una corporaci´n con 2000 personas, requiere m´s de 4 millones de pares de o a llaves que deben ser generadas y transportadas por medio de un canal seguro. No existe protecci´n contra fraude entre las entidades: En el caso de o algunas aplicaciones electr´nicas es deseable probar que alguna de las entidades o mando un mensaje. Sin embargo si se utiliza criptograf´ sim´trica es posible ıa e que algunas de las entidades se retracte del envi´ del mensaje. o 2.2.3. Criptograf´ de llave p´ blica ıa u Con el fin de tratar las limitantes que presenta la criptograf´ de llave secreta, ıa Whitfield Diffie y Martin Hellman en el a˜o 1976, en el art´ n ıculo ”New Directions in CINVESTAV Departamento de Computaci´n o
  • 29. Facturaci´n Electr´nica en M´xico 13 o o e Figura 2.3: Esquema de criptogr´ de llave p´blica ıa u Cryptography”, hacen una nueva propuesta en la cu´l, en vez de tener una sola llave a secreta se contar´ con un par de llaves: una llave p´blica y una llave privada. La llave a u p´blica como su nombre lo indica, puede ser entregada a cualquier entidad que as´ lo u ı solicite y es utilizada para cifrar la informaci´n por parte de alguna entidad emisora o (si se trata de un esquema de firma electr´nica esta utiliza una funci´n de verificaci´n o o o por una entidad receptora). Por otra parte la llave privada es utilizada para descifrar el mensaje por alguna entidad receptora (en un esquema de firma electr´nica esta o se utiliza para realizar el algoritmo firma digital por alguna entidad emisora). En la figura 2.3 se muestra el esquema de criptograf´ de llave p´blica ıa u 2.2.4. Funciones Picadillo Las funciones picadillo o funciones hash son utilizadas para garantizar la integridad de los datos. Una funci´n picadillo es utilizada para construir una ”huella digital”de o una pieza de datos, si los datos son alterados, entonces la huella digital dejar´ de a ser v´lida. Incluso si los datos son almacenados en un lugar inseguro, la integridad a de los datos puede ser verificada de vez en cuando volviendo a calcular la huella digital y verificando que esta huella no haya cambiado. Una funci´n picadillo tiene o las siguientes caracter´ ısticas [31]: 1. La huella digital o digesto puede ser calculado de forma r´pida. a 2. Para piezas de datos de longitud arbitraria se producen huellas digitales de longitud fija. 3. Son funciones de solo ida. Una vez calculado la huella digital o digesto sobre una pieza de datos es imposible regresar al mensaje original. CINVESTAV Departamento de Computaci´n o
  • 30. 14 Cap´ ıtulo 2 4. Dado dos mensajes diferentes debe de ser computacionalmente imposible que tengan la misma huella digital (libre de colisiones). Esto es dado un mensaje x es imposible encontrar x ̸= x′ tal que h(x′ ) = h(x). 2.2.5. Firma Electr´nica o La firma electr´nica es una de las herramientas criptogr´ficas m´s importantes, o a a su aplicaci´n va desde los certificados digitales para establecer comercio electr´nico o o seguro hasta el establecimiento de llaves sobre canales inseguros, constituyendo ´stas, e la instancia m´s importante para la criptograf´ de llave p´blica. a ıa u La propiedad de probar que una cierta persona gener´ un mensaje es muy imo portante fuera del dominio digital. En el mundo real esto se realiza atrav´s de las e firmas autogr´fas en papel. Por ejemplo, si nosotros firmamos alg´n contrato o un a u cheque, el receptor puede verificar f´cilmente que nosotros firmamos el mensaje. Al a igual que con la firma autogr´fa convencional, solo la persona que cree un mensaje a digital debe ser capaz de generar una firma v´lida. Las firmas digitales comparten a algunas de las funcionalidades con las firmas autogr´fas. En particular, estas proveen a un m´todo para asegurar que un mensaje es aut´ntico a un usuario, es decir, que el e e mensaje se haya originado de la persona quien dice haber generado el mensaje. Para lograr esto es necesario el uso de la criptograf´ de llave p´blica y comunmente el uso ıa u de funciones picadillo. El uso de funciones picadillo nos ayuda a reducir el tama˜o del n mensaje manteniendo una longitud fija sin importar la longitud del mensaje original. Un esquema de firma digital esta compuesto de los siguientes componentes: 1. Un mensaje m. 2. Una funci´n picadillo h() la cu´l debe de ser p´blica. o a u 3. Un par de llaves: una llave privada kpriv y una llave p´blica kpub . u 4. Un algoritmo de firmado sigkpriv (), as´ como su correspondiente algoritmo de ı verificaci´n verkpub (). o Los pasos para crear y verificar una firma digital son los siguientes: 1. Una entidad A calcula el picadillo de el mensaje h1 = h(m). 2. La entidad A firma el mensaje h1 para obtener su firma sigkpriv (h1 ). 3. El par (m, sigkpriv (h(m))) es enviado hacia la entidad B. 4. La entidad B aplica la funci´n picadillo para obtener el digesto h2 = h(m). o 5. La entidad B utiliza el algoritmo de verificaci´n h3 = verkpub (sigkpriv (h(m))). o CINVESTAV Departamento de Computaci´n o
  • 31. Facturaci´n Electr´nica en M´xico 15 o o e Figura 2.4: Esquema de firma digital 6. Si los digestos h2 y h3 son iguales esto quiere decir que la firma es autentica y el mensaje no sufri´ ninguna alteraci´n. o o El proceso de firma digital puede visualizarse en la figura 2.4. Con el uso de firmas digitales se pueden alcanzar los siguientes servicios de seguridad: Integridad Autenticaci´n de Mensajes o No repudio 2.2.6. Infraestructura de llave p´ blica (PKI) u El uso de las firmas digitales por si solas es susceptible a diversos ataques como lo son ataques de repetici´n0 , usurpaci´n de identidad1 y ataques de hombre en el o o 2 medio . Es por esto que es necesario el uso de una infraestructura que evite este tipo de ataques. 0 Ataques de repetici´n: Ataque donde un adversario repite o retarda la transmisi´n de datos de o o manera maliciosa. 1 Ataques de usurpaci´n de identidad: Ataque donde un adversario roba la identidad de un ente o digital. 2 Ataques de hombre en el medio: Este ataque esta relacionado al ataque de usurpaci´n de ideno tidad, donde un adeversario remplaza la llave(s) p´blica de alguno de los participantes de la comuu nicaci´n por su propia llave. o CINVESTAV Departamento de Computaci´n o
  • 32. 16 Cap´ ıtulo 2 La infraestructura de llave p´blica (PKI) es un conjunto de hardware, software, u pol´ ıticas y procedimientos necesarios para crear, manejar, distribuir y revocar certificados digitales basados en criptograf´ asim´trica [27] . El principal objetivo por el ıa e cu´l se desarroll´ el concepto de PKI es para habilitar la adquisici´n de llaves p´blia o o u cas de manera segura, conveniente y eficiente. En general la infraestructura de llave p´blica se compone de diversas tareas o actividades. Las tareas m´s importantes de u a la infraestructura de llave p´blica se mencionan a continuaci´n [28]: u o Emisi´n de certificados: Esta tarea se refiere a la emisi´n de nuevos certifio o cados a los usuarios dentro de una PKI. La mayor´ de las PKI’s tienen una o m´s ıa a autoridades de confianza (usualmente llamadas autoridades de certificaci´n). Antes o que un certificado sea emitido, la identidad y las credenciales del usuario tienen que ser verficados por medios no criptograficos. Una vez verificados las credenciales del usuario, el certificado es emitido al usuario. Al mismo tiempo se realiza procedimiento criptogr´fico para generar la llava p´blica y privada para el propietario de el certifia u cado. Una vez que se gener´ el certificado, este debe ser transmitido al propietario de o una manera segura (posiblemente atrav´s de medios no criptogr´ficos). e a Revocaci´n de certificados: Esta tarea se refiere a la revocaci´n de certificados o o despu´s de su fecha de expiraci´n normal, la cu´l debe de ser especificada en el e o a certificado. La revocaci´n de certificados puede darse por diferentes circunstancias o imprevistas, tales como perdida o robo de la llave privada, o por uso fraudulento de la llave. Respaldo de la llave/ recuperaci´n/ actualizaci´n: El respaldar la llave se o o refiere a un almacenamiento seguro de las llaves privadas por el administrador de la PKI, en caso de perdida de las llaves privadas. La recuperaci´n de llaves es un protocolo que permite que una llave perdida sea o restaurada o reactivada. T´ ıpicamente, un usuario tiene que probar su entidad antes de permitir el acceso a la llave privada. Estampillado de tiempo: A la firma sobre cierto dato que incluya un cierto periodo espec´ ıfico tiempo durante el cu´l la llave es v´lida se le llama estampillado a a de tiempo. Comunicaci´n segura: Este componente se refiere a protocolos seguros tao les como el protocolo S/MIME (Secure Multipurpose Internet Mail Extensions), PGP(Pretty Good Privacy) o TLS(Transport Layer Security). Control de acceso: El control de acceso tambi´n conocido como administraci´n e o de privilegios incorpora autenticaci´n, autorizaci´n y delegaci´n. El control de acceso o o o puede involucrar algunas formas de autenticaci´n de usuario, ya sea por medio de o una contrase˜a o alg´n esquema criptogr´fico de identificaci´n. n u a o Arquitectura de privacidad: Una arquitectura de privacidad permite el uso de certificados an´nimos o pseudoan´nimos. Este tipos de certificados podr´ mostrar la o o ıa CINVESTAV Departamento de Computaci´n o
  • 33. Facturaci´n Electr´nica en M´xico 17 o o e membres´ de un individuo en una clase de usuarios especificados, sin especificar su ıa identidad particular. 2.2.7. Certificados Digitales Los certificados digitales constituyen los bloques principales de la Infraestructura de Llave P´blica y permiten un medio seguro y escalable en las PKI’s. Un certificado u digital vincula a una identidad con su llave p´blica. Esto usualmente sea hace por u medio de el uso de autoridades certificadoras que firman la informaci´n del certificao do, se supone que generalmente todos los usuarios tienen una copia v´lida de la llave a p´bilca de la autoridad certificadora. Por lo tanto, la firma de la autoridad certifiu cadora puede ser verificada, lo cu´l permite que la informaci´n en el certificado sea a o validada. Los certificados m´s com´nmente utilizados son los X.509 v3. Un certificado a u X.509 contiene los siguientes campos: 1. n´mero de versi´n u o 2. n´mero serial u 3. ID del algoritmo de firma digital 4. nombre del emisor 5. periodo de v´lidez a 6. nombre del propietario del certificado 7. la llave p´blica del propietario del certificado u 8. campos opcionales 9. la firma digital de la autoridad certificadora sobre todos los campos anteriores 2.3. Plataforma tecnol´gica de la factura electr´nio o ca en M´xico e La factura electr´nica en M´xico esta regulada por el Servicio de Administraci´n o e o Tributaria (SAT). A la representaci´n electr´nica de una comprobante fiscal impreo o so se le conoce como Comprobante Fiscal Digital(CFD), y que a partir de la nueva regulaci´n ser´ utilizado como comprobante de ingresos, egresos y propiedad de mero a canc´ en M´xico. Para la generaci´n de Comprobantes Fiscales Digitales el SAT ıas e o cuenta con ciertos mecanismos de seguridad, para garantizar que el comprobante sea aut´ntico, ´ e ıntegro e unico. Los componentes para poder generar Comprobante Fiscales ´ Digitales son los siguientes: CINVESTAV Departamento de Computaci´n o
  • 34. 18 Cap´ ıtulo 2 Firma Electr´nica Avanzada (FIEL) y certificado de firma electr´nica. o o Certificados de Sello Digital (CSD). Folios Digitales. Los componentes anteriormente mencionados est´n unificados en una plataforma a que utiliza los est´ndares de la Infraestructura de Llave P´blica (PKI). En el resto a u de la secci´n se hablar´ de como se generan estos componentes y como es la creaci´n o a o de los comprobantes fiscales digitales. 2.3.1. Generaci´n de la Firma Electr´nica Avanzada (FIEL) o o y cerfificado de firma electr´nica o Para la generaci´n de la FIEL y el certificado FIEL, se deber´n crear llaves de o a 1024 bits basados en el esquema de cifrado RSA. La llave p´blica deber´ estar bajo u a el est´ndar PKSC#10 y almacenada en un archivo de requerimientos con extensi´n a o .req en formato DER. Mientras que la llave privada se almacenar´ en archivo con a extensi´n .key bajo el est´ndar PKSC#8 en formato DER. Para la obtenci´n de este o a o par de llaves el SAT provee un programa llamado SOLCEDI(Solicitud de Certificados Digitales) basado en la biblioteca OPENSSL, sin embargo el contribuyente es libre de crear bajo sus propios medios este par de llaves bajo las especificaciones y los est´ndares anteriormente mencionados. a Por otra parte, para la obtenci´n del certificado digital el contribuyente deber´ reao a lizar un cita ante las autoridades del SAT y presentar sus documentos de identificaci´n o (fotograf´ de frente, huellas dactilares, firma aut´grafa,etc) junto con el archivo de ıa o requerimientos .req (almacenado en un medio digital), todo esto con el fin de vincular estos datos junto con la llave p´blica del contribuyente en un certificado digital. El u SAT fungir´ como autoridad certificadora y firmar´ el certificado con su llave privada. a a Al finalizar el tr´mite, se generar´ un certificado digital extensi´n .cer en formato a a o X.509 v3 que se entrega en en el mismo medio digital en el cu´l se llevo el archivo de a requerimientos. 2.3.2. Certificados de Sello Digital (CSD) Los certificados de Sello Digital (CSD) son un tipo de certificado digital que permiten acreditar la autor´ de los Comprobantes Fiscales Digitales emitidos. Para obıa tener los Certificados de Sello Digital se requiere del Certificado de Firma Electr´nica o Avanzada (FIEL). A partir del programa SOLCEDI se deber´ generar un archivo de a requerimientos de certificado de sello digital que contendr´ los datos del certificado de a la FIEL y una llave privada para el uso del certificado de sello digital. Posteriormente el archivo de requerimientos de certificado de sello digital junto con la la llave privada CINVESTAV Departamento de Computaci´n o
  • 35. Facturaci´n Electr´nica en M´xico 19 o o e FIEL es ensobretado en un archivo .sdg siguiendo el est´ndar PCKS#7 para finala mente ser enviado v´ un webservice a trav´s de la aplicaci´n CertiSAT. La aplicaci´n ıa e o o CERTISAT ser´ la encargada de generar el certificado de sello digital con extensi´n a o .cer y en formato X.509 v3. 2.3.3. Folios Digitales Para poder iniciar a facturar electr´nicamente es necesario solicitar los folios dio gitales. Los folios digitales constan de un n´mero y una serie. Para obtener los folios u digitales es necesario el uso de el programa SICOFI donde es necesario la autenticaci´n del usuario ingresando la llave privada y el certificado de la Firma Electr´nica o o Avanzanda. Posteriormente se deben de ingresar la llave privada y el certificado de sello digital y capturar la serie y el rango de folios que se requieran. 2.3.4. Modelo Operativo En la figura 2.5 se muestra el modelo operativo entre el emisor y el receptor de Comprobantes Fiscales Digitales. El modelo operativo para el env´ y recepci´n de los comprobantes Fiscales Digiıo o tales es el siguiente: El emisor debe contar con sus folios, n´meros de aprobaci´n y su u o certificado digital correspondiente. Se genera un documento XML de acuerdo a como lo establece el Anexo 20. Este documento XML contendr´ los datos necesarios de a contabilidad de una factura electr´nica, posteriormente se extrae la cadena original o que no es m´s que una cadena que concatena varios campos del documento XML. La a cadena original es firmado con el esquema de cifrado RSA utilizando el certificado. Al firmado de la cadena original se le conoce como sello digital. Para finalizar el proceso de generaci´n de un comprobante fiscal v´lido es necesario agregar este sello digital o a al documento XML previamente generado. Una vez generado el Comprobante Fiscal Digital este debe ser almacenado por un periodo de 5 a˜os por cualquier aclaraci´n n o fiscal. Al finalizar el proceso de generaci´n del CFD al receptor se le hace llegar el o documento de forma electr´nica o magn´tica o impresa, para la integraci´n de sus o e o procesos de contabilidad, el cliente tiene la obligaci´n de verificar los datos de la o factura como lo son el Folio, Serie y Vigencia del Certificado. CINVESTAV Departamento de Computaci´n o
  • 36. 20 Cap´ ıtulo 2 Figura 2.5: Modelo operativo de la Facturaci´n Electr´nica o o CINVESTAV Departamento de Computaci´n o
  • 37. Cap´ ıtulo 3 Desarrollo de Software Seguro En este cap´ ıtulo se detallan los fundamentos te´ricos que sirven como base para o el desarrollo de aplicaciones de software seguro. Primeramente se introducir´n de a manera breve las metodolog´ cl´sicas de desarrollo de software para posteriormente ıas a hacer una descripci´n m´s detallada de las herramientas, t´cnicas y procesos clave o a e para el desarrollo de software seguro haciendo ´nfasis en aquellos que fueron utilizados e en el desarrollo de este trabajo. 3.1. Metodolog´ de Desarrollo de Software ıas Debido a la complejidad de las aplicaciones de software que se desarrollan hoy en d´ es necesario el uso de metodolog´ para facilitar y llevar de manera esquematizada ıa ıas el desarrollo de software. Las metodolog´ de desarrollo de software proporcionan un ıas marco de trabajo para planear, estructurar y controlar el proceso de desarrollo de los sistemas de informaci´n. Existen diversas metodolog´ para el desarrollo de software o ıas a continuaci´n se mencionan algunos de estos enfoques: o 3.1.1. Modelo en cascada El desarrollo aplicaciones de el modelo en cascada es un enfoque secuencial, en el cu´l cada etapa del desarrollo de software debe de esperar la finalizaci´n de la etapa a o anterior, siguiendo rigurosamente las etapas de desarrollo an´lisis de requerimientos, a dise˜o, implementaci´n, pruebas, integraci´n y mantenimiento. n o o 3.1.2. Modelo en prototipado Este modelo sugiere el desarrollo de software mediante la creaci´n de prototipos, o es decir la creaci´n de versiones incompletas del software que se esta desarrollando. o 21
  • 38. 22 Cap´ ıtulo 3 La idea de este enfoque es perfeccionar el desarrollo de la aplicaci´n y crear prototipos o automatizados cada vez m´s sofisticados, poni´ndolos a disposici´n de los usuarios a e o para realizar pruebas hasta llegar as´ hasta un versi´n final del producto. ı o 3.1.3. Modelo en espiral El modelo en espiral es un proceso de software donde las etapas del desarrollo son colocados en una especie de espiral, donde cada iteraci´n representa un conjunto o de actividades. Este modelo de desarrollo combina las caracter´ ısticas del modelo de prototipado y el modelo en cascada. 3.1.4. Proceso de Unificado de Rational El Proceso de Unificado de Rational(RUP)[26] es un ejemplo de un modelo de proceso que se apega a el uso de UML(Unified Modeling Language) y el asociado Proceso de Unificado de Desarrollo de Software. El Proceso de Unificado de Rational cuenta con las siguientes fases: Inicio El objetivo de la fase de inicio es el de establecer un caso de negocio para el sistema. Elaboraci´n El objetivo es establecer un marco de trabajo arquitect´nico para o o el sistema, desarrollar un plan de trabajo e identificar los riesgos que podr´ ıan surgir en el proyecto. Construcci´n Esta fase comprende el dise˜o del sistema, la programaci´n y o n o las pruebas. Al terminar esta fase, se debe de tener un software operativo y documentando. Transici´n Como su nombre lo indica esta fase busca hacer la transici´n de la o o comunidad de desarrollo hacia la comunidad de usuarios y hacerlo trabajar en un entorno real. 3.1.5. Desarrollo ´gil de software a Este tipo de metodolog´ se basan en un enfoque incremental e iterativo, donde el ıas cliente espec´ ıfica en cada incremento los requerimientos a incluir. Los clientes deben de estar fuertemente involucrados en todo el proceso de desarrollo, proporcionando y priorizando los nuevos requerimientos, evaluando cada iteraci´n del ciclo de dasarrollo. o En el desarrollo ´gil de software se debe de optar por la simplicidad tanto en el a software a desarrollar como en el proceso, trabajando de manera activa para elimnar la complejidad de el sistema. CINVESTAV Departamento de Computaci´n o
  • 39. Desarrollo de Software Seguro 23 3.1.6. Capability Maturity Model Integration La integraci´n de Modelos de Madurez y Capacidad (CMMI) es un proceso para o la mejora y evaluaci´n dentro de las organizaciones, provee a las organizaciones con o los elementos esenciales para mejorar su desempe˜o[11]. CMMI puede usarse como n una gu´ para la mejora ya sea en un proyecto, una divisi´n de la empresa o una ıa o organizaci´n entera. Por todas estas caracter´ o ısticas CMMI es aplicable al desarrollo de software al uso de CMMI dentro de el desarrollo de software o servicios de informaci´n o se le conoce como CMMI-DEV. CMMI-DEV es una colecci´n de buenas pr´cticas que o a adoptan las organizaciones para mejorar la efectividad, eficiencia y la calidad de el software, tambi´n incluye gu´ que cubren los ciclos de vida del software desde su e ıas concepci´n hasta la entrega y mantenimiento del producto. o 3.2. Desarrollo de Software Seguro Dentro de los modelos y metodolog´ anteriormente mencionados, en ninguno de ıas sus procesos se contempla la parte de desarrollo seguro de aplicaciones. Es por esta raz´n que para resolver este problema se ha desarrollado un proceso que facilite el o modelado de componentes cr´ ıticos y amenazas que puedan presentarse en un sistema de informaci´n. A este proceso se le conoce como ciclo de vida de desarrollo seguro o el cu´l busca mitigar en medida de lo posible ataques potenciales hacia el sistema de a informaci´n. o 3.2.1. Ciclo de vida de Software Seguro El ciclo de vida de software seguro es un proceso que incluye una serie de procedimientos y actividades que deben de ser establecidas durante el ciclo de vida de desarrollo de software con el fin de desarrollar sistemas de informaci´n seguros y reo sistir en medida de lo posible los diferentes ataques que se puedan presentar en una aplicaci´n. Reducir la debilidades de un sistema comienza desde la especificaci´n de o o los requerimientos de seguridad. El software que incluye los requerimientos de seguridad puede ayudar a anticipar comportamiento anormal y nos ayudara a crear software confiable y seguro. Un proceso de ciclo de vida seguro debe de compensar las deficiencias en los requerimientos de software a˜adiendo pr´cticas basadas en riegos n a y comprueba la adecuaci´n de las pr´cticas durante el ciclo de vida del software. A o a continuaci´n se mencionaran dos aproximaciones de como puede ser llevado el ciclo o de vida de desarrollo los cu´les integran fases o tareas adicionales al ciclo de vida a convencional de desarrollo. Actualmente, se ha identificado dos propuestas las cuales cubren el proceso del ciclo de vida seguro. CINVESTAV Departamento de Computaci´n o
  • 40. 24 Cap´ ıtulo 3 3.2.2. Ciclo de vida de Desarrollo Confiable de Microsoft El ciclo de vida de Desarrollo Confiable de Microsoft (o simplemente SDL) es un proceso que Microsoft ha adoptado para el desarrollo de software que necesita resistir ataques [14]. El proceso agrega una serie de actividades enfocadas a la seguridad y entregables en cada fase de el proceso de desarrollo de software. Est´s actividades de a seguridad y entregables incluyen la definici´n de requisitos de seguridad y actividades o de evaluaci´n durante la fase de requerimientos, modelo de amenazas para la identifio caci´n de riesgos durante la fase de dise˜o, el uso de herramientas de an´lisis est´tico o n a a de c´digo y revisiones durante la implementaci´n, adem´s de pruebas orientadas y o o a pruebas difusas durante la fase de pruebas. Durante la fase de verficaci´n se realiza o una revisi´n final del c´digo y finalmente, durante la fase de lanzamiento, la revisi´n o o o se lleva a cabo por el equipo de Seguridad de Microsoft, que es un conjunto de expertos que han sido asignados durante todo el ciclo de desarrollo. El ciclo de vida de Desarrollo Confiable de Microsoft esta compuesto de 12 fases como se muestra a continuaci´n: o Fase 0: Educaci´n y Conciencia: Esta etapa se encarga de ense˜ar tanto al equio n po de trabajo como a la organizaci´n de las amenazas que existen al desarrollar o sistemas de informaci´n y las t´cnicas que existen para mitigar estas amenazas. o e Fase 1: Iniciaci´n del Proyecto: Este fase consiste en los siguientes pasos: o • Determinar si la aplicaci´n es cubierta por el ciclo de desarrollo seguro o (SDL). • Asignar un lider de seguridad. • Construir el equipo de seguridad. • Hacer una compilaci´n de los bugs que van a ser mitigados. o Fase 2: Definir y seguir pr´cticas de mejores dise˜os: En esta fase se asigna a n como mandato a los ingenieros encargados de proyecto a pensar en las caracter´ ısticas de seguridad y implementar dise˜os seguros, aplicando principios de n dise˜o seguro. n Fase 3: Evaluaci´n de riesgos del producto: El prop´sito de la evaluaci´n de o o o riesgos es la de clarificar el nivel de esfuerzo para llevar a cabo los requerimientos del ciclo de vida de desarrollo seguro y as´ determinar como gastar los recursos ı al desarrollar el producto. Fase 4: An´lisis de Riesgo: En esta etapa se realiza un modelado de amenazas a el cu´l es importante para construir software seguro ya que es la piedra angular a para entender como el producto podr´ ser atacado y como podr´ ser defendido. ıa ıa CINVESTAV Departamento de Computaci´n o
  • 41. Desarrollo de Software Seguro 25 Fase 5: Crear documentos de seguridad, herramientas, y mejores pr´cticas para a clientes: Esta etapa es la encargada de la realizaci´n de documentos y gu´ que o ıas sean de ayuda para que los usuarios conozcan las implicaciones de seguridad y las configuraciones. Fase 6: Pol´ ıticas de c´digo seguras: Durante esta etapa se hace uso de las mejores o pr´cticas de c´digo seguro y se aplica el uso de herramientas de an´lisis de c´digo a o a o seguro. Fase 7: Pol´ ıticas de prueba seguras: En esta etapa se realizan diferentes tipos de m´todos para hacer pruebas en la aplicaci´n ya implementadas dentro de las que e o se encuentran: pruebas difusas, pruebas de penetraci´n, verificaci´n en tiempo o o de ejecuci´n, revisar de nueva cuenta el modelo de amenazas, reevaluaci´n de o o los ataques. Fase 8: Push de seguridad: Esta etapa consiste en hacer una revisi´n del c´digo, o o incluyendo una actualizaci´n del modelos de amenazas y de la documentaci´n o o de los ataques Fase 9: Revisi´n de seguridad final: Antes de que el producto pueda entregarse o a los usuarios finales se debe de hacer una revisi´n final de seguridad verificando o que todo el grupo de trabajo haya seguido correctamente el ciclo de desarrollo seguro. Fase 10: Planificaci´n de respuesta de seguridad: Una vez que el software se o encuentre listo es necesario crear un equipo o un centro de respuesta que este preparado para investigar y eliminar nuevas vulnerabilidades de seguridad. Fase 11: Liberaci´n del producto: En esta fase se libera el producto despu´s de o e haber pasado por la revisi´n de seguridad final. o Fase 12: Ejecuci´n de respuesta de seguridad: En esta fase se hace la ejecuci´n de o o un plan de respuesta en caso de que aparezcan nuevas vulnerabilidades contando con toda la documentaci´n que se realiz´ en las fases anteriores. o o 3.2.3. Ciclo de vida de seguridad mejorado de McGraw El ciclo de vida de seguridad mejorado de McGraw y Taylor[30] compensa las deficiencias en los requerimientos de software, agrega pr´cticas de riesgo y verifica las a adecuaciones de esas pr´cticas agregando el concepto de puntos clave de seguridad a durante todas las fases del ciclo de vida de software. En la figura 3.1 se muestra como incorporar la seguridad en el ciclo de vida de desarrollo seguro. Los puntos claves de seguridad son aplicados a un conjunto de artefactos de software que son creados durante el proceso de desarrollo de software. CINVESTAV Departamento de Computaci´n o
  • 42. 26 Cap´ ıtulo 3 Figura 3.1: Ciclo de vida de seguridad de McGraw y Taylor En la fase de seguridad de requerimientos se manifiesta la seguridad funcional as´ como las caracter´ ı ısticas emergentes de seguridad que un sistema debe de integrar. Una buena forma para cubrir los requerimientos de seguridad es atrav´s de los antie casos de uso. Los anticasos de uso describen el comportamiento del sistema cuando este se encuentra bajo un ataque, construirlos requiere abarcar las partes del sistema que deben de ser cubiertos, de qui´n y por cuanto tiempo. e En la fase de dise˜o y arquitectura, el sistema debe de ser coherente y presentar n una arquitectura unificada de seguridad tomando en cuanta las reglas de seguridad. Los dise˜os, arquitecturas y el an´lisis debe de estar debidamente documentado idenn a tificando todos los posibles ataques. Tanto en la fase de arquitectura basada en especificaciones como en el dise˜o jer´rquico de clases, el an´lisis de riesgos se necesita n a a incorporar. Utilizar el an´lisis de riesgos nos ayuda a descubrir y clasificar los riesgos a para as´ encontrar una forma de mitigarlos. ı Para la fase de codificaci´n trata de enfocarse en encontrar en las fallas de impleo mentaci´n utilizando herramientas de an´lisis est´tico (herramientas que exploran el o a a c´digo en busca de vulnerabilidades). o Para realizar pruebas de seguridad se deben de abarcar dos estrategias: la primera es probar la funcionalidad de seguridad con t´cnicas de pruebas funcionales y la otra e es utilizar pruebas de seguridad basadas en el riesgo de ciertos patrones de ataque y en modelos de amenaza. Realizar pruebas de penetraci´n tambi´n resultan utiles o e ´ para ver los riesgos de la arquitectura probando el sistema en un ambiente real. La ultima fase es el monitoreo de seguridad se hace una revisi´n continua checando ´ o el estado o el comportamiento de software durante el tiempo y aplicando un plan emergente a nuevas vulnerabilidades que aparezcan. El enfoque de McGraw y Taylor presentado anteriormente es neutral y por lo tanto, puede ser usado con una gran cantidad de procesos de software(cascada, ´gil, a espiral, etc). 3.3. Herramientas de desarrollo seguro Con el fin de facilitar la tarea del an´lisis y dise˜o de aplicaciones seguras durana n te el ciclo de vida de desarrollo seguro se han creado metodolog´ y herramientas ıas CINVESTAV Departamento de Computaci´n o
  • 43. Desarrollo de Software Seguro 27 que ayudan a realizar el modelado de componentes cr´ ıticos y amenazas que puedan presentarse en un sistema de informaci´n est´s se utilizan con el fin de mitigar en o a medida de lo posible dichas amenazas. A continuaci´n se mencionaran aquellas que o son relevantes para este trabajo de tesis. 3.3.1. SQUARE Es una m´todologia que proporciona los medios para obtener, categorizar y prioe rizar los requisitos de seguridad para los sistemas de informaci´n y aplicaciones. El o enfoque de esta metodolog´ es la construcci´n de los conceptos de seguridad en las ıa o etapas tempranas del ciclo de vida de desarrollo. Este modelo tambi´n se puede utie lizar para documentar y analizar los aspectos de seguridad de los sistemas para el manejo y envi´ de futuras mejoras y modificaciones a los sistemas. SQUARE eso ta compuesto de 9 pasos para la obtenci´n de requisitos, los cuales se presentan a o continuaci´n: o 1. Consenso sobre los conceptos y su definici´n. En esta estapa se realio zan reuniones con los clientes para establecer un conjunto com´n de reglas de u seguridad para establecer una base com´n de conocimiento. u 2. Identificaci´n de los objetivos de seguridad. Se realiza a nivel organizao cional y es para establecer un conjunto de metas de seguridad priorizadas para el proyecto. Est´ etapa provee una verificaci´n consistente con las pol´ a o ıticas y el ambiente operativo de la organizaci´n. o 3. Desarrollo de los artefactos necesarios para definir los requisitos de seguridad. Antes de que se realicen los requerimientos de seguridad es necesario contar con un conjunto de herramientas para hacer el levantamiento de requerimientos, estas herramientas van desde diagramas de arquitectura del sistema, diagramas de anticasos de uso, ´rboles de ataque, etc. a 4. Valoraci´n de riesgos. El objetivo de esta fase es la identificar vulnerabilio dades y amenazas que pueda enfrentar el sistema, viendo la posibilidad de que estos se materialicen en un ataque y las consecuencias que este pueda traer. 5. Selecci´n de las t´cnicas para enunciaci´n los requisitos. En esta fase o e o se elige una t´cnica de enunciaci´n de requerimientos que se adapte tanto a los e o clientes como al equipo de desarrollo. 6. Obtenci´n de los requisitos. En esta fase se enuncian los requerimientos de o seguridad de acuerdo a la t´cnica utilizada. La mayor´ de las t´cnicas proveen e ıa e una gu´ detallada de como utilizar dicha enunciaci´n. ıa o CINVESTAV Departamento de Computaci´n o
  • 44. 28 Cap´ ıtulo 3 7. Clasificaci´n de los requisitos. Esta fase consiste en distinguir entre los o requerimientos esenciales, metas y restricciones arquitecturales y clasificarlos de acuerdo a su relevancia. 8. Priorizaci´n. En esta fase se elige que requerimientos van a ser implementados o de acuerdo a la clasificaci´n de requerimientos que se realizo anteriormente. o 9. Revisi´n de los requisitos. El objetivo de esta fase es revisar atrav´s de un o e m´todo de inspecci´n las ambiguedades, errores y incosistencias que se pudieran e o tener en los requerimientos. 3.3.2. STRIDE Es un m´todo de clasificaci´n para categorizar amenazas conocidas de acuerdo e o con el tipo de vulnerabilidad que se utiliza por alg´n atacante. El t´rmino STRIDE u e es el acr´nimo de “Spoofing identity, Tampering with data, Repudiation, Informao tion disclosure, Denial of service, Elevation of privilege”. Es decir, suplantaci´n de o identidad, manipulaci´n de datos, repudio, revelaci´n de informaci´n, denegaci´n de o o o o servicio y elevaci´n de privilegios. o Suplantaci´n: El ataque de suplantaci´n se produce cuando un atacante usuro o pa la identidad de alguna otra persona obteniendo informaci´n de autenticaci´n. o o Modificaci´n de datos: Este ataque se produce cuando los datos que son o transmitidos por un canal de comunicaci´n o almacenados de manera persistente o son alterados con prop´sitos malignos. o Repudiaci´n: Este ataque esta asociado con usuarios que niegan la autor´ o ıa de una acci´n o evento en un sistema de informaci´n. o o Revelaci´n de la Informaci´n: Este ataque est´ relacionado cuando el o o a sistema o aplicaci´n revela informaci´n a personas no autorizadas. o o Denegaci´n de Servicio: Este ataque se refiere a la introducci´n de datos o o o informaci´n maliciosa para mantener alg´n sistema de informaci´n no disponio u o ble. Elevaci´n de privilegios: Este tipo de amenaza se presenta cuando un usuao rio no autorizado obtiene privilegios que normalmente no tendr´ y debido a ıa esto tiene el acceso suficiente para comprometer el sistema. CINVESTAV Departamento de Computaci´n o
  • 45. Desarrollo de Software Seguro 29 Para seguir el m´todo STRIDE, se descompone el sistema en componentes signifie cativos, tras analizar cada componente para comprobar si es susceptible de sufrir las amenazas anteriormente mencionadas y se proponen acciones que traten de mitigarlas. A continuaci´n, se repite el proceso hasta llegar a una situaci´n c´moda con las o o o amenazas restantes. 3.3.3. UMLSec Es una extensi´n de lenguaje de modelado UML para el desarrollo de sistemas o seguros evaluando diagramas UML de varios tipos indicando sus vulnerabilidades. Necesidades peri´dicas de seguridad (tales como confidencialidad, integridad y autenticao ci´n) son ofrecidas como elementos de especificaci´n por la extensi´n de UMLSec[16]. o o o Estas propiedades son utilizadas para evaluar diagramas de varios tipos e indicar posibles vulnerabilidades. Esta extensi´n esta dada en forma de un perfil de UML usando mecanismos de o extensi´n de UML, utiliza estereotipos en conjunci´n de etiquetas de UML para foro o mular requerimientos de seguridad y suposiciones del ambiente del sistema, as´ mismo ı usa restricciones que determinan si los requerimientos se cumplen con el dise˜o del n sistema. Para el desarrollo de sistemas cr´ ıticos, este enfoque nos permite considerar los requerimientos de seguridad desde etapas tempranas de una manera transparente atrav´s del ciclo de desarrollo. Herramientas basadas en modelo como UMLSec nos e servir´n para establecer que el sistema cumpli´ con los requerimientos de seguridad a o a nivel dise˜o, analizando el modelo del sistema, y a su vez nos ayudara a verificar n que el c´digo que se realiz´ tambi´n es seguro generando secuencias de pruebas para o o e el modelo. 3.3.4. T´cnicas de Codificaci´n Segura e o Las pr´cticas de codificaci´n segura ayudan substancialmente a reducir defectos a o comunes introducidos durante la implementaci´n, por esta raz´n es importante coo o nocer que tipos de agujeros de seguridad son comunes y presentar una estrategia de revisi´n a nivel c´digo. Entre los hoyos de seguridad que podr´ o o ıamos encontrar durante la codificaci´n encontramos los siguientes: validaci´n incorrecta o incompleta de o o las entradas, manejo de excepciones pobre, buffer overflow, inyecci´n de c´digo SQL, o o condiciones de competencia, etc. Para hacer las revisiones de c´digo se deben de considerar est´ndares de codifio a caci´n y hacer uso de rese˜as de listas de verificaci´n de c´digo, inspeccionando los o n o o comentarios en c´digo, documentaci´n, pruebas unitarias y requerimientos de segurio o dad. En la fase de pruebas se detalla como el c´digo debe usarse para demostrar que o cumple con los requerimientos de seguridad y est´ndares de dise˜o/c´digo destinados a n o a reducir las fallas de dise˜o y errores de implementaci´n. n o CINVESTAV Departamento de Computaci´n o
  • 46. 30 Cap´ ıtulo 3 3.3.5. Herramientas de An´lisis de c´digo est´tico a o a El an´lisis de c´digo est´tico es el proceso en el cu´l los desarrollores de software a o a a verifican su c´digo para encontrar problemas y inconsistencias antes de compilar. o Los desarrolladores pueden automatizar el an´lisis de c´digo usando herramientas de a o an´lisis de c´digo est´tico. Estas herramientas exploran el c´digo fuente y detectan a o a o errores que t´ ıpicamente el compilador no detectar´ y las cuales podr´ provocar ıa ıan problemas posteriores en el ciclo de vida de desarrollo. 3.3.6. Pr´cticas de codificaci´n a o Las pr´cticas de codificaci´n t´ a o ıpicamente describen m´todos, t´cnicas, procesos, e e herramientas que pueden prevenir o limitar exploits hacia vulnerabilidades existentes. Las pr´cticas de codificaci´n segura requieren el entendimiento de los errores de proa o gramaci´n que suelen llevar a vulnerabilidades de software as´ como el conocimiento o ı y uso de enfoques alternativos que son menos propensos a error. 3.4. Pruebas de seguridad de software Las actividades de pruebas de seguridad son principalmente realizadas para demostrar que un sistema cumple con los requerimientos de seguridad, identificar y minimizar el numero de vulnerabilidades en el software antes de que el software sea lanzado a producci´n. El objetivo de las pruebas de seguridad es la de asegurar que o el software que se este verificando sea robusto y continu´ su funcionamiento de una e manera aceptable incluso en presencia de un ataque. Existen dos m´todos para probar e si un software ha cumplido con sus requerimientos de seguridad estas son las pruebas de seguridad funcionales y las pruebas de seguridad basadas en riesgos. Pruebas Funcionales: Estas pruebas tienen la intenci´n de asegurar de que o el software se comporte como se espec´ ıfico y se basa en demostrar que los requerimientos definidos se cumplan en un nivel aceptable. Pruebas basadas en riesgo: Las pruebas basadas en riesgo est´n dirigidas a hacia los requerimientos negativos, los cu´les nos dicen lo que un sistema debe a de hacer y lo que no. Estos requerimientos deben de venir de un an´lisis de a riegos, el cu´l debe debe de abarcar tanto los riesgos altos que existan como a aquellos que no presentan tanto riesgo para el sistema de informaci´n. o El software es verificado en muchos niveles en un proceso t´ ıpico de desarrollo. A continuaci´n se mencionaran algunas actividades que son comunes en en la mayor´ o ıa de los procesos de pruebas. alguno de ellos son repetidos en diferentes ocasiones para artefactos de software en diferentes niveles: CINVESTAV Departamento de Computaci´n o
  • 47. Desarrollo de Software Seguro 31 Pruebas Unitarias Se utilizan usualmente en la primera etapa de pruebas e involucra probar relativamente peque˜os componentes tales como clases, m´ton e dos, funciones, etc. Probar bibliotecas y archivos ejecutables Pruebas de integraci´n El objetivo de esta prueba es la de verificar que cierta o colecci´n de componentes de software trabajen entre ellos correctamente. o Pruebas de sistema Se pone a prueba todo el sistema, a trav´s de pruebas e de estr´s o pruebas de penetraci´n. e o Pruebas de penetraci´n El objetivo de esta prueba es la de verificar que el o sistema o aplicaci´n sea comprometido a trav´s de la b´squeda de vulnerabilio e u dades. CINVESTAV Departamento de Computaci´n o
  • 48. 32 Cap´ ıtulo 3 CINVESTAV Departamento de Computaci´n o
  • 49. Cap´ ıtulo 4 An´lisis y dise˜ o de un sistema a n seguro de facturaci´n electr´nica o o En este cap´ ıtulo se presenta el an´lisis y dise˜o de un sistema de facturaci´n a n o electr´ncia explicando cu´l fue el modelo de proceso a utilizar para la elaboraci´n o a o del sistema, incorporando a este proceso t´cnicas y metodolog´ de desarrollo de e ıas software seguro. 4.1. 4.1.1. An´lisis de Requerimientos a Perspectiva del producto El sistema de facturaci´n electr´nica utilizar´ un dispositivo m´vil para generar o o a o y certificar CFD’s, contar´ con un mecanismo de sincronizaci´n para respaldar los a o CFD’s. El envi´ de los CFD’s ser´n enviados por correo electr´nico a trav´s de un o a o e canal seguro. La interacci´n con los usuarios ser´ a trav´s de una interfaz gr´fica por o a e a medio de un dispositivo m´vil. o 4.1.2. Funciones del producto El sistema de facturaci´n electr´nica tendr´ las siguientes funciones: o o a Crear factura Administrar clientes Crear factura Generar Reporte Mensual 33
  • 50. 34 Cap´ ıtulo 4 Reporte Contable Consulta de CFD’s 4.1.3. Caracter´ ısticas del usuario El sistema esta destinado a personas que quieran emitir facturas electr´nicas en o peque˜os puntos de venta o peque˜as empresas a trav´s de un dispositivo m´vil. n n e o 4.1.4. Suposiciones y dependencias El sistema tendr´ las siguientes dependencias antes de poder usado: a 1. La aplicaci´n debe de estar firmada por el proveedor de el servicio de facturaci´n o o electr´nica. o 2. La aplicaci´n debe de tener acceso a la llave privada (archivo .key) previao mente guardada en el dispositivo, esta debe ser obtenido a trav´s del programa e proporcionado por el SAT llamado SOLCEDI. 3. La aplicaci´n m´vil debe de tener acceso a el certificado digital(archivo .cer) o o de la FIEL el cu´l contiene la llave p´blica del usuario. Este tr´mite se hace en a u a las instalaciones del SAT. 4. La aplicaci´n m´vil debe de tener acceso a el certificado de sello digital (archivo .cer) o o generado por medio de la aplicaci´n SOLCEDI y la aplicaci´n CertiSAT. Este o o certificado sirve para firmar los comprobantes fiscales digitales. 5. El sistema debe de tener acceso a los folios electr´nicos proporcionados por la o aplicaci´n SOLCEDI. o 4.1.5. Requerimientos Funcionales R.1 Facilidad de uso: El sistema de facturaci´n electr´nica debe de contar con una interfaz amigable o o para el usuario. R.2 Autenticaci´n a trav´s de usuario y contrase˜ a: o e n Para ingresar al sistema de facturaci´n electr´nica se tendr´ que ingresar mediante o o a un nombre de usuario y contrase˜a, si no se cuenta con uno el sistema nos pedir´ que n a ingresemos un nombre de usuario nuevo y contrase˜a. n CINVESTAV Departamento de Computaci´n o
  • 51. An´lisis y dise˜o de un sistema seguro de facturaci´n electr´nica 35 a n o o R.3 Men´ de Acceso: u Al entrar al sistema tendremos acceso a un men´ que nos permitir´ realizar las u a siguientes acciones: Crear factura Administrar clientes Crear factura Generar Reporte Mensual Reporte Contable Consulta de CFD’s R.4 Generar factura: El usuario del sistema podr´ realizar una factura electr´nica seleccionando a un a o cliente de una lista de clientes registrados, en caso de que no exista el cliente el usuario podr´ crear un nuevo cliente. El sistema deber´ mostrar los datos del contribuyente a a a nombre del que se emite (receptor) la factura tales como: Nombre de la empresa. RFC. Domicilio Fiscal. Datos y Cantidad del producto. Se requiere ingresar totalmente los datos para poder generar correctamente un CFD, de acuerdo a lo establecido en el anexo 20 secci´n C. Al tener los datos cono firmados el sistema debe de crear la factura electr´nica y debe de mandarse hacia o receptor. Los CFD’s emitidos se almacenan en el dispositivo en una colecci´n de o CFD’s. R.5 Crear Cliente: El sistema tendr´ la capacidad de ingresar un nuevo cliente. Para ingresar a un a nuevo cliente el usuario tendr´ que ingresar los siguientes datos: a 1. Raz´n Social o CINVESTAV Departamento de Computaci´n o
  • 52. 36 Cap´ ıtulo 4 2. Correo electr´nico o 3. Direcci´n: o 4. RFC Los datos del cliente se guardaran localmente en el dispositivo mediante una base de datos interna y se podr´n respaldar en un servidor externo. Los clientes guardados a por el sistema podr´n ser utilizados para pr´ximas veces en la creaci´n de facturas. a o o R.6 Administrar clientes El sistema podr´ realizar cambios o bajas de clientes. El sistema debe de mostrar a una lista con clientes teniendo la posibilidad de hacer bajas o modificaciones. Modificaci´n de Usuario Al hacer una modificaci´n se deben de mostrar o o toda la informaci´n del cliente( Raz´n Social, correo electr´nico, direcci´n ), el o o o o sistema tendr´ la posibilidad de modificar esta informaci´n. a o Baja de Usuario Se tendr´ que hacer una b´squeda del usuario del que se a u quiere que hacer la baja, a continuaci´n se mostrar´ la informaci´n de dicho o a o cliente, se contar´ con un bot´n para confirmar la baja de dicho cliente. a o R.7 Generar Reporte Mensual El sistema deber´ generar el reporte mensual que debe de ser mandado al SAT. El a usuario debe de seleccionar el mes y a˜o del reporte. El reporte mensual debe de ser n creado de acuerdo al Anexo 20 secci´n A, este reporte deber´ ser guardado localmente o a en el dispositivo y posteriormente se debe mandar hacia el SAT por medio que este determine. R.8 Reporte Contable En el sistema se podr´n visualizar todas las facturas que se hayan generado. El a reporte contable deber´ mostrar la siguiente informaci´n: a o No. de Factura Nombre Importe Total CINVESTAV Departamento de Computaci´n o
  • 53. An´lisis y dise˜o de un sistema seguro de facturaci´n electr´nica 37 a n o o R.9 Consulta de CFD’s El sistema debe de contar con un mecanismo para buscar dentro de la colecci´n de CFD’s generados, el sistema podr´ buscar el comprobante por los siguientes o a par´metros: a Emisor Receptor Producto Para ejecutar la consulta solo es necesario especificar alguno de los filtro especificados. Una vez localizado el/los CFD’s acorde al criterio de b´squeda, se podr´ consultar u a el detalle de cada CFD. 4.1.6. Requerimientos no funcionales R.10 Mecanismo para almacenamiento seguro de los comprobantes fiscales Los CFD’s generados deben de ser almacenados en un deposito seguro en la memoria SD del dispositivo (copia local). R.11 Mecanismo para respaldo de CFD’s Debe de existir un mecanismo para guardar de manera segura los CFD’s en un repositorio remoto. R.12 Mecanismo para sincronizaci´n de datos o El sistema debe de contar con un mecanismo de sincronizaci´n para respaldar los o datos del usuario, clientes, CFD’s asegurando que esta sincronizaci´n se haga a trav´s o e de un canal seguro. R.13 Env´ de Comprobantes Fiscales Digitales ıo Una copia de los CFD’s deben ser enviados al contribuyente a nombre que se emite (receptor) el cu´l debe de verificar la validez de dicho comprobante, para lo cu´l el a a cfd debe ser enviado por medio de un canal seguro. El env´ puede hacerse a trav´s ıo e de correo electr´nico o hacia otro dispositivo por medio de bluetooth, por ejemplo. o CINVESTAV Departamento de Computaci´n o
  • 54. 38 Cap´ ıtulo 4 R.14 Extracci´n de la informaci´n del Certificado Digital o o Debido que el certificado digital generado por la aplicaci´n SOLCEDI tiene la ino formaci´n relacionada con el emisor de los comprobantes fiscales digitales, se podr´ exo a traer la informaci´n de el emisor para el uso del sistema de facturaci´n electr´nica, o o o esta informaci´n debe de ser guardada localmente, garantizando el acceso exclusivo o de la aplicaci´n. o R.15 Sello Digital El sello digital que se integra al CFD debe de hacerse de acuerdo al Anexo 20 secci´n D. o R.16 Lenguaje de programaci´n o El lenguaje de programaci´n ser´ JAVA debido a que es el lenguaje nativo de la o a plataforma ANDROID. 4.2. Requerimientos de Seguridad con SQUARE En esta secci´n se presentar´n ejemplos de la aplicaci´n de la metodolog´ de o a o ıa SQUARE dentro de el contexto de una aplicaci´n de facturaci´n electr´nica. o o o Debido a la naturaleza de este trabajo y tomando en cuenta que la aplicaci´n de o la metodolog´ SQUARE se necesita un fuerte compromiso organizacional y debido ıa a que ejecutar el proceso completo de la metodolog´ es tardado, se ha decido el uso ıa de una versi´n reducida de SQUARE llamada SQUARE-Lite. o SQUARE-Lite consiste en 4 pasos extra´ ıdos de la metodolog´ SQUARE, estos ıa pasos corresponden a los pasos 1,2,6,8. Los pasos en el proceso de SQUARE-Lite se encuntran resumidos en la siguiente tabla [10]: Como puede observarse para algunos casos de la metodolog´ es necesario trabajar ıa directamente con el cliente para llegar a un consenso, la interacci´n con el cliente fue o omitida haciendo suposiciones de las acciones organizacionales que deber´ de ejecutar ıa el cliente. 4.2.1. Consenso sobre los conceptos y su definici´n. o Se definieron una lista de conceptos de seguridad que son indispensables para el desarrollo de la aplicaci´n de facturaci´n electr´nica. Estas definiciones fueron o o o tomadas de distintas referencias, como los son: el Anexo 20 del SAT, FIPS-140-3, RFC-2459, etc.Algunos de los conceptos que se definieron fueron los siguientes: CINVESTAV Departamento de Computaci´n o
  • 55. An´lisis y dise˜o de un sistema seguro de facturaci´n electr´nica 39 a n o o Paso 1 Acuerdo en las definiciones Entrada Definiciones candidatas de est´ndares a 2 Identificar me- Definiciones, tas de seguridad metas candidatas, pol´ ıticas. 3 Obtenci´n de Artefactos, o requerimientos resultado del de seguridad an´lisis de riesa gos, selecci´n de o t´cnicas e 4 Priorizar re- Requerimientos querimientos categorizados, resultado del an´lisis a de riesgos T´cnicas e Entrevistas estructuradas Participantes Clientes, equipo de requerimientos. Sesiones de tra- Clientes, inbajo, encuestas, geniero de entrevistas requerimientos. Modelo basados Ingeniero de reen an´lisis, lista querimientos. a de requerimientos, entrevistas, encuestas, m´toe do acelerado de obtenci´n de reo querimientos M´todos de prio- Ingeniero de ree rizaci´n o querimientos. Salida Consenso de las definiciones. Metas Corte inicial en los requerimientos de seguridad Requerimientos priorizados Cuadro 4.1: Metodolog´ SQUARE-Lite ıa Confidencialidad: Es la propiedad de que la informaci´n sensitiva no este o disponible o se divulge a individuos, entidades o procesos no autorizados [23]. Llave privada: Llave criptogr´fica, usada con un algoritmo criptogr´fico, que a a esta unicamente asociado con una entidad y esta no se hace p´blica [23]. ´ u CFD: Es un mecanismo alternativo de comprobaci´n de ingresos, egresos y proo piedad de mercanc´ en traslado por medios electr´nicos. Maneja est´ndares de ıas o a seguridad internacionalmente reconocidos, que garantizan que el comprobante es aut´ntico, ´ e ıntegro, unico[5]. ´ Una lista completa de las definiciones utilizadas en este trabajo podr´ encontrarse a en el Ap´ndice A. e 4.2.2. Identificaci´n de metas de seguridad o Para nuestra aplicaci´n de facturaci´n electr´nica se definieron pol´ o o o ıticas de seguridad. Recordemos que estas pol´ ıticas se deben de realizar a nivel organizacional verificando que concuerde los objetivos de negocio de la organizaci´n. A continuaci´n o o CINVESTAV Departamento de Computaci´n o
  • 56. 40 Cap´ ıtulo 4 mostraremos un ejemplo de objetivo de seguridad identificado para el contexto de la aplicaci´n a desarrollar: o Objetivo: Integridad de datos. Los datos como la llave privada, folios, certificado digital, cartera de clientes, factura emitida y entregada (por entregar), copia local de facturas emitidas, copia de respaldo de facturas emitidas, reporte mensual no deben de ser alterados. Antes de utilizar el sistema de facturaci´n electr´nica se debe de realizar o o una funci´n de autoprueba que cheque la integridad tanto de la aplicaci´n como de o o los datos anteriormente mencionados, si la aplicaci´n ha sufrido alguna alteraci´n en o o los datos el sistema tendr´ la capacidad de alertar al usuario. a Una lista de las metas de seguridad que fueron definidas podr´n encontrarse en el a Ap´ndice B. e 4.2.3. Obtenci´n y priorizaci´n de los requerimientos de seo o guridad Casos de uso Para definir el funcionamiento de nuestra aplicaci´n y las interacciones que iba a o tener el usuario con el sistema, fue necesario utilizar herramientas tales como los casos de uso. Un caso de uso es una t´cnica que se basa en escenarios para la obtenci´n de e o requerimientos identificando una lista de interacciones particulares entre el usuario y el sistema. Un caso de uso comprende: El usuario con el que interactua el sistema (actor). Una descripci´n de la meta a alcanzar. o Suposiciones que deben conocer para para que se realice el caso de uso con ´xito. e Una lista de los pasos que se realizan entre el actor y el sistema. Variaciones o caminos alternativos para realizar la meta. Los casos de uso especifican la variedad de formas para utilizar el sistema. Estos definen las funcionalidades requeridas por el sistema. En nuestro caso los casos de uso fueron de gran ayuda para identificar servicios de misi´n cr´ o ıtica y los activos que pueden estar involucrados en el sistema. Los casos de uso desarrollados en este trabajo se realizaron en base al modelo de negocios de descrito en el C´pitulo 2. Un ejemplo de caso de uso desarrollado se a muestra en la tabla 4.4. Este caso de uso detalla las acciones del usuario con el sistema para generar una factura electr´nica, adem´s contiene excepciones de las acciones en o a caso de ocurrir alg´n funcionamiento anormal en el uso de la aplicaci´n. Una lista u o completa de todos los casos de uso desarrollados en este trabajo podr´ encontrarse a en el Ap´ndice C. e CINVESTAV Departamento de Computaci´n o
  • 57. An´lisis y dise˜o de un sistema seguro de facturaci´n electr´nica 41 a n o o Identificador Nombre Descripci´n o Precondici´n o Actores principales Secuencia normal CINVESTAV Generaci´ de factura o Acci´n “Generar Factura” o El usuario podr´n generar una factura electr´nica a un cliena o te El usuario debe de estar previamente registrado en el sistema. Usuario. Paso Acci´n o 1 El usuario selecciona la opci´n “Crear Factura” dentro el o men´ principal del sistema. u 2 El usuario selecciona el cliente de una lista de clientes registrados(contribuyente), en caso contrario se podr´ ingresar a un nuevo usuario. 3 Al seleccionar un cliente el sistema, mostrar´ los datos del a cliente tales como: Nombre de la empresa, RFC, Domicilio Fiscal, Datos y Cantidad del producto. 4 El usuario debe de de insertar los datos del producto(s) por el cu´l se desea realizar la factura. Se deben de ingresar todos a los datos del producto para poder realizar la factura. Los datos que se deben de insertar son los siguientes: Cantidad, Descripci´n, Si genera IVA, Precio Unitario. Este proceso se o realiza por cada producto o servicio del cu´l se requiera la a factura. 4.a El sistema calcula los siguientes datos: Importe, Subtotal, Precio con IVA, Retenci´n de IVA(Si aplica), Retenci´n de o o ISR(Si aplica), TOTAL 5 Una vez insertados todos los datos se muestran para confirmaci´n y se puede proceder a realizar la factura electr´nica, o o seleccionando el bot´n crear factura. o 6 Al momento de presionar el bot´n, se realizaran los siguieno tes pasos: 6a Se genera un archivo XML, con los par´metros que apliquen a para dicha factura. Estos par´metros ser´n los que que se a a especifican en el Anexo 20 secci´n C. o Departamento de Computaci´n o
  • 58. 42 Cap´ ıtulo 4 Secuencia normal Postcondici´n o Excepciones CINVESTAV Paso 6b Acci´n o Se procede a generar el sello digital de acuerdo al Anexo 20 secci´n D. Para realizar este proceso es necesario cargar la o llave privada en la memoria , al finalizar el sello digital, la llave privada debe de ser borrada de la memoria de manera segura del dispositivo. Los pasos a seguir para realizar el sello digital son los siguientes: 1) Se genera la cadena original, 2) Se recupera la llave privada desde el repositorio seguro, 3) Con la llave privada creada en memoria se realiza la firma digital de la cadena original, 4) Se borra de memoria la llave privada, 5) Se anexa al documento xml el sello digital.Si existe alg´n problema con la llave o la firma digital se u proceder´ a la excepci´n signerr. a o 6c Una vez generado el archivo XML y el sello digital, se proceder´ a enviar este archivo v´ un canal seguro hacia el a ıa cliente(contribuyente).Se guarda las facturas en el repositorio seguro. 6d Si se gener´ y se envi´ correctamente el archivo XML, el o o sistema mostrara una notificaci´n de ´xito En caso contrario o e se proceder´ a la excepci´n generr o generr2 seg´n sea el a o u caso. 7 Se muestra la opci´n de regresar al men´ principal. o u La facturas son guardadas en formato XML(solo se mantendr´n en este formato y no se tendr´ una base de datos a a relacional para su almacenamiento). Excepci´n signerr o Paso Acci´n o 1 Si en el momento de hacer la firma, la llave privada no se encuentra dentro de la memoria SD o si existe un error de entrada/salida al leer la llave privada se realizan los siguientes pasos: 1.a Si el sistema notifica un error al no encontrar la llave privada en la memoria SD el sistema notificar´ al usuario y se a cerrar´ la aplicaci´n a o 1.b Si el sistema notifica un error de entrada/salida al leer la llave privada el sistema notifica al usuario y cerrara la aplicaci´n. o Departamento de Computaci´n o
  • 59. An´lisis y dise˜o de un sistema seguro de facturaci´n electr´nica 43 a n o o Frecuencia esperada Importancia Excepci´n generr o Paso Acci´n o 1 La generaci´n del archivo tuvo un problema al momento o de escribirse a disco o no se realiza correctamente el sello digital. 2 El archivo XML no se manda correctamente al contribuyente. 3 Se lanza una notificaci´n al usuario para que vuelva a realio zar la factura Cuadro 4.4: Generaci´n de fa o Excepci´n generr2 o 1 Existe un problema de conexi´n y no se puede enviar el o archivo XML 2 El sistema guarda el archivo y lo marca como pendiente para poder mandarlo posteriormente y recuperarse de dicha excepci´n. o Cada vez que el usuario genere una factura Alta, indispensable para la generaci´n de comprobantes fiscales digitales. o Como se hab´ mencionado con anterioridad los casos de uso fueron de gran imporıa tancia ya que nos ayudaron a identificar los activos relevantes para nuestra aplicaci´n. o Un activo es un elemento que se busca proteger ante las posibles vulnerabilidades del sistema. Dentro de los activos identificados en este trabajo tenemos los siguientes: llave privada folios certificado digital cartera de clientes factura emitida y por entregar copia local de facturas emitidas y estado copia respaldo de facturas emitidas dispositivo Casos de Abuso Para dise˜ar un software confiable y seguro, es necesario anticipar comportamiento n anormal en el sistema. Los casos de abuso nos pueden ayudar a ver el software que se este dise˜ando de la misma forma que un atacante lo har´ Pensando m´s all´ de las n ıa. a a funcionalidades convencionales y contemplando eventos inesperados o negativos en el sistema. CINVESTAV Departamento de Computaci´n o
  • 60. 44 Cap´ ıtulo 4 Los casos de abuso de uso son similares a los casos de uso tradicionales, excepto que estos est´n hechos para detallar un abuso, amenaza o vulnerabilidad de el sistema a y como este podr´ solucionarse. ıa Los casos de abuso nos fueron de gran ayuda en el dise˜o del sistema de facturan ci´n electr´nica particularmente en la obtenci´n de los requerimientos de seguridad, o o o adem´s de que nos ayudo a reconocer los ataques a los que podr´ estar expuesta a ıa nuestra aplicaci´n proporcionando un conjunto de recomendaciones para mitigar esas o vulnerabilidades. Un ejemplo de caso de abuso desarrollado en este trabajo se muestra a continuaci´n: o Numero: Nombre: Alcance: Prioridad: Ambiente: Anti-Actores: Niveles de derecho de acceso: Puntos de entrada: Atributos de seguridad afectados: Descripci´n: o Precondiciones: Suposiciones: Post-Condiciones: Perfiles de potenciales anti-actores: Clientes y amenazas: Amenazas relacionadas: Recomendaciones arquitecturales: Pol´ ıticas de Recomendaci´n: o MC-01 Genera Factura sin acceso a llave privada(residual) Compromete la misi´n de la aplicaci´n o o Prioridad Alta Host y Aplicaci´n. o Usuarios no Autorizados Nivel Usuario Nivel Administrador Aplicaci´n o Autenticidad de la informaci´n,no repudio o Una vez que se ha generado una factura previa, es posible que la llave privada haya quedado en memoria. Dicha copia podr´ usarse ıa para generar una factura posteriormente y sin que esto requiera verificar al contenedor de la llave privada. Se accede a la llave privada para firmar una factura electr´nica o de forma local en el dispositivo(se requiere que por lo menos se haya generado una firma para poder realizar el ataque). Se accede al proceso gen factura() y se mantiene en memoria la copia de la llave privada. No se inicializ´ la variable que contiene la llave o privada. No se cerro la sesi´n de la applicaci´n. Se tenian folios o o cargados en el dispositivo. Se supone que este ataque se realiza mediante el robo del dispositivo. Peor Caso Se genera f´ctura v´lida a a sin aviso al contribuyente Medida de prevenci´n deseada o -Blanquear llave privada -Lock de la aplicaci´n. o Medida de detecci´n deseada o -Bitacora de la aplicaci´n o realizando un corte diario -Cruce de las facturas emitidas contra el SAT. Medidia de recuperaci´n deseada. -Revocar la llave privada. o -Litigio. Usuarios sin conocimiento t´cnico agudo. e Clientes: creaci´n de facturas sin consentimiento del contribuyeno te. Elevaci´n de privilegios, acceso no autorizado a la ino terfaz,autenticidad de los datos, usurpaci´n de la identio dad,repudiaci´n de la informaci´n. o o -Se debe de realizar un bloqueo de la aplicaci´n cada 10 min si la o aplicaci´n no esta en uso.-Cada vez que se realice un factura se de o pedir el password de la aplicaci´n o la del acceso a la llave privada.o Crear bitacoras de las operaciones dela aplicaci´n.-Blanqueo de la o llave privada cada vez que se ocupe. -Realizar cortes de caja al d´ y ver las facturas que se han emitidoıa El password que se utilice para generar la factura electr´nica debe o de ser cambiado peri´dicamente.-Contar con pol´ o ıticas para contrase˜as fuertes.-Acciones de usuarios deben de ser revisadas pen ri´dicamente. o Cuadro 4.5: Caso del Mal Uso MC-01 CINVESTAV Departamento de Computaci´n o
  • 61. An´lisis y dise˜o de un sistema seguro de facturaci´n electr´nica 45 a n o o Como se puede apreciar los casos de abuso casi contiene los mismos par´metros a que contendr´ un caso de uso convencional, sin embargo tambi´n conceptualiza las ıa e medidas de seguridad que deber´ tomarse si este ataque fuera exitoso, incluyendo ıan las prevenciones que deber´ de realizarse pare prevenir, detectar y recuperarse de ıan ese ataque. Otro aspecto a resaltar en la realizaci´n de los casos de abuso es que en o cada caso de abuso se agrego el apartado Amanezas relacionadas. Este apartado nos sirvi´ para ver las amenazas al que el sistema esta expuesto en caso de que el caso o de abuso se realice con ´xito, esta clasificaci´n se realiz´ de acuerdo al sistema de e o o clasificaci´n STRIDE. Una lista completa de todos los casos de uso desarrollados en o este trabajo podr´ encontrarse en el Ap´ndice D. a e ´ Arboles de ataque Un ´rbol de ataque muestra una vista potencial de forma jer´rquica de como se a a realiza un ataque en un sistema, basado en como los ataques pueden realizarse. A continuaci´n se muestra el siguiente ´rbol de ataque para el caso de la aplicaci´n de o a o factura electr´nica. o Figura 4.1: Modelo operativo de la Facturaci´n Electr´nica o o En la figura 4.1 se muestra un sub´rbol de ataque que corresponde a la acci´n a o malintencionada de una modificaci´n o eliminaci´n de una factura electr´nica. En el o o o ejemplo se supone que un adversario ha obtenido acceso al dispositivo donde se emite la factura. El nodo ra´ representa el objetivo del adversario a realizar para nuestro ız caso se denot´ bajo la leyenda ganar acceso al dispositivo. Cada nodo no ra´ o ız representa un submeta, y los hijos de ese nodo son formas de realizar dicha meta. Se puede notar que los ´rboles de ataque existen nodos con compuertas OR o AND. a Todos los nodos compuertas OR representan alternativas para cumplir el objetivo de el nodo padre. Por ejemplo en la figura para realizar robo de password este se podr´ ıa CINVESTAV Departamento de Computaci´n o
  • 62. 46 Cap´ ıtulo 4 obtener por ataque de fuerza bruta o por ingenier´ social. Un ´rbol tambi´n puede ıa a e contener nodos con compuertas AND las cuales representan los diferentes pasos que se deben para que el adversario realice el objetivo del nodo padre. Una vista completa de los arboles de ataque desarrollados en este trabajo podr´ encontrarse en el ap´ndice a e C. Estimaci´n de riesgos o Una vez obtenidos los activos y las amenazas a las que podr´ estar expuesto el ıa sistema atrav´s del uso de herramientas como lo fueron casos de uso, casos de uso y e arboles de ataque, es necesario realizar una estimaci´n del estado de riesgo del sistema. o Es decir, una estimaci´n de la afectaci´n de los activos, para descubrir aquellos que o o se encuentren m´s vulnerables, lo cu´l ayudar´ al momento de decidir como priorizar a a a los requerimientos de seguridad y as´ minimizar los riesgos de la aplicaci´n. ı o En esta fase de estimaci´n de riesgos, se estima el impacto al que est´n expuestos o a los activos del sistema, se tom´ en cuenta el impacto potencial al que est´ expuesto o a el sistema teniendo en cuenta el valor de los activos y la valoraci´n de las amenazas. o Para los c´lculos del valor del activo se utiliz´ la siguiente escala: a o B: Bajo M: Medio A: Alto Por otra parte, para valoraci´n de las amenazas a las que esta expuesto el sistema o se realiz´ una priorizaci´n de los casos de abuso, se decidi´ clasificarlos de acuerdo al o o o efecto que tendr´ sobre todo el sistema. Se realiz´ un concentrado para evaluar cada ıa o caso de abuso. Los niveles de valoraci´n de las amenazas se basaron en una escala de o 10 de acuerdo a los siguientes rangos: 1-3= Baja, 4-6= Media, 7-10 = Alta. La tabla 4.6 muestra la clasificaci´n de los casos de abuso: o Caso de Abuso MC-01 MC-02 MC-03 MC-04 MC-05 MC-06 MC-07 MC-08 MC-09 MC-10 MC-11 MC-12 Rango 10 7 7 3 3 5 3 5 3 5 8 5 Valoraci´n de las amenazas o Alta Alta Alta Baja Baja Media Baja Media Baja Media Alta Media Cuadro 4.6: Priorizaci´n de los casos de abuso o CINVESTAV Departamento de Computaci´n o
  • 63. An´lisis y dise˜o de un sistema seguro de facturaci´n electr´nica 47 a n o o Adem´s, para el c´lculo del riesgo, se utiliz´ la notaci´n de la Tabla 4.2 a a o o Figura 4.2: C´lculo de impacto a Tomando en cuenta el valor de los ´ctivos y la valoraci´n de las amenazas de a o los casos de los casos de abuso, se realiz´ el c´lculo de estimaci´n de impacto, el o a o resultado se encuentra concentrado en la Tabla 4.7. Para el c´lculo de la posibilidad a de ocurrencia se calculo el promedio de acuerdo a los valores n´mericos de priorizaci´n u o de los casos de abuso presentados en la tabla 4.6. Activo CFD CFD CFD Llave privada Llave privada Llave privada Folios Propiedad Disponibilidad Integridad Confidencialidad Disponibilidad Integridad Confidencialidad Disponibilidad Valor A A M A A A M Folios Folios Certificado digital Integridad Confidencialidad Disponibilidad M M A Certificado digital Certificado digital Cartera de clientes Cartera de clientes Integridad Confidencialidad Disponibilidad Integridad A B M M Cartera de clientes Confidencialidad A Reporte mensual Reporte mensual Reporte mensual Aplicaci´n o Disponibilidad Integridad Confidencialidad Disponibilidad M M M A Aplicaci´n o Aplicaci´n o Dispositivo Dispositivo Integridad Confidencialidad Disponibilidad Integridad A B A A Dispositivo Confidencialidad Servidor Disponibilidad Servidor Integridad Servidor Confidencialidad Cuadro 4.7: Estimaci´n de riesgo o B A A M CINVESTAV Caso de Abuso MC-02 MC-06,MC-11 MC-02,MC-11 MC-01,MC-02 MC-03 MC-01,MC-02 MC-01,MC-02,MC03,MC-07 MC-03 MC-01,MC-02 MC-01,MC-02,MC03,MC-07 MC-03,MC-05 MC-01,MC-02 MC-06,MC-07 MC-06,MC-07,MC09,MC-11 MC-06,MC-07,MC09 MC-06 MC-06,MC-10 MC-06,MC-10 MC-03,MC-04,MC06,MC-07,MC-09 MC-02,MC-03 Posibilidad de ocurrencia 7 Alta 6.5 Media 7.5 Alta 8.5 Alta 7 Alta 8.5 Alta 6.75 Alta Impacto A A A A A A A 7 Alta 8.5 Alta 6.75 Alta A A A 5 Media 8.5 Alta 4 Media 4.75 Media A M M M 3.66 Media A 5 Media 5 Media 5 Media 4.2 Media M M M A 7 Alta MC-06 MC-01,MC-02,MC03,MC-04,MC05,MC-08,MC09,MC-11 5 Media 5.75 Media A B A A Baja 5 Media 5 Media 5 Media B A A M MC-06 MC-12 MC-12 Departamento de Computaci´n o
  • 64. 48 Cap´ ıtulo 4 4.2.4. Resultados de la metodolog´ SQUARE Lite ıa Como resultado de la aplicaci´n de las etapas desarrolladas durante el trabajo o realizado con el uso de la metodolog´ SQUARE Lite, se han podido identificar y dar ıa prioridad a los requerimientos de seguridad. Se desarroll´ una clasificaci´n dividido o o de acuerdo a las siguientes m´tricas: e Esenciales: implica que el producto no ser´ aceptable a menos que estos rea querimientos se cumplan. Condicionales: implica que estos requerimientos podr´ mejorar el producto, ıan pero el producto no ser´ inaceptable si estos est´n ausentes. ıa a Opcionales: implica una clase de funciones que pueden o no ser completamente necesarias. Cada requerimiento fue clasificado de acuerdo a las m´tricas de arriba. Los ree querimientos esenciales todos corresponden directamente a las amenazas m´s altas a realizadas al resultado de estimaci´n de riesgo. o Requerimientos Esenciales de Seguridad En nuestro an´lisis, estos 12 requerimientos de seguridad fueron considerados como a esenciales: RS-1 Definici´n de Arquitectura de Informaci´n: Describir el proceso de o o arquitectura de informaci´n para ubicar la l´gica de negocio y las m´tricas de seguo o e ridad. RS-2 Control de Acceso: Para ingresar al sistema es necesario introducir el nombre de usuario y password. El password que se introduzca debe de estar basado en un est´ndar deber´ de contener letras, n´meros y caract´res especiales. Datos de a a u e la aplicaci´n como la contrase˜a de la aplicaci´n debe de ser secreto. o n o RS-3 Blanqueado de memoria: Par´metros cr´ a ıticos de seguridad como la llave privada y la contrase˜a de acceso deben de ser blanqueados de memoria cuando no n sean utilizados. RS-4 Protecci´n de par´metros cr´ o a ıticos de seguridad: Par´metros cr´ a ıticos de seguridad como la llave privada debe de ser protegida, de acceso no autorizado, divulgaci´n, modificaci´n o sustituci´n. o o o RS-5 Protecci´n de par´metros p´ blicos de seguridad: Par´metros p´blio a u a u cos de seguridad como los certificados digitales y folios deben de ser protegidos, de acceso no autorizado, divulgaci´n, modificaci´n o sustituci´n. o o o CINVESTAV Departamento de Computaci´n o
  • 65. An´lisis y dise˜o de un sistema seguro de facturaci´n electr´nica 49 a n o o RS-6 Autoprueba del sistema: La aplicaci´n debe de realizar una funci´n de o o autoprueba para comprobar la integridad de par´metros como: llave privada, folios y a cartera de clientes. RS-7 Canal seguro: Par´metros p´blicos de seguridad tales como la cartera de a u cliente y los comprobantes fiscales digitales deben de ser transportados electr´nicao mente atrav´s de un canal seguro. e RS-8 Validaci´n de entradas y s´lidas: Se debe de hacer una validaci´n de o a o todas las entradas y salidas de la aplicaci´n una vez que la aplicaci´n se encuentre en o o un ambiente operativo. RS-9 Protecci´n de ataques f´ o ısicos: Mediante un respaldo de la informaci´n o sensitiva en el dispositivo se tendr´ que respaldar la informaci´n en un servidor. a o RS-10 Almacenamiento Seguro: Se debe de buscar que las facturas electr´nio cas se guarden en un almacenamiento seguro en el servidor. Despues de que la informaci´n sea respaldada, la cartera de clientes debe de ser cifrada en el servidor o seguro. RS-11 Protecci´n de datos ante aplicaciones externas: Otras aplicaciones o no podr´n acceder a los datos de la aplicaci´n de facturaci´n electr´nica. Esto es, a o o o otras aplicaciones no podr´ acceder a los datos como CFD’s, certificados digitales, a folios digitales, informaci´n de los clientes y contrase˜a que se encontraran guardados o n en la memoria SD. RS-12 Bloqueo de la aplicaci´n: Despu´s de cierto tiempo la aplicaci´n debe o e o de bloquearse para evitar que usuarios no autorizados no acceda a informaci´n privada o de usuario o generen facturas sin consentimiento del contribuyente Estos 12 requerimientos abordan directamente las dimensiones de seguridad de integridad, autenticaci´n, confidencialidad, disponibilidad y amenazas f´ o ısicas. Consideramos que estos requerimientos de seguridad son esenciales para el sistema de facturaci´n electr´nica, sin cumplir estos requerimientos, no se podr´ considerar que o o ıa el sistema es seguro ante las principales amenazas que afecten al sistema. Estos requerimientos deben de estar impactados en el dise˜o e implementaci´n del sistema n o Requerimientos Condicionales de Seguridad En nuestro an´lisis, estos 5 requerimientos de seguridad fueron considerados como a condicionales. Cumplir con estos requerimientos de seguridad a˜adiran cierta segurin dad al sistema de facturaci´n electr´nica pero no son necesariamente esenciales para o o defender la aplicaci´n de facturaci´n electr´nica: o o o RS-13 Firma de la aplicaci´n: El c´digo ejecutable de la aplicaci´n debe de o o o ser firmado. RS-14 Servidor: El servidor que se utilice para realizar el respaldo de CFD’s debe ser protegido ante ataques pasivos o activos. CINVESTAV Departamento de Computaci´n o
  • 66. 50 Cap´ ıtulo 4 RS-15 Uso de t´cnicas de dise˜ o e implementaci´n seguras: Durante el e n o desarrollo del proyecto se har´ uso de t´cnicas de modelado de seguridad. a e RS-16 Uso de Buenas pr´cticas de codificaci´n: Para la implementaci´n de a o o la aplicaci´n se debe de usar buenas pr´cticas de codificaci´n segura en el lenguaje o a o JAVA. RS-17 Evitar ataques DoS: El servidor siempre debe se estar disponible cuando la aplicaci´n lo requiere (Evitar ataques de tipo DOS). o Debido a que en este trabajo el caso de estudio es una aplicaci´n m´vil de faco o turaci´n electr´nica, la protecci´n del servidor es considerada como condicional sin o o o embargo es conveniente la implementaci´n de estos requerimientos. o El requerimiento RS-15 y RS-16 deber´ ser considerado ya que el uso de mejores ıa pr´cticas pueden disminuir las vulnerabilidades a las que est´ expuesto el sistema. a a Requerimientos Opcionales de Seguridad En nuestro an´lisis, estos 3 requerimientos de seguridad fueron considerados como a opcionales: RS-18 Actualizaci´n del Servidor: El servidor debe ser actualizado con cierta o frecuencia (2 Meses). RS-19 Pol´ ıticas de servidor: Se deben de bloquear todos los puertos, protocolos y servicios que no sean necesarios en el servidor. RS-20 Roles de Usuario: En el sistema deben de existir dos perfiles de usuario: Perfil de usuario de confianza: Usuario com´n que podr´ realizar las funciones u a de facturaci´n electr´nica, envio de reportes mensuales, configuraciones b´sicas. o o a Perfil de administrador: Usuario que podr´ realizar funciones avanzadas. a Estos requerimientos de seguridad agregar´ cierta seguridad al sistema de facıan turaci´n electr´nica. En base a nuestra estimaci´n de riesgos se determin´ que estos o o o o requerimientos son opcionales, y no son necesarios. Por ejemplo el requerimiento de seguridad RS-20, no es necesario ya que el uso de los dispositivos m´viles es indio vidual, la segregaci´n de funciones resulta complicada, sin embargo considerar este o requerimiento podr´ ser considerado como condicional en un sistema de facturaci´n ıa o electr´nica de mayor escala. o CINVESTAV Departamento de Computaci´n o
  • 67. An´lisis y dise˜o de un sistema seguro de facturaci´n electr´nica 51 a n o o 4.3. 4.3.1. Arquitectura Criterios de dise˜ o n Debido a que desarrollo de este trabajo se har´ bajo la plataforma Android y dada a la naturaleza de la aplicaci´n de facturaci´n electr´nica, donde la l´gica de negocio o o o o puede variar con el tiempo y las reglas de negocio podr´n modificar a las actuales y a nutrirse de otras nuevas. Es por eso que el modelado se har´ utilizando programaci´n a o orientada a objetos, formando as´ objetos muy similares a la realidad que se rigen por ı las reglas de negocio. Para poder acompa˜ar los cambios del negocio, actualizando as´ el modelo del n ı dominio, se busc´ la manera de mantener este dominio lo mas aislado posible del o resto de la aplicaci´n. Para ello la arquitectura elegida es una arquitectura basada o en capas l´gicas (Layer Pattern). Buscando que esta arquitectura sea escalable y o lo m´s segura posible, es deseable poder distribuir la arquitectura en capas l´gicas a o y poder buscar el mayor desacoplamiento entre ellas. En la Figura 4.3 podemos ver como quedaron distribuidas las diferentes partes de la aplicaci´n sobre la arquitectura o propuesta. Figura 4.3: Arquitectura en capas CINVESTAV Departamento de Computaci´n o
  • 68. 52 Cap´ ıtulo 4 4.3.2. An´lisis del dise˜ o a n Definida la arquitectura a utilizar, a continuaci´n se analiza el dise˜o de cada capa o n del dise˜o. n Capa de presentaci´n o Esta es la capa que interactua con el usuario final, es la encargada de presentar la informaci´n y recolectarla para hacer uso de los servicios expuestos por la capa de o servicio, para satisfacer los casos de uso de la aplicaci´n. o En este trabajo como se mencion´ con anterioridad se har´ bajo la plataforma Ano a droid. Android utiliza la clase Activity para delegar la capacidad de presentaci´n. o Las actividades de Android son esenciales ya que forman las pantallas de la aplicaci´n o y desempe˜an un papel en el ciclo de vida de una aplicaci´n en Android. Las actin o vidades est´n formadas por componentes secundarios denominados vistas. Las vistas a son lo que ven los usuarios y con lo interact´an. Controlan el dise˜o, proporcionan u n elemento de texto para etiquetas e informaci´n, botones y formularios para entrao das del usuario, y dibujan gr´ficos en la pantalla. Tambi´n se utilizan para registrar a e oyentes de la interfaz, como los de controles de pantallas t´ctiles. Las vistas y otros a componentes de Android utilizan cadenas, colores, estilos y gr´ficos a los cuales se a conocen como recursos. La figura 4.4 muestra la relaci´n entre actividades vistas y o recursos. Figura 4.4: Diagrama de relaci´n entre Activity, View, recursos y manifesto o CINVESTAV Departamento de Computaci´n o
  • 69. An´lisis y dise˜o de un sistema seguro de facturaci´n electr´nica 53 a n o o Figura 4.5: Ejemplo de dashboard Por otra parte para optimizar el dise˜o de la interfaz de usuario se usaron los n siguientes patrones de dise˜o de interfaces de usuario: n Dashboard: Un dashboard es una pantalla de bienvenida de la aplicaci´n dano do un punto de entrada para la el usuario. El dashboard puede ser est´tico o a din´mico. En la pantalla del dashboard se muestra las acciones importantes o a que se usaran con frecuencia en la aplicaci´n en forma de categor´ Las cateo ıas. gor´ son representadas con un icono y su t´ ıas ıtulo y se encuentran en pantalla completa en una orientaci´n de grid. Este patr´n permite que el usuario eno o cuentre el contenido de una forma m´s f´cil. Un ejemplo de dashboard se puede a a ver en la figura 4.5 Barra de acci´n La barra de acci´n se encuentra localizada en la parte alta o o de la pantalla y muestra funcionalidades importantes, por lo regular se ocupa para realizar opciones de b´squeda, refrescar datos y composici´n. Un ejemplo u o del patr´n barra de acci´n puede verse en la figura 4.6. o o Barra de b´ squeda: La barra de b´squeda esta anclada en la parte de arriba u u de la pantalla y remplaza la barra de acciones. Contiene 3 elementos: un campo de texto permitiendo al usuario introducir los par´metros de b´squeda, el bot´n a u o de b´squeda y un selector de popup para m´ltiples b´squedas. Este patr´n u u u o ser´ conveniente adoptarlo para nuestro sistema de facturaci´n electr´nica ya a o o que se podr´n realizar b´squedas m´ltiples. Un ejemplo del patr´n barra de a u u o busqueda puede verse en la figura 4.7. CINVESTAV Departamento de Computaci´n o
  • 70. 54 Cap´ ıtulo 4 Figura 4.6: Ejemplo de barra de accion Figura 4.7: Ejemplo de barra de busqueda CINVESTAV Departamento de Computaci´n o
  • 71. An´lisis y dise˜o de un sistema seguro de facturaci´n electr´nica 55 a n o o Capa de servicios La capa de servicios es la que se encarga de brindar los servicios necesarios a la capa de presentaci´n. En nuestro caso esta capa se encargar´ de facilitar la creaci´n o a o de facturas electr´nicas. Para el dise˜o de esta capa se hizo uso del patr´n de dise˜o o n o n fachada. El patr´n fachada provee una interfaz unificada a un conjunto de interfaces o en un subsistema, definiendo una interfaz de m´s alto nivel para que el subsistema a sea m´s f´cil de usar. a a Los objetos intercambiadas entre las capas de servicio y de presentaci´n ser´n o a objectos del tipo Data Transfer Object, que son simples objetos simples (POJO) utilizados en el intercambio de informaci´n. o En el diagrama de clases de la figura 4.8 se puede ver el dise˜o para la creaci´n n o de facturas electr´nicas usando el patr´n de dise˜o fachada. o o n Figura 4.8: Patr´n fachada para cfd o Capa de persistencia La capa de persistencia es la encargada de abstraer y resolver el acceso a datos en cualquier modelo de base de datos. El objetivo es ser la unica que conoce co´ mo son persistidos los objetos de la aplicaci´n y como recuperarlos abstrayendo las o impedancias entre objetos y la fuente de datos. La capa superior o de vista no interact´a directamente con la base de datos, si no u que lo hace mediante la interfaz expuesta por la capa de persistencia. Esto permite cambiar la estrategia con que se persisten los objetos, incluso cambiar la tecnolog´ ıa o el motor utilizado sin impactar m´s all´ de ´sta capa. a a e CINVESTAV Departamento de Computaci´n o
  • 72. 56 Cap´ ıtulo 4 Algunos de los requerimientos buscados por la capa de persistencia son los siguientes: Encapsular los mecanismos de persistencia (utilizando m´todos del estilo: sae ve(obj), delete(obj),create(obj), find(obj)). Identificaci´n de objetos. o Manejo de transacciones. Posibilidad de realizar consultas. En la Figura 4.9 puede observarse el mecanismo de persistencia, donde una clase de la capa de presentaci´n solicita una b´squeda con ciertos par´metros a partir de o u a un criterio dado. Figura 4.9: Diagrama de secuencia: persistencia de datos Por otra parte se hace uso del patr´n de de dise˜o Data Access Object(DAO) o n que nos permitir´ una interfaz abstracta atrav´s de un mecanismo de persistencia sin a e o exponer los detalles de la base de datos. En la figura 4.10 se muestra la vista l´gica de como se aplic´ este patr´n de dise˜o atrav´s de este diagram´ de clases. Como o o n e a mecanismo para guardar datos se utilizar´ una base de datos XML. a CINVESTAV Departamento de Computaci´n o
  • 73. An´lisis y dise˜o de un sistema seguro de facturaci´n electr´nica 57 a n o o Figura 4.10: Patr´n de persistencia DAO o La clase XMLHelper presentada en la figura 4.10 nos ayudar´ a leer estos datos a del documento XML y deserializarlos en objetos POJO que contienen la l´gica de o negocio del sistema de facturaci´n electr´nica y as´ poderlos manipularlos de manera o o ı m´s sencilla. Para la serializaci´n de documentos XML a objetos POJO se hiz´ uso a o o de la bibloteca SIMPLE [6]. 4.3.3. Arquitectura de seguridad Una arquitectura de seguridad describe como el sistema conjunta mecanismos de seguridad apropiados para satisfacer los requerimientos de seguridad, y de esta forma proteger el sistema ante amenazas. En este trabajo se ha realizado una arquitectura de seguridad donde se defini´ un conjunto de componentes de seguridad que cubren la o mayor´ de los requerimientos de seguridad especificados con la metodolog´ SQUAıa ıa RE. Esta arquitectura de seguridad protege al sistema de facturaci´n electr´nica y o o ofrece el soporte necesario para asegurar que los requerimientos de seguridad sean cubiertos. Esta arquitectura de seguridad debe de ser integrada a la arquitectura propuesta anteriormente a˜adiendo una nueva capa de seguridad que contribuye con aspectos de n seguridad convirtiendo esta arquitectura de software convencional en una arquitectura de software segura que ser´ implementada subsecuentemente. La arquitectura final a del sistema de facturaci´n electr´nica agregando una capa de seguridad adicional o o quedar´ de la siguiente manera como se muestra en la figura 4.11. ıa CINVESTAV Departamento de Computaci´n o
  • 74. 58 Cap´ ıtulo 4 Figura 4.11: Componentes de seguridad Los componentes de seguridad de esta capa de seguridad ser´n definidos a trav´s a e de la extensi´n UMLSEC. Estos componentes de seguridad servir´n como referencia o a para cualquier dise˜o aplicaciones m´viles de facturaci´n electr´nica e incluso un subn o o o conjunto de estos componentes podr´n servir para aplicaciones basadas en escritorio a o aplicaciones web de facturaci´n electr´nica. A partir de los requerimientos de seo o guridad obtenidos por la metolog´ SQUARE se realiz´ el modelado de componentes ıa o utilzando la herramienta de seguridad UMLSEC. A continuaci´n se muestra como o se realiz´ el dise˜o de los componentes de seguridad para el sistema de facturaci´n o n o electr´nica. o Canal Seguro Para el modelado de este componente se consideran los requerimientos referentes a proteger las comunicaciones entre el dispositivo m´vil y el servidor de respaldo. El o dise˜o corresponde a los siguientes requerimientos RS-7, RS-9 y RS-10 de nuestra n fase an´lisis de requerimientos. a Podemos ver que en estos requerimientos necesitamos proporcionar privacidad entre los elementos, es decir se requiere preservar la privacidad entre los datos enviados entre el dispositivo m´vil y el servidor de resplado y una vez que la informaci´n o o como la cartera de clientes llegue al servidor est´ informaci´n debe ser protegida. a o Bajo estas directivas se aplic´ el estereotipo << data security >> que es usado o para asegurar que los requerimientos de seguridad dados por los estereotipos << CINVESTAV Departamento de Computaci´n o
  • 75. An´lisis y dise˜o de un sistema seguro de facturaci´n electr´nica 59 a n o o critical >> y las etiquetas asociadas se cumplan. La figura 4.12 da una especificaci´n o de un subsistema de comunicaciones de un objeto emisor (dispositivo m´vil) a un o objeto receptor (servidor de respaldo). En el subsistema, el objeto emisor supone aceptar un valor d que corresponde a los datos que ser´n enviados (comprobante a fiscales, cartera de clientes) al objeto receptor. Los datos enviados del dispositivo m´vil ser´ enviado de forma cifrada ( << encrypted >> ) por medio de la red. o a De acuerdo al estereotipo << critical >> y la etiqueta {secrecy} se guardar´ la a privacidad de los datos enviados. Para este componente se defini´ un adversario por o defecto, las acciones que puede realizar el adversario estan resumidas en la tabla 4.8. Stereotype Internet encrypted Threatsdef ault() delete,read, insert delete Cuadro 4.8: Acciones del adversario Figura 4.12: Subsistema de comunicaciones CINVESTAV Departamento de Computaci´n o
  • 76. 60 Cap´ ıtulo 4 Control de acceso El control de acceso se refiere a proteger el acceso a la aplicaci´n ante personas no o autorizadas, para realizar el acceso al sistema este se har´ atrav´s de un sistema de a e autenticaci´n basado en algo conocido, en este caso ser´ el nombre de usuario y una o a contrase˜a. La interacci´n para lograr la autenticaci´n se muestra en la figura 4.13 n o o en el diagrama de secuencia. Figura 4.13: Diagrama de Secuencia: control de acceso El dise˜o de este componente cubre el requerimiento de seguridad RS-2 donde n el elemento de autenticaci´n como el password de usuario debe mantenerse secreto. o Para cubrir este requerimiento se utilizar´ el estereotipo guarded access el cu´l nos a a indica que cada objecto en el subsistema estereotipado como << guarded >> solo puede ser accedido por medio de objetos que tengan la etiqueta {guard} ligados al objeto << guarded >>. En nuestro caso el objecto el cu´l se debe de mantenerse a guardado es el password por lo tanto deber´ ser etiquetado de la siguiente forma a {guard = password}. En la figura 4.14 se puede ver el modelado de este componente por medio del diagrama de clases. CINVESTAV Departamento de Computaci´n o
  • 77. An´lisis y dise˜o de un sistema seguro de facturaci´n electr´nica 61 a n o o Figura 4.14: Diagrama de Clases: control de acceso Contenedor de seguro El componente de contenedor seguro ser´ el encargado de mantener los datos a sensitivos de la aplicaci´n confidenciales, para que personas no autorizadas no puedan o acceder a este contenido. Un ejemplo de uso del contenedor seguro se muestra en la figura 4.15, donde una vez que se realiza alguna acci´n (inserci´n, modificaci´n, o o o borrado) sobre la capa de persistencia de nuestra aplicaci´n, los datos deben de ser o guardados y cifrados en un contenedor seguro. El dise˜o de este componente cubre los requerimientos RS-4,RS-5, RS-10 y RSn 11 de nuestra fase an´lisis de requerimientos. Para el dise˜o de este subsistema se a n har´ uso del estereotipo << no down − f low >> el cu´l pretende prevenir de fuga de a a informaci´n o corrupci´n de los datos. Este esteoreotipo permite dar especial atenci´n o o o en el flujo de informaci´n segura con el uso de la etiqueta {high} asociado con el o estereotipo << critical >> que nos ayudar´ a proteger la fuga de los datos marcados a con esta etiqueta. El dise˜o de este componente se puede ver en el diagrama de clases n de la figura 4.16. Autoprueba del sistema El componente de autoprueba del sistema se encargar´ de verificar que datos a sensitivos, como lo es la llave privada, certificados, cartera de clientes o folios no sean modificados, en caso de que alguno de estos componentes se haya alterado, el CINVESTAV Departamento de Computaci´n o
  • 78. 62 Cap´ ıtulo 4 Figura 4.15: Diagrama de secuencia: contenedor seguro Figura 4.16: Diagrama de clase: contenedor seguro CINVESTAV Departamento de Computaci´n o
  • 79. An´lisis y dise˜o de un sistema seguro de facturaci´n electr´nica 63 a n o o Figura 4.17: Diagrama de clase: Autoprueba sistema denegar´ el acceso a la aplicaci´n. El dise˜o de este componente impacta a o n directamente al requerimiento de seguridad RS-6. En el dise˜o de este sistema se n hiz´ uso del estereotipo << no down − f low >> en este caso lo que se intenta con o este estereotipo es que no exista corrupci´n en los datos manteniendo as´ la integridad o ı de los datos con la etiqueta {integrity} asociado con el estereotipo << critical >>. El dise˜o de este componente se puede ver en el diagrama de clases de la figura 4.17. n Firma electr´nica o El componente de firma de electr´nica ser´ el encargado de firmar la cadena o a original del comprobante fiscal digital. El dise˜o de este componente no corresponde n a ning´n requerimiento de seguridad de nuestra fase de an´lisis de requerimientos de u a seguridad sin embargo es un requerimiento funcional de la aplicaci´n. Para el dise˜o o n de este componente se usar´ el estereotipo << critical >> que se puede usar con a la etiqueta {authenticity} que nos servir´ para mostrar la autenticidad del origen a n de la factura electr´nica. En la figura 4.18 se puede ver como fue el dise˜o de este o componente. Bloqueo de la aplicaci´n o Este componente de seguridad debido a su naturaleza no requiere ser modelado con la extensi´n UMLSEC, ya que no contiene manejo de informaci´n sensitiva sin o o embargo se considera un componente de seguridad ya que nos permite que no exista CINVESTAV Departamento de Computaci´n o
  • 80. 64 Cap´ ıtulo 4 Figura 4.18: Diagrama de clase: Firma electr´nica o Figura 4.19: Diagrama de clase: Bloquear aplicaci´n o fuga de informaci´n cuando el dispositivo no se encuentre en uso. En la figura 4.19 el o dise˜o de este componente. n CINVESTAV Departamento de Computaci´n o
  • 81. Cap´ ıtulo 5 Implementaci´n y pruebas o En cap´ ıtulos anteriores se ha mostrado el modelo operativo de un sistema de facturaci´n electr´nica, explicando tanto los requerimientos legales del Sistema de Admio o nistraci´n Tributaria, requerimientos funcionales, requerimientos de seguridad y una o arquitectura de seguridad para este tipo de aplicaciones. En base a estos par´metros a en este este cap´ ıtulo se har´ una descripci´n de la implementaci´n de los componentes a o o de seguridad de para as´ formar as´ una aplicaci´n segura de facturaci´n electr´nica. ı ı o o o 5.1. Codificaci´n Segura o Desarrollar aplicaciones robustas de software que sean libre de vulnerabilidades es una tarea d´ ıficil, y hacerlas totalmente seguras es imposible. Sin embargo el uso de pr´cticas de codificaci´n segura que nos puede ayudar significativamente a reducir a o defectos, vulnerabilidades e errores de software. Las pr´cticas de codificaci´n segura a o requiere un entendimiento de los errores de programaci´n que pueden llevar a vulneo rabilidades. Dentro de este trabajo se siguieron las siguientes pr´cticas de codificaci´n a o segura: Asegurar que las variables se inicialicen correctamente, no depender de inicializaci´n por defecto [12]. o Comprobar expl´ ıcitamente todas las llamadas al sistema o los valores de retorno de m´todos o funciones [12]. e Asegurar que los archivos no se puedan abrir utilizando rutas relativas de archivos o referencias indirectas de archivo [12]. Evitar la invocaci´n de programas de menos de confianza, como shells de coo mandos, desde el interior de nuestra aplicaci´n [12]. o 65
  • 82. 66 Cap´ ıtulo 5 Evitar el uso de generadores de n´meros pseudo-aleatorios en su lugar, utilizar u una API para generar n´meros pseudo-aleatorios de una manera criptogr´ficau a mente segura [12, 13]. Poner en pr´ctica el manejo de excepciones de forma segura y asegurar que la a informaci´n sensible no se filtre [13]. o Proteger datos secretos mientras se encuentran almacenados en la memoria (llaves criptogr´ficas, contrase˜as) [13]. a n Evitar el hard-coding de datos secretos (por ejemplo, contrase˜aas, llaves cripn togr´ficas), cifrar y almacenarlos en archivos externos [13]. a Usar enunciados parametrizados en las consultas de base de datos (para evitar inyecci´n SQL) [13]. o Eliminar el c´digo que es obsoleto o que no se utiliza [12, ?]. o Adicionalmente a estas pr´cticas se han adoptado algunas otras que son parte a del propias del lenguaje Java. Estas pr´cticas de codificaci´n segura en Java pueden a o encontrarse en [3]. 5.1.1. Revisi´n de c´digo o o La revisi´n de c´digo ocupa un lugar importante en la lista de buenas pr´cticas o o a que est´n destinadas a mejorar la seguridad del software. Para ayudarnos a realizar a esta tarea existen herramientas para verificar errores e inconsistencias en el c´digo o antes de compilarse, a este tipo de herramientas se les conoce como herramientas de an´lisis est´tico. a a Para realizar la revisi´n de c´digo se utiliz´ la herramienta FindBugs que es o o o una herramienta de c´digo est´tico que nos permite visualizar errores y violaciones o a en c´digo Java. La herramienta FindBugs se ejecut´ al concluir la codificaci´n del o o o proyecto, mostrando alrededor de 174 errores como se muestra en la figura 5.1. Dentro de los cuales 76 son de prioridad alta, 68 de prioridad media y 30 de prioridad baja. CINVESTAV Departamento de Computaci´n o
  • 83. Implementaci´n y pruebas 67 o Figura 5.1: Errores encontrado por FindBugs Al analizar el c´digo con esta herramienta, se eliminaron la mayor´ de los errores o ıa que fueron encontrado por la herramienta tal como lo muestra la figura 5.2. Quedando un total de 16 de errores. Figura 5.2: Revisi´n de c´digo FindBugs o o Estos 16 errores se consideraron como falsos positivos. A continuaci´n se dar´ un o a listado explicando porque estos errores son falsos positivos: CINVESTAV Departamento de Computaci´n o
  • 84. 68 Cap´ ıtulo 5 Los nombre de las clases deben comenzar con una letra may´ scula u A pesar de que esto se considera un est´ndar de codificaci´n en la plataforma a o Java. Android autogenera clases para acceder sus recursos declarando clases del est´ public start final class anim. ılo Variable local muerta: Este error se refiere a que una variable local es asignada, pero su valor no es le´ ni utilizado en ninguna instrucc´n subsecuente. ıdo o Al revisar el c´digo manualmente se encontr´ que esta variable se utilizaba o o posteriormente en el c´digo. o Campos no utilizados: Este par´metro se refiere a eliminar par´metros que a a no se utilizan. En nuestro caso se refiere al no uso de dos clases internas, sin embargo estas clases internas son partes del funcionamiento de este m´dulo. o 5.2. Implementaci´n de componentes de seguridad o En la siguiente secci´n se explicar´ como se realiz´ la implementaci´n de los o a o o componentes de seguridad que fueron propuestos en nuestro dise˜o arquitectural para n mitigar en medida de lo posible los ataques que pudiera sufrir una aplicaci´n de o facturaci´n electr´nica. o o 5.2.1. Control de acceso Para la implementaci´n del control de acceso se realiz´ atrav´s de ingresar un o o e nombre de usuario y una contrase˜a. Para la creaci´n de esta contrase˜a se ha decidido n o n adoptar un conjunto de reglas que ayudaran a los usuarios a generar contrase˜as n seguras. Para que una contrase˜a se considere segura se debe de considerar lo siguiente n [1]: CINVESTAV Departamento de Computaci´n o
  • 85. Implementaci´n y pruebas 69 o La contrase˜a debe de contener al menos tres de los siguientes tipos de caracn teres: • Letras min´sculas u • Letras may´sculas u • N´meros u • Caracteres especiales (|@#$%^&*()_+~-=‘{}[]:";’<>|) La contrase˜a debe de contener al menos quince caracteres alfan´mericos. n u Para nuestro caso se ha implantado que nuestra contrase˜a contenga letras min´scun u las, al menos una letra may´scula, al menos un n´mero y al menos un car´cter esu u a pecial. La longitud de la contrase˜a ser´ de al menos 8 caracteres ya que debido a n a la naturaleza de los dispositivos m´viles resulta cansado en terminos de usabilidad el o ingresar una contrase˜a de mayor longitud. n Por otra parte, el almacenamiento del nombre de usuario y contrase˜a se har´ en n a una peque˜a base de datos creada en SQLite. Para el almacenamiento de la contrase˜a n n se utilizar´ una funci´n picadillo. Si no se aplica esta funci´n picadillo a las contrase˜as a o o n que se almacenan en la aplicaci´n en caso de que un adversario comprometa la base o de datos y robe la contrase˜a es posible comprometer a otra aplicaci´n o servicio del n o usuario, si este utiliza la misma contrase˜a. n Al aplicar una funci´n picadillo a las contrase˜a antes de que sea almacenada en o n la base de datos, dificultamos al adversario el determinar la contrase˜a original. Para n el almacenamiento del campo de contrase˜a en la base de datos se hizo uso de el n algoritmo SHA1. 5.2.2. Canal Confiable El canal seguro nos servir´ para enviar los datos de respaldo como nuestra cartera a de clientes y los comprobantes fiscales digitales de una manera segura. Para la implementaci´n de este canal confiable se ha decidido utilizar el protocolo SSL/TLS. o El objetivo primordial del protocolo SSL/TLS es proporcionar privacidad y integridad de datos entre dos aplicaciones que se comunican. Algunos puntos clave de este protocolo son: SSL/TLS proporciona servicios de seguridad entre el protocolo TCP y las aplicaciones que usan TCP. SSL/TLS proporciona confidencialidad usando criptograf´ sim´trica e integriıa e dad de los mensajes usando c´digos de autenticaci´n de mensajes (MAC). o o CINVESTAV Departamento de Computaci´n o
  • 86. 70 Cap´ ıtulo 5 SSL/TLS incluye mecanismos para permitir a dos usuarios del protocolo TCP determinar los mecanismos de seguridad. El protocolo SSL/TLS trabaja a nivel capa de transporte justo arriba del protocolo TCP tal como se muestra en la figura 5.3 Figura 5.3: SSL/TLS A nivel implementaci´n existen dos aproximaciones: SSL/TLS puede estar inteo grado como parte de la suite de protocolos subyacente y por lo tanto, ser transparente a las aplicaciones o por otra parte SSL, se puede incrustar en paquetes espec´ ıficos. Para nuestro caso se tom´ la segunda aproximaci´n ya que la plataforma Android nos o o proporciona paquetes para la abstracci´n de este protocolo para la implementaci´n o o de un canal seguro atrav´s de HTTPS. e En la implementaci´n de nuestro canal seguro se tom´ como base el modelo clienteo o servidor, donde nuestro dispositivo m´vil servir´ como cliente y realizar´ peticiones o a a hacia un servidor web que prestar´ los servicios para guardar la informaci´n sensitiva a o que mande nuestro dispositivo. Para comunicarse por medio de un canal HTTPS es necesario la creaci´n de un cliente HTTPS registrando la adici´n de los protocolos a o o utilizar en nuestra aplicaci´n como se muestra a continuaci´n: o o public c l a s s H t t p s C l i e n t extends D e f a u l t H t t p C l i e n t { @Override public ClientConnectionManager createClientConnectionManager () { f i n a l SchemeRegistry r e g i s t r y = new SchemeRegistry () ; CINVESTAV Departamento de Computaci´n o
  • 87. Implementaci´n y pruebas 71 o r e g i s t r y . r e g i s t e r (new Scheme ( ” h t t p s ” , new SSLSocketFactory ( ) , 443 ) ) ; return new SingleClientConnManager ( params , r e g i s t r y ); } } Como puede verse se debe de sobreponer el m´todo createClientConnectionManager() e y en el establecer los protocolos que van a utilizarse en este caso ser´ el protocolo a https registr´ndolo en el esquema createClientConnectionManager(). Para regisa trar el servicio es necesario crear una f´brica de sockets SSL para el envio y recepci´n a o de informaci´n de manera segura, en nuestro caso esto se realiz´ heredando de la o o interfaz SocketFactory y la interfaz LayeredSocketFactory e implementando cada uno des sus m´todos( connectSocket, createSocket, isSecure). A continuaci´n e o se muestra como se construye esta fabrica de sockets: public c l a s s SSLSocketFactory implements So cke tFac tor y , LayeredSocketFactory { private SSLContext s s l c o n t e x t = null ; private s t a t i c SSLContext createEasySSLContext ( ) throws IOException { try { SSLContext c o n t e x t = SSLContext . g e t I n s t a n c e ( ”TLS” ); c o n t e x t . i n i t ( null , new TrustManager [ ] { new EasyX509TrustManager ( null ) } , null ) ; return c o n t e x t ; } catch ( E x c e pt io n e ) { throw new IOException ( e . getMessage ( ) ) ; } } // Implementacion de l o s metodos c o n n e c t S o c k e t , createSocket , isSecure .... } Por ultimo es necesario crear un manejador de los certificados para que verifique ´ que certificados son v´lidos. Para realizar esta tarea hay es necesario implementar los a m´todos que se heredan de la interfaz X509TrustManager. e CINVESTAV Departamento de Computaci´n o
  • 88. 72 Cap´ ıtulo 5 public c l a s s AmaiTrustManager implements X509TrustManager { public void c h e c k C l i e n t T r u s t e d ( X 5 0 9 C e r t i f i c a t e [ ] chain , S t r i n g authType ) throws C e r t i f i c a t e E x c e p t i o n { .... } public void c h e c k S e r v e r T r u s t e d ( X 5 0 9 C e r t i f i c a t e [ ] chain , S t r i n g authType ) throws C e r t i f i c a t e E x c e p t i o n { .... } public X 5 0 9 C e r t i f i c a t e [ ] g e t A c c e p t e d I s s u e r s ( ) { .... } } 5.2.3. Contenedor Seguro El contenedor seguro es el que mantendr´ confidencial la informaci´n privada de a o la aplicaci´n de facturaci´n electr´nica. Para la implementaci´n de este componente o o o o se ha decido utilizar el cifrador AES (Advanced Encryption Standard) de 128 bits. Existen muchas formas para la generaci´n de llaves del cifrador AES como lo son el o uso de n´meros aleatorios. Sin embargo en ocasiones es conveniente usar llaves que el u usuario genere por sus propios medios. Para la generaci´n de llaves del cifrador AES o se utilizar´ un m´todo el cu´l sea amigable con el usuario, donde para la creaci´n de a e a o llaves se tomar´ como entrada la contrase˜a que introduzca el usuario, esta contrase˜a a n n se procesa por medio de alguna funci´n o conjunto de funciones y produce una llave o adecuada para el cifrador sim´trico. Al cifrado que genera las llaves de esta forma se e le conoce cifrado basado en contrase˜a (PBE). n Los mecanismos de cifrado basados en contrase˜as utilizan m´todos para la pren e venci´n de ataques triviales, sin embargo un adversario podri´ determinar f´cilmente o a a la contrase˜a si se escoge una contrase˜a inapropiada. Es por eso que para la creaci´n n n o de contrase˜as se deben de usar pol´ n ıticas para la creaci´n de contrase˜as fuertes. o n Los mecanismos de cifrado basados en contrase˜as est´n basados en funciones n a picadillo. En esencia, este tipo de mecanismos utilizan la contrase˜a y un valor p´blico n u CINVESTAV Departamento de Computaci´n o
  • 89. Implementaci´n y pruebas 73 o llamado sal para alimentar de alguna manera a una funci´n de mezcla basada en una o funci´n picadillo segura aplicada un cierto n´meros de veces. Una vez que la funci´n o u o de mezcla se completa, el resultado es una llave para el cifrador y posiblemente un vector de inicializaci´n. En la figura 5.4 se muestra un esquema general de cifrado o basado en contrase˜a. n Figura 5.4: Mecanismo PBE La contrase˜ a: Este elemento debe de mantenerse secreto y debe ser una n contrase˜a fuerte. n Funci´n de derivaci´n de llaves (creaci´n de llave secreta): Una funci´n o o o o de derivaci´n de llaves produce una llave derivada de una llave base y otros o par´metros. En una funci´n de derivaci´n de llave basado en contrase˜a, la a o o n llave base es una contrase˜a y los otros par´metros son el valor de la sal y el n a contador de iteraci´n. o La sal: Es un valor p´blico (el adversario puede saberlo), la sal tiene como u objetivo agregar una cadena de bytes aleatorios a la contrase˜a, una misma n contrase˜a puede usarse para generar un gran n´mero de llaves. Esto es util n u ´ porque obliga a los adversarios para realizar el c´lculo de generaci´n de llaves a o cada vez que desee probar una contrase˜a, por cada pieza de datos cifrados que n desea atacar. La llave derivada se genera de la siguiente manera: DK = KDF (C, S) CINVESTAV (5.1) Departamento de Computaci´n o
  • 90. 74 Cap´ ıtulo 5 donde DK es la llave derivada, C es la contrase˜a, y S es la sal. La generaci´n n o de llaves tiene 2 beneficios [19]: 1. Es dif´ para un adversario precalcular todas las llaves en un diccionario ıcil de contrase˜as. Si la sal tiene una longitud de 64 bits, habr´ alrededor n a de 264 llaves por cada contrase˜a. Un adversario se limita por tanto a la n b´squeda de contrase˜as despu´s de que se realiza la operaci´n basada en u n e o la contrase˜a dada una sal que es conocida. n 2. Es poco probable que la misma llave se seleccione dos veces. Por ejemplo, si la sal tiene una longitud de 64 bits, la probabilidad de colisi´n entre llaves o 32 no se vuelve significativa hasta que cerca de 2 llaves sean producidas. Contador de iteraci´n: El contador de iteraci´n es tambi´n un valor p´blio o e u co. El prop´sito del contador de iteraci´n es incrementar el tiempo de c´lculo o o a requerido para convertir una contrase˜a en una llave. Por ejemplo, si un advern sario monta un ataque de diccionario, si se utiliza un contador de iteraci´n 1000 o veces en vez de una sola vez,se requerir´ 1000 veces m´s de procesamiento para a a calcular la llave de la contrase˜a. n Para la implementaci´n del contenedor seguro se utiliz´ el esquema de cifrado o o basado en contrase˜a AES-CBC-Pad el cu´l es el algoritmo de cifrado AES con el n a modo de operaci´n CBC con padding PKCS #5 [19]. La plataforma Android nos ofrece o mecanismos para generar cifrado basado en contrase˜a. La creaci´n del cifrado de n o basado en contrase˜a puede dividirse en tres partes: n 1. Creaci´n de sal: Para la creaci´n de la sal se ha decidio que este par´metro o o a se haga de manera aleatoria. Para la generaci´n de este par´metro se utiliz´ el o a o generador de n´meros pseudoaleatorio SHA1PRNG, que esta basado en el u algoritmo de digesto SHA-1. Un ejemplo de generaci´n de sal se muestra a o continuaci´n: o public s t a t i c S t r i n g g e n e r a t e S a l t ( ) { byte [ ] s a l t = new byte [ 8 ] ; SecureRandom s r ; try { s r = SecureRandom . g e t I n s t a n c e ( ”SHA1PRNG” ) ; s r . n e x t By te s ( s a l t ) ; } catch ( NoSuchAlgorithmException e ) { e . printStackTrace () ; } return t o H e x S t r i n g ( s a l t ) ; } CINVESTAV Departamento de Computaci´n o
  • 91. Implementaci´n y pruebas 75 o 2. Inicializaci´n del Cifrador basado en contrase˜ a: En esta parte se inio n cializan los datos del cifrador a utilizar as´ como la conversi´n de la contrase˜a ı o n a una llave del cifrador. Un ejemplo de esta inicializaci´n se muestra a contio nuaci´n: o private void i n i t i a l i z e ( ) { pbeParamSpec = new PBEParameterSpec ( s a l t , count ) ; try { keyFac = S e c r e t K e y F a c t o r y . g e t I n s t a n c e ( algorithmMedium , ”BC” ) ; } catch ( NoSuchAlgorithmException e ) { e . printStackTrace () ; } catch ( NoSuchProviderException e ) { e . printStackTrace () ; } } } public void s e t P a s s w o r d ( S t r i n g p a s s ) { password = p a s s ; pbeKeySpec = new PBEKeySpec ( password . toCharArray ( ) ) ; try { pbeKey = keyFac . g e n e r a t e S e c r e t ( pbeKeySpec ) ; pbeCipher = Cipher . g e t I n s t a n c e ( algorithmMedium , ” BC” ) ; } catch ( I n v a l i d K e y S p e c E x c e p t i o n e ) { e . printStackTrace () ; } catch ( NoSuchAlgorithmException e ) { e . printStackTrace () ; } catch ( NoSuchProviderException e ) { e . printStackTrace () ; } catch ( NoSuchPaddingException e ) { e . printStackTrace () ; } 3. Cifrar Datos: Una vez inicializados los datos ya es posible cifrar datos. El siguiente c´digo nos muestra como se puede realizar esta acci´n: o o pbeCipher . i n i t ( Cipher .ENCRYPT MODE, pbeKey , pbeParamSpec ) ; c i p h e r t e x t = pbeCipher . d o F i n a l ( p l a i n t e x t . g e t B y t e s ( ) ) ; Dentro de las clases principales que abstraen el funcionamiento del cifrador basado en contrase˜a se encuentran: n CINVESTAV Departamento de Computaci´n o
  • 92. 76 Cap´ ıtulo 5 javax.crypto.spec.PBEParameterSpec: Esta clase nos sirve como portador de sal y el contador de iteraciones para que puedan ser inicializados en nuestro cifrador. javax.crypto.spec.PBEKeySpec: Esta clase es capaz de llevar a la sal, el contador de iteraciones y, si es necesario el mecanismo de generaci´n de llaves. o javax.crypto.SecretKeyFactory: Una vez creado el PBEKeySpec que contiene la contrase˜a y, posiblemente, los dem´s par´metros de generaci´n de n a a o llaves, es necesario tener un mecanismo para convertir la contrase˜a en un n objeto que sea compatible con la suite del provedor criptogr´fico. La clase a SecretKeyFactory nos sirve para este prop´sito. o 5.2.4. Autoprueba del sistema Una funci´n de autoprueba debe de realizarse para verificar que los componentes o de un modulo esten funcionando correctamente. Debido a que en nuestra aplicaci´n o de facturaci´n electr´nica maneja datos sensitivos (llave privada, certificados, cartera o o de clientes, folios) es necesario verificar que estos no hayan sufrido alg´n tipo de u alteraci´n antes de que el sistema de facturaci´n electr´nica pueda usarse. El tipo o o o de autoprueba que se implement´ en este modulo fue del tipo pre-operacional. Una o autoprueba pre-operacional es aquella que se realiza cada vez que el modulo o sistema es encendido o instanciado (despues de ser apagado, reiniciado, despu´s de alguna e falla, etc ). En nuestro caso la autoprueba del sistema se realizar´ al iniciar la aplicaci´n vea o rificando todos los datos sensitivos de la aplicaci´n, en caso de que nuestra aplicaci´n o o detecte que alguno de los datos sensitivos ha sido alterado, esta tiene la capacidad de pasar a un modo no operacional mostrando un mensaje de error como se muestra en la figura 5.5. Figura 5.5: Falla de autoprueba del sistema CINVESTAV Departamento de Computaci´n o
  • 93. Implementaci´n y pruebas 77 o Para realizar esta funci´n de autoprueba pre-operacional fue necesario la utilio zaci´n de un componente que pudiera verificar la integridad de los datos, para este o prop´sito se utiliz´ la funci´n picadillo SHA1. Los digestos del conjunto de datos seno o o sitivos ha sido guardado en una peque˜a base de datos y cada vez que se realiza esta n prueba se verifican los datos de los digestos calculados con los campos de digestos guardados en la base de datos. 5.2.5. Firma electr´nica o Una vez generado el documento XML con los par´metros de la factura electr´nica a o de acuerdo a Anexo 20 secci´n C y se ha creado la cadena original de acuerdo a lo o que especifica el Anexo 20 secci´n D, es necesario crear sello digital. El sello digital o no es m´s que la firma digital de la cadena original, este fue creado de acuerdo a los a siguientes par´metros [2]: a 1. Se aplica el m´todo de digesti´n SHA-1 sobre la cadena original a sellar inclue o yendo los nodos Complementarios. Este procedimiento genera una salida de 160 bits (20 bytes) para todo mensaje. La posibilidad de encontrar dos mensajes distintos que produzcan una misma salida es de 1 en 2160 , y por lo tanto en esta posibilidad se basa la inalterabilidad del sello, as´ como su no reutilizaci´n. Es ı o de hecho una medida de la integridad del mensaje sellado, pues toda alteraci´n del mismo provocar´ una digesti´n totalmente diferente, por lo que no se o a o podr´ autentificar el mensaje. a SHA-1 no requiere semilla alguna. El algoritmo cambia su estado de bloque en bloque de acuerdo a la entrada previa. 2. Con la llave privada correspondiente al certificado digital del emisor del mensaje y del sello digital, firmar el digesto del mensaje obtenido en el paso 1 utilizando para ello el algoritmo de cifrado RSA. 3. El resultado ser´ una cadena binaria que no necesariamente consta de caracteres a imprimibles, por lo que deber´ traducirse a una cadena que s´ conste solamente a ı de tales caracteres. Para ello se utilizar´ el modo de expresi´n de secuencias de a o bytes denominado ”Base 64”, que consiste en la asociaci´n de cada 6 bits de la o secuencia a un elemento de un alfabeto que consta de 64 caracteres imprimibles. Puesto que con 6 bits se pueden expresar los n´meros del 0 al 63, si a cada uno u de estos valores se le asocia un elemento del alfabeto se garantiza que todo byte de la secuencia original puede ser mapeado a un elemento del alfabeto Base 64, y los dos bits restantes formar´n parte del siguiente elemento a mapear. a Por tanto y de acuerdo a lo anterior los algoritmos para generar la llave privada ser´n los siguientes: a CINVESTAV Departamento de Computaci´n o
  • 94. 78 Cap´ ıtulo 5 SHA-1 y firma con el algoritmo RSA: La plataforma Android nos ofrece varias clases para la realizaci´n de la firma electr´nica con el algoritmo RSA y SHA-1 o o dentro de los paquetes que nos ayudan a realizar esta tarea se encuentran: • import java.security.Signature • java.security.interfaces.RSAPrivateKey • java.security.spec.PKCS8EncodedKeySpec A continuaci´n se muestra un peque˜o fragmento de c´digo de como se realiz´ la o n o o firma electr´nica utilizando los paquetes anteriormente mencionados: o PKCS8EncodedKeySpec p r i v S p e c = new PKCS8EncodedKeySpec ( privKeyBytes ) ; = ( RSAPrivateKey ) keyFactory . g e n e r a t e P r i v a t e ( privSpec ) ; // Compute s i g n a t u r e S i g n a t u r e i n s t a n c e = S i g n a t u r e . g e t I n s t a n c e ( ”SHA1withRSA” , ”BC” ) ; i n s t a n c e . i n i t S i g n ( privKey ) ; i n s t a n c e . update ( messageToByte ) ; sigBytes = instance . sign () ; 5.2.6. Bloqueo de la aplicaci´n o La aplicaci´n necesita ser bloqueada cada cierto tiempo para que personas no o autorizadas puedan realizar acciones malitencionadas dentro de nuestra aplicaci´n. o La aplicaci´n se bloquear´ cada 5 minutos una vez que el dispositivo entre en un o a estado donde no se realic´ ninguna acci´n por parte del usuario (idle), mostrando e o una pantalla que nos pedir´ el nombre de usuario y contrase˜a como se muestra en a n la figura 5.6. CINVESTAV Departamento de Computaci´n o
  • 95. Implementaci´n y pruebas 79 o Figura 5.6: Bloqueo de la aplicaci´n o Cada vez que la aplicaci´n se bloquea se borran datos sensitivos como la contrase˜a o n de usuario y la llave sim´trica con la que se cifran la cartera de clientes y llave privada; e esto con el prop´sito de evitar ataques de volcado de memoria. Una vez que se ingresan o los datos de autenticaci´n y sean v´lidados por la aplicaci´n se volver´ a instanciar o a o a el cifrador basado en cotrase˜a. n Para la implementaci´n de de este componente se creo un servicio en Android o para capturar los Intents generados por la alarma. Se establece un estado global de la instancia del servicio para indicar que la aplicaci´n debe de bloquearse. Para o el control de alarma se utiliz´ la clase AlarmManager para programar y cancelar la o acci´n de tiempo de espera como se muestra en el siguiente fragmento de c´digo: o o c t x . s t a r t S e r v i c e (new I n t e n t ( ctx , T i m e o u t S e r v i c e . class ) ) ; long t r i g g e r T i m e = System . c u r r e n t T i m e M i l l i s ( ) + DEFAULT TIMEOUT; AlarmManager am = ( AlarmManager ) c t x . g e t S y s t e m S e r v i c e ( Context . ALARM SERVICE) ; am . s e t ( AlarmManager .RTC, t r i g g e r T i m e , b u i l d I n t e n t ( ctx ) ) ; El control de la alarma para el bloqueo de la aplicaci´n se controla en los eventos o onPause() y onResume() del ciclo de vida de una aplicaci´n de Android. En el evento o onPause() se verifica si la aplicaci´n ha estado ocioso si es as´ se lanza el servicio de o ı alarma, si ocurre alguna interrupci´n se reinicia la la alarma en el evento onResume() o @Override protected void onPause ( ) { super . onPause ( ) ; CINVESTAV Departamento de Computaci´n o
  • 96. 80 Cap´ ıtulo 5 Timeout . s t a r t ( t h i s ) ; } @Override protected void onResume ( ) { super . onResume ( ) ; Timeout . c a n c e l ( t h i s ) ; checkShutdown ( ) ; } En la figura 5.7 se describe el diagrama de estados el proceso de bloqueo de la aplicaci´n. o Figura 5.7: Diagrama de estado: Bloqueo de la aplicaci´n o 5.3. Pruebas de seguridad Las pruebas de seguridad es la fase en la cu´l el software se somete a un conjunto a de pruebas para demostrar que este es seguro. El principal objetivo de las pruebas de seguridad es asegurar que el software que se someta a dichas pruebas sea robusto y continu´ funcionando de una manera aceptable incluso en la presencia de un ataque e mal intencionado. Para fines de este trabajo se realizaron las siguientes pruebas de seguridad: Pruebas funcionales Pruebas de penetraci´n o 5.3.1. Pruebas funcionales El objetivo principal de las pruebas funcionales es demostrar que todas las funciones planeadas para proteger el software de ataques est´n funcionando correctamente. e CINVESTAV Departamento de Computaci´n o
  • 97. Implementaci´n y pruebas 81 o Las pruebas se realizaron sobre nuestros componentes de seguridad. Se realizaron tanto pruebas unitarias como pruebas de integraci´n sobre los siguientes componentes: o Pruebas de comunicaci´n : Se verific´ que la informaci´n entre el dispositivo o o o m´vil y el servidor se estuvieran mandando correctamente. o Pruebas de soporte criptogr´fico: Se verific´ que los componentes que proa o porcionan alg´n servicio criptogr´fico funcionaran adecuadamente (modulo de u a firma digital, modulo de contenedor seguro). Pruebas de autenticaci´n: Se verific´ que los componentes de autenticaci´n o o o permitieran solo acceso a usuarios autorizados. Pruebas de canales seguro: Se verific´ que la informaci´n efectivamente se o o estuviera mandando por un canal confiable. Pruebas de protecci´n de datos: Se verific´ que la informaci´n sensitiva o o o efectivamente estuviera protegida. 5.3.2. Pruebas de penetraci´n o Las pruebas de penetraci´n nos sirven para evaluar como un adversario atacar´ el o a sistema. En otros t´rminos las pruebas de penetraci´n se refieren a probar el software e o de una aplicaci´n de software o sistema computacional e intentar comprometer su o seguridad. Para realizar las pruebas de penetraci´n existen distintas herramientas o las cu´les contienen un conjunto de programas que intent´n aprovechar de alguna a a debilidad del sistema (exploit). El estado del arte en herramientas de penetraci´n para plataformas m´viles es muy o o pobre. Sin embargo la plataforma Android nos ofrece un conjunto de herramientas que nos puede ayudar de cierta forma a realizar esta tarea a pesar de que estas herramientas no est´n destinadas a realizar pruebas de seguridad. e Android Debug Bridge(ADB) ADB es una herramienta de l´ ınea de comandos que permite comunicarse con una instancia del emulador o un dispositivo Android. Es un programa cliente-servidor, que incluye los siguientes tres componentes: Un cliente que se ejecuta en el equipo de desarrollo. Se puede mandar a llamar una consola shell desde el emulador o dispositivo con Android. Un servidor que se ejecuta como un proceso en segundo plano en el equipo de desarrollo. El servidor gestiona la comunicaci´n entre el cliente y el demonio o adb. CINVESTAV Departamento de Computaci´n o
  • 98. 82 Cap´ ıtulo 5 Un demonio, que se ejecuta como un proceso en segundo plano en cada emulador o de instancia del dispositivo. Usando esta herramienta es posible usar los comandos que nos proporciona shell de comandos y as´ poder extraer informaci´n sensitiva de nuestro dispositivo. Bajo ı o la utilizaci´n de estas herramientas se plantearon los siguientes escenarios: o Pruebas de penetraci´n en base de datos o A trav´s de la utilizaci´n del shell de comando de ADB es posible ejecutar el e o comando sqlite3 para hacer consultas creadas por aplicaciones Android y que esten almacenadas en la memoria del dispositivo. En nuestro caso es posible que un adversario quiera robar la informaci´n de contrase˜as o llaves que almacenemos en esta o n base datos. Para realizar este ataque el adversario realizar´ lo siguiente: ıa 1. Explorar la bases de datos de las aplicaci´n de facturaci´n electr´nica instalada o o o en el dispositivo y ejecutar el comando de sqlite3 adb -s <nombre del dispositivo> shell ls /data/data/<aplicacion>/databases/ sqlite3 /data/data/<aplicacion>/databases/<nombredelabasedetaos.db> 2. Ejecutar el comando .table para ver la estructura de tablas que tiene la aplicaci´n de facturaci´n electr´nica. o o o Como se puede ver es posible ver nuestro esquema de la base datos. Por ejemplo el adversario podr´ ver nuestra tabla de control de acceso o nuestra llave del ıa contenedor seguro de nuestra aplicaci´n. Tal como se muestra en la figura 5.7 o y la figura 5.8. CINVESTAV Departamento de Computaci´n o
  • 99. Implementaci´n y pruebas 83 o Figura 5.8: Visualizaci´n de nuestra contrase˜a de usuario o n Figura 5.9: Visualizaci´n de nuestra llave del contenedor seguro o Como se puede ver este ataque no vulnera nuestro sistema debido a las medidas tomadas en nuestro dise˜o e implementaci´n del mismo. Sin embargo, si no n o se hubieran tomado en cuenta estas medidas, el ataque resultar´ efectivo y se ıa caer´ en un fallo grave de seguridad para nuestra aplicaci´n. ıa o Pruebas de penetraci´n de red o Esta prueba se realiz´ para probar los datos entre nuestro dispositivo m´vil y o o el servidor de respaldo. Para esto es necesario la utilizaci´n de un sniffer que nos o permita capturar y explorar el tr´fico de nuestra aplicaci´n. Para realizar esta prueba a o se utilizar´ la herramienta wireshark. a En este ataque se supone que existe un adversario escuchando el canal de comunicaciones para tratar de ver la informaci´n que pasa entre nuestra aplicaci´n y el o o servidor de respaldo. Para realizar este ataque el adversario realizar´ lo siguiente: ıa 1. Introducir tanto la ip fuente (dispositivo m´vil) como la ip destino (servidor de o respaldo) en el filtro de la herramienta wireshark. La ip fuente y la ip destino pueden ser obtenidas f´cilmente por medio de una captura global del tr´fico con a a la herramienta wireshark. ip.src==<ip-fuente> and ip.dst==<ip-destino> 2. Aplicar la b´squeda de paquetes con este filtro. En nuestro aplicaci´n al realizar u o la b´squeda con estos par´metros se obtuvieron los resultados de la figura 5.10. u a CINVESTAV Departamento de Computaci´n o
  • 100. 84 Cap´ ıtulo 5 Figura 5.10: Busqueda de peticiones https con wireshark Como podemos ver debido a que decidimos enviar nuestros par´metros sensitia vos por un canal seguro SSL, el adversario no podr´ obtener ninguna informaa ci´n relevante de nuestra aplicaci´n. Los datos se estar´n enviando por medio o o a del protocolo HTTPS a trav´s del servicio pcsync-https que es utilizado por e el servidor Apache-Tomcat. Por otra lado, se configur´ nuestra aplicaci´n para o o que se pudieran enviar datos a trav´s del protocolo HTTP para mandar los e entre el dispositivo m´vil y el servidor. Utilizando los mismos par´metros de o a b´squeda de paquetes se obtuvo el resultado de la figura 5.11. u Figura 5.11: Busqueda de peticiones http con wireshark CINVESTAV Departamento de Computaci´n o
  • 101. Implementaci´n y pruebas 85 o Como podemos ver, si los datos no son enviados sobre un canal protegido un adversario podr´ obtener informaci´n sobre los par´metros sensitivos de seguıa o a ridad de nuestra aplicaci´n. o CINVESTAV Departamento de Computaci´n o
  • 102. 86 Cap´ ıtulo 5 CINVESTAV Departamento de Computaci´n o
  • 103. Cap´ ıtulo 6 Conclusiones y trabajo a futuro En este cap´ ıtulo se resumen todas las ideas principales y los resultados obtenidos en la realizaci´n del dise˜o e implementaci´n de un sistema de facturaci´n electr´nica. o n o o o Se mencionaran las principales actividades y aportaciones de este trabajo as´ como las ı posibles mejoras que se podr´ realizar en el dise˜o e implementaci´n en el desarrollo ıan n o seguro de sistemas de facturaci´n electr´nica. o o 6.1. Conclusiones El principal objetivo de este trabajo de tesis es mostrar un enfoque sistem´tia co para el desarrollo de una aplicaci´n de facturaci´n electr´nica para dispositivos o o o m´viles incluyendo al ciclo de vida convencional de desarrollo de software el uso de o herramientas y metodolog´ de desarrollo seguro de aplicaciones. Estas herramientas ıas est´n destinadas a brindar servicios de seguridad tanto en etapas tempranas como a en etapas de posteriores del ciclo de vida de desarrollo. Introducir al ciclo de vida convencional el uso de estas herramientas puede mejorar sustancialmente el dise˜o n y la implementaci´n de las aplicaciones. En este trabajo se realiz´ el an´lisis, dio o a se˜o e implementaci´n de una aplicaci´n de facturaci´n electr´nica obteniendo como n o o o o principales resultados los siguientes: Se integr´ a la fase de requerimientos de software la inclusi´n de la metodolog´ o o ıa SQUARE la c´al nos sirvi´ para la obtenci´n y priorizaci´n de los requerimienu o o o tos de seguridad. Esta fase es de suma importancia en el desarrollo si es que se quiere construir un software seguro. Se realiz´ el estudio del an´lisis y modelado de amenazas atrav´s del uso de o a e herramientas como lo son los arboles de ataque y los casos de abuso realizando una estimaci´n de los riesgos de nuestra aplicaci´n. Estas herramientas nos o o permitieron tener una visi´n de los objetivos de seguridad para que fueran o introducidos en el ciclo de vida de software mostrando los riesgos y debilidades 87
  • 104. 88 Cap´ ıtulo 6 de este tipo de aplicaciones para posteriormente integrar contra-medidas para mitigar estos. Para proveer una plataforma segura de facturaci´n electr´nica m´vil se realiz´ el o o o o dise˜o de una arquitectura de software escalable incorporando una capa que se n enfoca a prestar ciertos servicios de seguridad a nuestro sistema. El modelado de los componentes de seguridad se hizo utilizando la herramienta UMLSec. El dise˜o de estos componente podr´ servir de ayuda para el desarrollo de otro n ıa tipo de aplicaciones m´viles o de otro tipo aplicando los mismos m´todos de o e protecci´n. o Se desarroll´ una implementaci´n de un sistema de facturaci´n electr´nica que o o o o incorpora el modelo de seguridad arquitectural propuesto. Se incorpor´ el uso de pr´cticas de codificaci´n segura las cuales pueden mejorar o a o la calidad del producto. A pesar de que las opciones de herramientas para realizar pruebas de penetraci´n son pocas para la plataformas m´viles, se present´ una propuesta b´sica de o o o a como se podr´ realizar este tipo de pruebas utilizando la plataforma Android. ıan 6.2. Trabajo a futuro Los siguientes puntos se proponen como trabajo a futuro de este trabajo: Incorporar al actual sistema implementado el nuevo esquema de facturaci´n o electr´nica que entr´ en vigor en el 2011, el cu´l hace incorporaci´n de un o o a o timbre digital la cu´l va impedir ataques de falsificaci´n de facturas ya que la a o creaci´n de este este timbre digital es creado por un proveedor autorizado del o SAT. Implementar este desarrollo en otras plataformas con recursos similares a Android (IOS, Symbian-OS, Meego) y experimentar la implementaci´n en platao formas con m´s bajos recursos que cuenten con la plataforma J2ME. a Implementar los controles de seguridad en plataformas de facturaci´n electr´nio o ca de mayor escala como podr´ ser plataformas de escritorio o plataformas ıan web y realizar el an´lisis de seguridad para ver que componentes son necesarios a en este tipo de sistemas CINVESTAV Departamento de Computaci´n o
  • 105. Ap´ndice A e Definiciones de seguridad Activo: Se trata de un recurso de valor que se debe proteger. Pueden ser activos intangibles como la reputaci´n de su empresa, o tangibles como la informaci´n que se o o procesa o los datos de un cliente. Tambi´n se podr´ considerar un activo un recurso e ıa que utilizado de forma indebida facilite el acceso no autorizado o provoque la no disponibilidad de otro activo.[29] Algoritmo criptogr´fico: Un procedimiendo computacionalmente bien definido a que toma variables de entrada, el cu´l incluye llaves criptogr´ficas y produce una a a salida [23]. Amenaza: Un evento de posible ocurrencia que podr´ da˜ar o comprometer un ıa n activo o un objetivo estrat´gico.[29] e Ataque: Una acci´n que se sirve de una o varias vulnerabilidades para materiao lizar una amenaza.[29] Autenticaci´n: El proceso de determinar si alguien o algo es en verdad lo que o dice ser. [27] Ataque de denegaci´n de servicio: Una forma de ataque a una computadora o o grupo de computadoras enviando millones de peticiones cada segundo, ralentizando la red. [27] 89
  • 106. 90 Cadena original: Se entiende como cadena original, a la secuencia de datos formada con la informaci´n contenida dentro de la factura electr´nica, establecida en o o el Rubro C del Anexo 20 de la Resoluci´n Miscel´nea Fiscal [5]. o a Certificado de sello digital: Documento electr´nico, mensaje de datos u otro o registro que asocia una llave p´blica con la identidad de su propietario, confirmando u el v´ ınculo entre ´ste y los datos de creaci´n de una firma electr´nica avanzada o de e o o un sello digital [5]. Cliente o receptor: Persona que recibir´ las f´cturas electr´nicas [5]. a a o Codigo de Autenticaci´n de Mensajes: Una checksum de los datos que usa o una llave sim´trica para detectar tanto modificaciones accidentales como intencionae les en los datos [23]. Comprobante Fiscal Digital: Es un mecanismo alternativo de comprobaci´n o ˜ de ingresos, egresos y propiedad de mercancAas en traslado por medios electr´nicos. o Maneja est´ndares de seguridad internacionalmente reconocidos, que garantizan que a el comprobante es aut´ntico, ´ e ıntegro, unico y que ser´ aceptado igual que el compro´ a bante fiscal impreso [5]. Contrase˜ a: Una cadena de caracteres(n´meros, letras y otros simbolos) usados n u para autenticar una identidad o verificar autorizaci´n de acceso [23]. o Confidencialidad: Es la propiedad de que la informaci´n sensitiva no este diso ponible o se divulge a individuos, entidades o procesos no autorizados [23]. Firma Digital: Es el resultado de una transformaci´n criptogr´fica, la cu´l de o a a ser implementada correctamente provee los servicios de autencicaci´n de origen, ino tegridad de datos y no repudio del firmante [23]. Fuerza bruta: Una t´cnia de criptoan´lisis o otro tipo de m´todo de ataque que e a e involucra un procedimiento exhaustivo de todas las posiblidades existentes [27]. Funcion picadillo o hash: Una funci´n computacionalmente eficiente que proyecta o cadenas de longitud arbitraria a cadenas de longitud fija, la cu´l es computacionala mente imposible encontrar dos valores con el mismo digesto [23]. Impacto: Efecto negativo de un ataque sobre un activo o v´ ıctima por alg´n atacante u [29]. Integridad: La propiedad de que informaci´n sensitiva no sea modificada o boo rrada de manera no autorizada sin existir alguna detecci´n. [23] o Llave cifrada: Una llave criptogr´fica que ha sido cifrada una funci´n segura pera o CINVESTAV Departamento de Computaci´n o
  • 107. Definiciones de seguridad 91 mitida o aprobada [23]. Llave p´ blica: Una llave criptogr´fica usada con un algoritmo criptogr´fico p´blico, u a a u y que esta unicamente asociado con una entidad [23]. Llave privada: Llave criptogr´fica, usada con un algoritmo criptogr´fico, que esta a a unicamente asociada con una entidad y esta no se hace p´blica [23]. ´ u Llave sim´trica o secreta: Una llave criptogr´fica, usada con un algoritmo cripe a togr´fico de llave secreta y que esta unicamente asociada con una o m´s entidades y a a que no debe de hacerse p´blica [23]. u Informaci´n o datos sensitivos: datos que deben de ser protegidos [23]. o Parametro cr´ ıtico de seguridad (CSP): Cualquier informaci´n secreta (e.g., llave o privada o secreta, llave compartida y datos de autenticaci´n tales como contrase˜as) o n la cu´l su divulgaci´n o modificaci´n pueda comprometer la seguridad de el modulo a o o criptogr´fico [23]. a Parametro de seguridad cr´ ıtico p´ blico: Cualquier parametro p´blico de seu u guridad el cu´l su modificaci´n pueda compromenter la seguridad del modulo de a o seguridad o criptogr´fico [23]. a Parametros sensitivos de seguridad: Parametros de seguridad criticos y parametros p´blicos de seguridad. [23]. u Penetraci´n: Intrusi´n o acceso no autorizado en el sistema. [27] o o Privacidad: La condici´n de ser aislado de la presencia o vista de otros. [27] o Sello digital: Mecanismo que permite acreditar la autor´ de los comprobantes ıa fiscales digitales que se emitan, de esta manera sus clientes sabr´n la identidad del a autor del comprobante fiscal digital [5]. Usuario: Persona que hace uso de el sistema de facturaci´n electr´nica. [5] o o Vulnerabilidad: Una vulnerabilidad es un punto d´bil que de explotarse con ´xie e to puede llegar a originar la consecuci´n de una amenaza [29]. o CINVESTAV Departamento de Computaci´n o
  • 108. 92 CINVESTAV Departamento de Computaci´n o
  • 109. Ap´ndice B e Identificaci´n de metas de o seguridad B.1. Confidencialidad El objetivo de confidencialidad para la aplicaci´n de facturaci´n electr´nica es o o o lograr que la informaci´n se encuentre protegida ante usuarios no autorizados. La o aplicaci´n debe de contar con controles de seguridad para no divulgar informaci´n o o de los siguientes activos: llave privada, folios, certificado digital, cartera de clientes, factura emitida y entregada (por entregar), copia local de facturas emitidas, copia respaldo de facturas emitidas y reporte mensual. Estos controles de seguridad deben de existir tanto en el dispositivo m´vil, como en el servidor de respaldo. As´ mismo o ı se deben de contar con pol´ ıticas para mantener la no divulgaci´n, y expiraci´n de las o o contrase˜as. n B.2. Disponibilidad. La aplicaci´n de facturaci´n electr´nica existen ciertas funciones que son indiso o o pensables para el funcionamiento del sistema. Funciones como la emisi´n de facturas, o sincronizaci´n de datos o de facturas son cr´ o ıticas para el sistema por lo tanto deben de estar siempre disponibles para el sistema. Adicionalmente de guardar facturas electr´nicas y la cartera de clientes de forma local se har´ un respaldo hacia un sero a vidor remoto para respaldar estos datos. El respaldo se har´ por los usuarios al final a de d´ ıa. 93
  • 110. 94 Cap´ ıtulo B B.3. Integridad de datos Los datos como la llave privada, folios, certificado digital, cartera de clientes, factura emitida y entregada (por entregar), copia local de facturas emitidas, copia respaldo de facturas emitidas, reporte mensual no deben deben de ser alterados. Antes de utilizar el sistema de facturaci´n electr´nica se debe de realizar una funci´n o o o de autoprueba que cheque la integridad tanto de la aplicaci´n como de los datos o anteriormente mencionados, si la aplicaci´n ha sufrido alguna alteraci´n en los datos o o el sistema tendr´ la capacidad de alertar al usuario. a B.4. Seguimiento Se debe de contar con un seguimiento de todas las acciones que usuario del sistema ocupe atrav´s de una bit´cora. Acciones como la emisi´n de facturas, sincronizaci´n, e a o o altas, bajas y modificaciones en la cartera de clientes tendr´n que ser registradas para a poder ser consultadas por el administrador. CINVESTAV Departamento de Computaci´n o
  • 111. Ap´ndice C e Casos de uso Identificador Nombre Descripci´n o Precondici´n o Crear una nueva cuenta principal del sistema Acci´n “Crea una nueva cuenta de usuario ” o El usuario crea un nueva cuenta. -El software acaba de ser instalado y es la primera vez que sera usado. Los folios, llaves y certificados est´n previamente a cargados en el dispositivo Actores principales Administrador. Secuencia normal Paso Acci´n o 1 El usuario selecciona la opci´n registrarse. o 2 Se le pide al usuario que inserte un nombre de usuario y contrase˜a nueva. La contrase˜a que se introduzca debe de estar n n basado en un est´ndar deber´ de contener letras, n´meros, a a u caracteres especiales. 3 Se crea contenedor seguro con la cuenta del usuario que contendr´ llave privada, folios y certificados, cartera de clientes a Postcondici´n o El usuario solicita entrar al sistema a trav´s de el cone trol acceso.El sistema pasa a un nuevo estado, donde todos los componentes del sistema est´n debidamente inicializaa dos(certificados, folios, llave privada, contenedor seguro). El software se encuentra en estado operativo. Frecuencia esperada Una vez en el primer uso del sistema Importancia Alta, indispensable para inicializar el sistema por primera vez y cargar llave privada, certificados y folios. Cuadro C.1: Caso de Uso CU-01 95
  • 112. 96 Identificador Nombre Descripci´n o Precondici´n o CONTROL DE ACCESO Acci´n “acceso al sistema por medio de el control de acceso principal” o El usuario pueden tener acceso al sistema. Antes de realizar el acceso al sistema se realizara una funci´n de autoprueba, para ver que todos los componentes del o software no hayan sido alterados. Este proceso se realiza en la carga de la aplicaci´n.El usuario ya debe de estar dado o de alta en el sistema. Actores principales Usuario. Secuencia normal Paso Acci´n o 1 El usuario para tener acceso al sistema debe de ingresar su nombre de usuario y contrase˜a, dando la instrucci´n de n o acceso al sistema 1a Si el id de usuario y contrase˜a son correctos se podr´ accen a der exitosamente 1b Si el id de usuario y/o contrase˜a son incorrectos se procede n a la excepci´n autherr. o Postcondici´n o Ingresa exitosamente al sistema de facturaci´n o Excepciones Excepci´n auterr o Paso Acci´n o 1 Si el nombre de usuario y/o contrase˜a son err´neos mosn o trara un mensaje de error Frecuencia esperada Una vez por cada usuario por cada intento de acceder al sistema Importancia Alta, Indispensable para controlar el acceso al sistema Cuadro C.2: Caso de Uso CU-02 CINVESTAV Departamento de Computaci´n o
  • 113. Casos de uso 97 Identificador Nombre Descripci´n o Precondici´n o Actores principales Secuencia normal CINVESTAV Generaci´ de factura o Acci´n “Generar Factura” o El usuario podr´n generar una factura electr´nica a un cliena o te El usuario debe de estar previamente registrado en el sistema. Usuario. Paso Acci´n o 1 El usuario selecciona la opci´n “Crear Factura” dentro el o men´ principal del sistema. u 2 El usuario selecciona el cliente de una lista de clientes registrados(contribuyente), en caso contrario se podr´ ingresar a un nuevo usuario. 3 Al seleccionar un cliente el sistema, mostrar´ los datos del a cliente tales como: Nombre de la empresa, RFC, Domicilio Fiscal, Datos y Cantidad del producto. 4 El usuario debe de de insertar los datos del producto(s) por el cu´l se desea realizar la factura. Se deben de ingresar todos a los datos del producto para poder realizar la factura. Los datos que se deben de insertar son los siguientes: Cantidad, Descripci´n, Si genera IVA, Precio Unitario. Este proceso se o realiza por cada producto o servicio del cu´l se requiera la a factura. 4.a El sistema calcula los siguientes datos: Importe, Subtotal, Precio con IVA, Retenci´n de IVA(Si aplica), Retenci´n de o o ISR(Si aplica), TOTAL 5 Una vez insertados todos los datos se muestran para confirmaci´n y se puede proceder a realizar la factura electr´nica, o o seleccionando el bot´n crear factura. o 6 Al momento de presionar el bot´n, se realizaran los siguieno tes pasos: 6a Se genera un archivo XML, con los par´metros que apliquen a para dicha factura. Estos par´metros ser´n los que que se a a especifican en el Anexo 20 secci´n C. o Departamento de Computaci´n o
  • 114. 98 Secuencia normal Postcondici´n o Excepciones CINVESTAV Paso 6b Acci´n o Se procede a generar el sello digital de acuerdo al Anexo 20 secci´n D. Para realizar este proceso es necesario cargar la o llave privada en la memoria , al finalizar el sello digital, la llave privada debe de ser borrada de la memoria de manera segura del dispositivo. Los pasos a seguir para realizar el sello digital son los siguientes: 1) Se genera la cadena original, 2) Se recupera la llave privada desde el repositorio seguro, 3) Con la llave privada creada en memoria se realiza la firma digital de la cadena original, 4) Se borra de memoria la llave privada, 5) Se anexa al documento xml el sello digital.Si existe alg´n problema con la llave o la firma digital se u proceder´ a la excepci´n signerr. a o 6c Una vez generado el archivo XML y el sello digital, se proceder´ a enviar este archivo v´ un canal seguro hacia el a ıa cliente(contribuyente).Se guarda las facturas en el repositorio seguro. 6d Si se gener´ y se envi´ correctamente el archivo XML, el o o sistema mostrara una notificaci´n de ´xito En caso contrario o e se proceder´ a la excepci´n generr o generr2 seg´n sea el a o u caso. 7 Se muestra la opci´n de regresar al men´ principal. o u La facturas son guardadas en formato XML(solo se mantendr´n en este formato y no se tendr´ una base de datos a a relacional para su almacenamiento). Excepci´n signerr o Paso Acci´n o 1 Si en el momento de hacer la firma, la llave privada no se encuentra dentro de la memoria SD o si existe un error de entrada/salida al leer la llave privada se realizan los siguientes pasos: 1.a Si el sistema notifica un error al no encontrar la llave privada en la memoria SD el sistema notificar´ al usuario y cerrando a la aplicaci´n o 1.b Si el sistema notifica un error de entrada/salida al leer la llave privada el sistema notifica al usuario y cerrara la aplicaci´n. o Departamento de Computaci´n o
  • 115. Casos de uso 99 Excepci´n generr o Paso Acci´n o 1 La generaci´n del archivo tuvo un problema al momento o de escribirse a disco o no se realiza correctamente el sello digital. 2 El archivo XML no se manda correctamente al contribuyente. 3 Se lanza una notificaci´n al usuario para que vuelva a realio zar la factura Excepci´n generr2 o 1 Existe un problema de conexi´n y no se puede enviar el archivo XML o 2 El sistema guarda el archivo y lo marca como pendiente para poder mandarlo posteriormente y recuperarse de dicha excepci´n. o Frecuencia esperada Cada vez que el usuario genere una factura Importancia Alta, indispensable para la generaci´n de comprobantes fiscales digitales. o Cuadro C.5: Caso de Uso CU-03 CINVESTAV Departamento de Computaci´n o
  • 116. 100 Identificador Nombre Descripci´n o Precondici´n o Actores principales Secuencia normal Alta de Cliente Acci´n “Dar de Alta un Nuevo Cliente del Sistema” o El usuario puede dar de alta un cliente nuevo al cu´l se le va a facturar. a El usuario debe de estar previamente registrado en el sistema. Usuario. Paso Acci´n o 1 El usuario selecciona la opci´n “Alta de Clientes” dentro el o men´ principal del sistema. u 2 El cliente ingresa los siguientes datos al sistema: Raz´n Soo cial, Correo Electr´nico, Direcci´n, RFC. Si alguno de los o o datos son inv´lidos se proceder´ a la excepci´n datosfisa a o cerr. 3 Los datos son almacenados en la base de datos local del sistema. Si no existe espacio en disco duro del dispositivo se proceder´ a la excepci´n nodiskspaceerr a o 4 Se notifica al usuario que el usuario ha sido creado exitosamente 5 Se muestra la opci´n de regresar al menu principal. o Postcondici´n o Los datos del usuario deber´n ser respaldados en un servidor a remoto(sincronizaci´n de datos). o Excepciones Excepci´n datosfiserr o Paso Acci´n o 1 Si alguno de los datos del paso 2 son incorrectos el sistema mostrara un mensaje de error. 2 Los datos deber´n de ingresarse de nuevo. a Excepci´n nodiskspaceerr o Paso Acci´n o 1 Si no hay espacio en disco duro para hacer el almacenamiento de un nuevo cliente el sistema el sistema notifica al usuario, indic´ndole que borre archivos no esenciales del disa positivo. Frecuencia esperada Cada vez que el usuario quiera dar de alta un nuevo cliente Importancia Media. Indispensable para dar de alta nuevos clientes. Cuadro C.6: Caso de Uso CU-04 CINVESTAV Departamento de Computaci´n o
  • 117. Casos de uso 101 Identificador Nombre Descripci´n o Precondici´n o Baja de cliente Acci´n “Dar de baja un Cliente del Sistema” o El usuario puede dar de baja un cliente del sistema previamente registrado. El usuario debe de estar previamente registrado en el sistema.Se debe tener por lo menos registrado un cliente en el sistema. Actores principales Usuario. Secuencia normal Paso Acci´n o 1 El usuario selecciona la opci´n “Administraci´n de Clientes” o o dentro el men´ principal del sistema. u 2 El usuario selecciona la opci´n “Dar de baja un cliente” o dentro del men´ Administraci´n de Clientes. u o 3 El usuario realiza una b´squeda por alg´n de los siguientes u u criterios. Raz´n Social, Correo Electr´nico o RFC. o o 4 Se muestran una lista de los clientes de acuerdo a las coincidencias del criterio de selecci´n. o 5 Se selecciona al cliente que se quiere borrar. 6 Se borran los datos del cliente de la base de datos local. Si existe alg´n error en la eliminaci´n de la base de datos se u o proceder´ a la excepci´n databaseerr. a o 7 Se muestra la opci´n de regresar al men´ principal. o u Postcondici´n o Los cambios realizados al eliminar el cliente se ver´n reflea jados al sincronizar los datos en el servidor remoto. Excepciones Excepci´n databaseerr. o Paso Acci´n o 1 Existe alg´n problema en la eliminaci´n de un usuario, se le u o notifica al usuario error. Se cancela la operaci´n de borrado. o Frecuencia esperada Cada vez que el usuario quiera eliminar un cliente. Importancia Baja solo es indispensable para eliminar clientes del sistema. Cuadro C.7: Caso de Uso CU-05 CINVESTAV Departamento de Computaci´n o
  • 118. 102 Identificador Nombre Descripci´n o Cambios de datos de cliente Acci´n “Modificaci´n de un Cliente del Sistema” o o El usuario puede modificar un usuario del sistema previamente registrado. Precondici´n o El usuario debe de haber accedido por el control de acceso principal del sistema. Se debe tener por lo menos registrado un cliente en el sistema. Actores principales Usuario. Secuencia normal Paso Acci´n o 1 El usuario selecciona la opci´n “Administraci´n de Clientes” o o dentro el men´ principal del sistema. u 2 El usuario selecciona la opci´n “Modificar datos de cliente” o dentro del men´ Administraci´n de Clientes. u o 3 El usuario realiza una b´squeda por los siguientes criterios: u Raz´n Social, Correo Electr´nico3, Direcci´n, RFC. o o o 5 El usuario modifica al menos uno de los siguientes datos: Raz´n Social, Correo Electr´nico3, Direcci´n, RFC.Si los dao o o to(s) ingresados son llenados incorrectamente se proceder´ a la a excepci´n datosfiserr . o 6 Se pide confirmaci´n explicita del usuario mediante las oro denes actualizar o cancelar. 7 La modificaci´n de los datos es guardada en la base de datos o local. Si no existe espacio en disco duro del dispositivo se proceder´ a la excepci´n nodiskspaceerr a o 7 Se notifica al usuario que el usuario ha sido modificado exitosamente 8 Se muestra la opci´n de regresar al menu principal. o Postcondici´n o Los datos del usuario modificados ser´n respaldados en un a servidor remoto(sincronizaci´n) o Excepciones Excepci´n datosfiserr o Excepci´n nodiskspaceerr o Paso Acci´n o 1 Si no hay espacio en disco duro para hacer el almacenamiento de un nuevo cliente el sistema alerta al usuario, indic´ndoa le que borre archivos no esenciales del dispositivo. Frecuencia esperada Cada vez que el usuario quiera modificar informaci´n del cliente. o Importancia Baja, se puede prescindir de este caso de uso y el sistema seguir´ funcionando. a Cuadro C.8: Caso de Uso CU-06 CINVESTAV Departamento de Computaci´n o
  • 119. Casos de uso 103 Identificador Nombre Descripci´n o Generar Reporte Mensual Acci´n “Generar Reporte Mensual del SAT.” o El usuario selecciona la opci´n generar el reporte mensual o de acuerdo a lo establecido en el anexo 20 secci´n A. o Precondici´n o El sistema realiz´ la autoprueba para ver que todos los como ponentes del sistema son correctos. El usuario debe de estar previamente registrado en el sistema. Actores principales Usuario Secuencia normal Paso Acci´n o 1 El usuario selecciona la opci´n generar el reporte mensual. o 2 El usuario selecciona el periodo del reporte mensual del sistema. 3 El sistema extrae los datos que determina el Anexo 20 secci´n o A de cada CFD dentro de la colecci´n de archivos XML.Si existe o alg´n problema de lectura en alg´n archivo XML se proceder´ a u u a la excepci´n: xmlioerr. o 4 Se crea un archivo de texto de acuerdo a lo establecido en el Anexo 20 secci´n A, que se guarda en la memoria local del o dispositivo. Si ocurre un error en la escritura del archivo se procede a la excepci´n txtioerr. o 5 El archivo es guardado en memoria para luego ser enviado al SAT por lo medios que este determine. Si ocurre un error en el almacenamiento se procede a la excepci´n saverr. o 6 Se muestra la opci´n de regresar al menu principal. o Postcondici´n o Se guarda el reporte mensual. Excepciones Excepci´n xmlioerr o Paso Acci´n o 1 Se lee err´neamente alg´n CFD’s que est´n en formato o u a XML. 2 El sistema manda una notificaci´n de error. o 3 El sistema reinicia los pasos del caso de uso de “Generar Reporte Mensual” desde el paso 1 Excepci´n txtioerr o Paso Acci´n o 1 Existe un error en la escritura del reporte mensual 2 El sistema manda una notificaci´n de error. o 3 El sistema reinicia los pasos del caso de uso “Generar Reporte Mensual” desde el paso 4 Excepci´n saveerr o 1 Existe un error en el almacenamiento del reporte mensual 2 Se le notifica al usuario que haga de nuevo el reporte mensual Frecuencia esperada Cada d´ primero de cada vez ıa Importancia Alta, es necesario ya que el SAT lo solicita cada mes Cuadro C.9: Caso de Uso CU-07 CINVESTAV Departamento de Computaci´n o
  • 120. 104 Identificador Nombre Descripci´n o Precondici´n o Reporte Contable Acci´n “Visualizar Reporte Mensual” o El usuario puede ver el Reporte Mensual de todas las facturas emitidas. El usuario debe de haber ingresado a trav´s del control de e acceso de el sistema. Actores principales Usuario. Secuencia normal Paso Acci´n o 1 El usuario selecciona la opci´n “Reporte Contable” dentro o el men´ principal del sistema. u 2 Se muestra una lista de todas las facturas emitidas. 3 Se muestra la opci´n de regresar al menu principal. o Frecuencia esperada Cada vez que se quiera consultar las facturas emitidas. Importancia Visualizaci´n de las facturas emitidas o Urgencia Baja, no es indispensable para el funcionamiento del sistema, solo es de car´cter informativo para el usuario a Cuadro C.10: Caso de Uso CU-08 CINVESTAV Departamento de Computaci´n o
  • 121. Casos de uso 105 Identificador Nombre Descripci´n o Precondici´n o Consulta de CFD’s Acci´n “Consulta de CFD’s emitidos” o El usuario puede consultar los CFD’s emitidos. El usuario debe de haber ingresado a trav´s del control de e acceso del sistema. Se debe haber emitido al menos una factura. Actores principales Administrador, Usuario. Secuencia normal Paso Acci´n o 1 El usuario selecciona la opci´n “Consulta de CFD’s” dentro o del men´ principal del sistema. u 2 Se selecciona alguno de los siguientes filtros de b´squeda: u Emisor, Receptor o Producto. 3 Se inserta el criterio de b´squeda y se realiza la b´squeda sou u bre los CFD’s almacenados. Si existe un error en la b´squeda u en la base de datos se procede a la excepci´n databaseerr. o 4 Se muestra una lista de el/los CFD’s presentes en el dispositivo encontrados de acuerdo al criterio de la b´squeda o si u no la hay se muestra una notificaci´n de que no existieron o coincidencias en la b´squeda. u 5 Se selecciona el CFD deseado. 6 Se muestra a detalle el CFD emitido. 7 Se muestra la opci´n regresar de el men´ principal. o u Excepciones Excepci´n databaseerr. o Paso Acci´n o 1 Existe alg´n problema al acceder los datos en la base de datos. u 2 El sistema muestra una notificaci´n para volver a intentar la b´squeda. o u Frecuencia esperada Cada vez que el usuario consulte un CFD. Importancia Baja, no es indispensable para el funcionamiento primordial del sistema sin embargo es util para poder revisar una ´ bit´cora de que facturas se han emitido. a Cuadro C.11: Caso de Uso CU-09 CINVESTAV Departamento de Computaci´n o
  • 122. 106 Identificador Nombre Descripci´n o Precondici´n o Actores principales Secuencia normal Sincronizar datos Acci´n “Se sincronizan los cfd y la cartera de clientes con el o servidor para ser respaldados” El usuario elige la opci´n de sincronizar los datos, y estos o posteriormente ser´n respaldados. a Debe de existir al menos un cliente en la cartera de clientes o una factura emitida. Usuario, Servidor de respaldo. Paso Acci´n o 1 Se selecciona de la pantalla principal la opci´n “Sincronizar o Datos” 3 Los datos son mandados a un servidor v´ un canal seguro. ıa Si existe un error se procede a la excepci´n comerr o 4 El servidor recibe los datos. 5 Los datos son almacenados en una base de datos. 6 Se env´ una notificaci´n al dispositivo diciendo que los datos ıa o han sido respaldados correctamente. 7 El sistema recibe la notificaci´n y alerta al usuario que se o realizo con ´xito el respaldo. e 8 Se cambia el estado de los archivos a respaldados. 9 Se muestra la opci´n de regresar al men´ principal. o u Postcondici´n o Excepciones Excepci´n comerr o Paso Acci´n o 1 Se determina que no existe comunicaci´n hacia el servidor o o que la comunicaci´n ha sido interrumpida. o 2 El sistema muestra una notificaci´n avisando que el sistema o de sincronizaci´n ha fallado y se le pide al usuario que lo o realice posteriormente. Frecuencia esperada Cada vez que el administrador quiera respaldar los datos del dispositivo. Importancia Indispensable para que exista un respaldo de los datos del dispositivo. Cuadro C.12: Caso de Uso CU-10 CINVESTAV Departamento de Computaci´n o
  • 123. Ap´ndice D e Casos de maluso Numero: Nombre: Alcance: Prioridad: Ambiente: Anti-Actores: Niveles de derecho de acceso: Puntos de entrada: Atributos de seguridad afectados: Descripci´n: o Precondiciones: Suposiciones: Post-Condiciones: Perfiles de potenciales anti-actores: MC-01 Genera Factura sin acceso a llave privada(residual) Compromete la misi´n de la aplicaci´n o o Prioridad Alta Host y Aplicaci´n. o Usuarios no Autorizados Nivel Usuario Nivel Administrador Aplicaci´n o Autenticidad de la informaci´n,no repudio o Una vez que se ha generado una factura previa, es posible que la llave privada haya quedado en memoria. Dicha copia podr´ usarse para ıa generar una factura posteriormente y sin que esto requiera verificar al contenedor de la llave privada. Se accede a la llave privada para firmar una factura electr´nica de forma o local en el dispositivo(se requiere que por lo menos se haya generado una firma para poder realizar el ataque). Se accede al proceso gen factura() y se mantiene en memoria la copia de la llave privada. No se inicializ´ la variable que contiene la llave privada. No se cerro la sesi´n de la o o applicaci´n. Se tenian folios cargados en el dispositivo. o Se supone que este ataque se realiza mediante el robo del dispositivo. Peor Caso Se genera f´ctura v´lida a a sin aviso al contribuyente Medida de prevenci´n deseada o -Blanquear llave privada -Lock de la aplicaci´n. o Medida de detecci´n deseada o -Bitacora de la aplicaci´n o realizando un corte diario -Cruce de las facturas emitidas contra el SAT. Medidia de recuperaci´n deseada. -Revocar la llave privada. o -Litigio. Usuarios sin conocimiento t´cnico agudo. e 107
  • 124. 108 Clientes y amenazas: Casos de uso relacionados: Amenazas relacionadas: Recomendaciones arquitecturales: Pol´ ıticas de Recomendaci´n: o Clientes: creaci´n de facturas sin consentimiento del contribuyente. o Elevaci´n de privilegios, acceso no autorizado a la interfaz,autenticidad o de los datos, usurpaci´n de la identidad,repudiaci´n de la informaci´n. o o o -Se debe de realizar un bloqueo de la aplicaci´n cada 10 min si la aplio caci´n no esta en uso.-Cada vez que se realice un factura se de pedir el o password de la aplicaci´n o la del acceso a la llave privada.-Crear bitacoo ras de las operaciones dela aplicaci´n.-Blanqueo de la llave privada cada o vez que se ocupe. -Realizar cortes de caja al d´ y ver las facturas que se han emitidoıa El password que se utilice para generar la factura electr´nica debe o de ser cambiado peri´dicamente.-Contar con pol´ o ıticas para contrase˜as n fuertes.-Acciones de usuarios deben de ser revisadas peri´dicamente. o Cuadro D.2: Caso del Mal Uso MC-01 Numero: Nombre: Alcance: Prioridad: Ambiente: Anti-Actores: Niveles de derecho de acceso: Puntos de entrada: Atributos de seguridad afectados: Descripci´n: o Precondiciones: Suposiciones: Post-Condiciones: MC-02 Creaci´n de factura electr´nica a trav´s de robo del contenedor de la o o e llave privada Compromete el funcionamiento de la aplici´n o Alta. Hardware Usuarios no Autorizados Ninguno Hardware Auntenticiadad de la informaci´n o Un usuario extrae el contenedor donde se encuentran la factura electr´nio ca y los folios, e intentara realizar una factura electr´nica por sus propios o medios. El contenedor es extra´ del dispositivo. Se cuenta con una aplicaci´n ıdo o similar para realizar la aplicaci´n de facturaci´n electr´nica. Se tienen o o o folios precargados. Peor Caso Medida de prevenci´n deseada o Medida de detecci´n deseada o Medidia de recuperaci´n deseada. o Perfiles de potenciales anti-actores: Clientes y amenazas: Casos de uso relacionados: Amenazas relacionadas: Recomendaciones arquitecturales: Pol´ ıticas de Recomendaci´n: o Crea una factura electr´nica. o Los datos que esten en el contenedor deben de estar cifrados Bitacora de acciones realizadas en el dispositivo. -Revocar la llave privada. -Respaldar datos importantes Usuario sin conocimientos t´cnicos. e Clientes: creaci´n de facturas sin consentimiento del contribuyente. o Acceso no autorizado a la interfaz,Usurpaci´n de la identio dad,repudiaci´n de la informaci´n. o o -Se debe de tener una bit´cora de las acciones que se realicen en el a dispositivo.-Los datos como los folios, llave privada deben de estar cifrados en el contenerodr. -Hacer un cruce de las facturas emitidas contra el SAT y verificar cuales de estas no se han emitido por el contribuyente. Cuadro D.3: Caso del Mal Uso MC-02 CINVESTAV Departamento de Computaci´n o
  • 125. Casos de maluso 109 Numero: Nombre: Alcance: Prioridad: Ambiente: Anti-Actores: Niveles de derecho de acceso: Puntos de entrada: Atributos de seguridad afectados: Descripci´n: o Precondiciones: Suposiciones: Post-Condiciones: Perfiles de potenciales anti-actores: Clientes y amenazas: Amenazas relacionadas: Recomendaciones arquitecturales: MC-03 Suplantaci´n de contribuyente al generar facturas a su nombre. o Compromete el funcionamiento de la aplicaci´n. o Alta. Hardware del dispositivo. Usuarios no Autorizados Ninguno Hardware del dispositivo. Autenticidad de la informaci´n, no repudio, integridad de los datos cono tenidos Se extrae el contenedor del dispositivo y se ingresan otros datos de diferente contribuyente con folios v´lidos. a Se introduce informaci´n mediante otro contenedor de datos o Se tiene acceso directo al dispositivo Peor Caso Se realiza una factura con otros datos. Medida de prevenci´n deseada o Verificar los datos del certificado contra los del servidor. Medida de detecci´n deseada o -Tener bit´cora de las accia ones del emisor de la factura. Medidia de recuperaci´n deseada. -Revocaci´n de el certificado. o o -Notificaci´n al SAT o Usuarios sin conocimientos t´cnicos agudos. e Clientes: creaci´n de facturas sin consentimiento del contribuyente. o Acceso no autorizado a la interfaz,Usurpaci´n de la identio dad,repudiaci´n de la informaci´n,modificaci´n de datos o o o -Contar con un servidor de base de datos que tenga la informaci´n de o el contribuyente.-Se debe de tener una bit´cora de las acciones que se a realicen en el dispositivo. Cuadro D.4: Caso del Mal Uso MC-03 CINVESTAV Departamento de Computaci´n o
  • 126. 110 Numero: Nombre: Alcance: Prioridad: Ambiente: Anti-Actores: Niveles de derecho de acceso: Puntos de entrada: Atributos de seguridad afectados: Descripci´n: o Precondiciones: Suposiciones: Post-Condiciones: Perfiles de potenciales anti-actores: Clientes y amenazas: Amenazas relacionadas: Recomendaciones arquitecturales: Cuadro D.5: Caso del Mal Uso MC-04 CINVESTAV MC-04 Creaci´n de una factura electr´nica accediendo a la llave privada. o o Compromete el funcionamiento de la aplicaci´n. o Alta. Hardware del dispositivo. Usuarios no Autorizados Ninguno Hardware del dispositivo. Autenticidad de los datos, no repudio Se obtiene la llave privada haciendo un volcado de memoria hacia el dispositivo buscando residuos de la llave privada que se ocupo para realizar la llave privada. 1) El atacante obtiene acceso al dispositivo 2) El atacante hace un volcado de memoria para ver si es posible encontrar la llave privada. 3) Se tuvo que haber realizado por lo menos una vez la factura para poder obtener informaci´n mediante el volcado de memoria. 4) Se accede o mediante otra aplicaci´n que realice facturaci´n electr´nica con la llave o o o privada extra´ por el volcado de memoria. 5) Se accede al m´todo de ıda e generar factura de dicha aplicaci´n. o Se cuentan con folios del contribuyente al cual se le esta realizando el ataque Peor Caso El atacante obtiene la llave privada y puede realizar facturas sin consentimiento del contribuyente. Medida de prevenci´n deseada o Blanqueo de memoria de la llave privada. Medida de detecci´n deseada o Medidia de recuperaci´n deseada. -Revocaci´n de la llave privada. o o Usuarios sin conocimientos t´cnicos agudos. e Clientes: creaci´n de facturas sin consentimiento del contribuyente. o Acceso no autorizado a la interfaz,Usurpaci´n de la identio dad,repudiaci´n de la informaci´n,revelaci´n de informaci´n. o o o o Blanqueo de memoria Departamento de Computaci´n o
  • 127. Casos de maluso 111 Numero: Nombre: Alcance: Prioridad: Ambiente: Anti-Actores: Niveles de derecho de acceso: Puntos de entrada: Atributos de seguridad afectados: Descripci´n: o Precondiciones: Suposiciones: Post-Condiciones: Perfiles de potenciales anti-actores: Clientes y amenazas: Casos de uso relacionados: Amenazas relacionadas: Recomendaciones arquitecturales: MC-05 Creaci´n de Factura generando un certificado de sello digital apocrifo. o Compromete el funcionamiento de la aplicaci´n. o Alta Hardaware Usuario no autorizado Nivel Usuario Nivel Administrador Dispositivo Autenticiadad de los datos,No repudio Debido a que el sello digital es realizado con funciones picadillo obseletas(MD-5,SHA-1) es posible que se generen certificados falsos que parezcan v´lidos. a 1.- Se inserta un certificado que parece v´lido.2.- Se accede al m´todo a e de gen factura. 3. Se cuenta con folios en el dispositivo.4.La autoridad certificadora no detecta que el certificado es inv´lido a Se cuenta con infraestructura necesaria para encontrar colisiones en las funciones picadillo MD-5,SHA-1,SHA-2 Peor Caso Se genera una factura. Medida de prevenci´n deseada o Cambiar los algoritmos para realizar funciones picadillo Medida de detecci´n deseada o No existe Medidia de recuperaci´n deseada. No existe o Usuarios especializados con conocimiento t´cnicos avanzados e Clientes: creaci´n de facturas sin consentimiento del contribuyente. o Usurpaci´n de la identidad o -Cambiar los est´ndares propuestos por el SAT(proponer SHA-512 por a el momento). Cuadro D.6: Caso del Mal Uso MC-05 CINVESTAV Departamento de Computaci´n o
  • 128. 112 Numero: Nombre: Alcance: Prioridad: Ambiente: Anti-Actores: Niveles de derecho de acceso: Puntos de entrada: Atributos de seguridad afectados: Descripci´n: o Precondiciones: Suposiciones: Post-Condiciones: MC-06 Modificar/eliminar los datos del CFD o datos de la cartera de clientes mediante su transporte hacia el receptor o hacia el servidor del respaldo. Compromete el funcionamiento de la aplicaci´n. o Baja Internet Integridad de la informaci´n,Disponibilidad o Nivel usuario o admininstrador Canal de transmisi´n o Autenticidad de los datos Mediante el transporte de los datos se logra interceptar el cfd, o datos y se modifica o elimina la informaci´n ahi contenida. De igual manera se o puede interceptar el CFD para provocar un ataque de DOS 1.- Un atacante se encuentra escuchando el canal por el que se mandan los datos.2.- El atacante obtiene el CFD u otros datos, y modifica o elimina los datos que solo le convengan a el. Si modifica el CFD crea el sello digital con los datos nuevos generando una nueva factura v´lida.3. a Otra opci´n es que el adversario robe por completo el CFD.3. Se reenvia o los datos modificados al receptor Peor Caso Medida de prevenci´n deseada o Medida de detecci´n deseada o Perfiles de potenciales anti-actores: Clientes y amenazas: Casos de uso relacionados: Amenazas relacionadas: Recomendaciones arquitecturales: Cuadro D.7: Caso del Mal Uso MC-06 CINVESTAV Se modifican/eliminan los datos con exito. -Transporte de los datos mediante un canal seguro -Cruce de facturas con el emisor Medidia de recuperaci´n deseada. o Usuarios con conocimiento t´cnico agudo. e Clientes: Modificaci´n de facturas sin consentimiento del contribuyente. o Alteraci´n de la informaci´n, Revelaci´n de la informaci´n, Suplantaci´n o o o o o de identidad,Denegaci´n de servicio o -Contar con un canal seguro Departamento de Computaci´n o
  • 129. Casos de maluso 113 Numero: Nombre: Alcance: MC-07 Saltar el control de acceso de la aplicaci´n. o Generar una factura,Modificar informaci´n sensible del sistema como el o login,crear clientes falsos. Prioridad: Alta. Ambiente: Aplicaci´n o Anti-Actores: Usuarios no autorizados Niveles de derecho de acceso: Admininstrador o usuario Puntos de entrada: Aplicaci´n. o Atributos de seguridad afectados: Autenticaci´n o Descripci´n: o El atacante realiza alguna de las siguientes acciones: ataque de diccionario,explota control de acceso d´bil, explota vulnerabilidad de e S0/aplicaci´n, para tratar de obtener acceso al dispositivo para poso teriormente realizar una factura. Precondiciones: Se cuenta con acceso al dispositivo Se accede a la aplicaci´n por medio o de control de acceso. Se realiza alguna de las siguientes acciones:taque de diccionario,explota control de acceso d´bil, explota vulnerabilidad de e S0/aplicaci´n. Se deben de tener folios precargados. 5. Se accede al moo dulo para generar facturas electr´nicas, al de modificar login del sistema, o o al de crear nuevo cliente. Post-Condiciones: Peor Caso Se crean cfd’s, se modifica la informaci´n o del cliente o se crea un cliente con ´xito. e Medida de prevenci´n deseada -Tener pol´ o ıticas de password seguras -Bloquear la aplicaci´n o -Digesto de la contrase˜a n Medida de detecci´n deseada o -Tener una bitacora de las acciones realizadas en la aplicaci´n o Medidia de recuperaci´n deseada.-Bloquear la aplicaci´n despues o o de tres intentos Perfiles de potenciales anti-actores:Usuarios con conocimientos t´cnicos avanzados e Clientes y amenazas: Clientes: Creaci´n de facturas sin conocimientos del contribuyente o Casos de uso relacionados: Amenazas relacionadas: Suplantaci´n,Repudiaci´n, Denegaci´n de servicio,Elevaci´n de privileo o o o gios. Recomendaciones arquitecturales: Bit´cora de la aplicaci´n, digesto de la contrase˜a a o n Recomendaciones arquitecturales: Pol´ ıticas de contrase˜as seguras n CINVESTAV Departamento de Computaci´n o
  • 130. 114 Numero: Nombre: Alcance: Prioridad: Ambiente: Anti-Actores: Niveles de derecho de acceso: Puntos de entrada: Atributos de seguridad afectados: Descripci´n: o Precondiciones: Post-Condiciones: Perfiles de potenciales anti-actores: Clientes y amenazas: Casos de uso relacionados: Amenazas relacionadas: Recomendaciones arquitecturales: MC-08 Modificaci´n de los comprobantes fiscales digitales. o Compromente la integridad de los datos contenidos en la aplicaci´n o Alta Aplicaci´n o Usuarios no autorizados Ninguno Hardware Autenticidad de la informaci´n o Como se sabe los comprobantes digitales emitidos deben de ser guardados por 5 a˜os, esta tarea es delegada al contribuyente por lo que en n caso de que alg´n algoritmo criptogr´fico sea roto como se menciona en u a MC-05 podemos comprometer la seguridad de los CFD’s almacenados. Se tiene acceso directo al contenedor del dispositivo. Se vulnera los CFD’s ya que algun algoritmo de utilizado en la especificaci´n del anexo 20 ha o sido roto en un tiempo no mayor a 5 a˜os. n Peor Caso Se vulnera los CFD’s Medida de prevenci´n deseada o -Tener previstos los cambios de algoritmos criptogr´ficos. a Medida de detecci´n deseada o Ninguno Medidia de recuperaci´n deseada. Cambiar algoritmos o criptogr´ficos a Usuarios con conocimientos t´cnicos avanzados e Clientes: Alteraci´n de CFD almacenados a largo plazo o Modificaci´n de la informaci´n o o -Integrar un mecanismo de almacenamiento a largo plazo para evitar su modificaci´n o Cuadro D.8: Caso del Mal Uso MC-08 CINVESTAV Departamento de Computaci´n o
  • 131. Casos de maluso 115 Numero: Nombre: Alcance: Prioridad: Ambiente: Anti-Actores: Niveles de derecho de acceso: Puntos de entrada: Atributos de seguridad afectados: Descripci´n: o Precondiciones: Post-Condiciones: Perfiles de potenciales anti-actores: Clientes y amenazas: Amenazas relacionadas: Pol´ ıticas de Recomendaci´n: o Cuadro D.9: Caso del Mal Uso MC-09 CINVESTAV MC-09 Modificaci´n/Eliminaci´n de los datos respaldados en la base de datos o o local del dispositivo. Aplicaci´n o Alta Host Usuarios no autorizados Ninguno Aplicaci´n o Confidencialidad,integridad Se accede por una aplicaci´n diferente a la de facturaci´n a la base o o de datos local donde se guarda la informaci´n y esta es modificada o o eliminada. 1.- Se cuenta con una aplicaci´n que puede leer las base de datos locao les del dispositivo.2.- Las base de datos para acceder a ella tienen un password debil o el que esta por defecto. Peor Caso Se modifican/eliminan los datos con exito del reporte mensual Medida de prevenci´n deseada o Contar con contrase˜as fuertes n para entrar a la base de datos Medida de detecci´n deseada o Medidia de recuperaci´n deseada. o Usuarios con conocimientos avanzados Clientes: Eliminaci´n de datos o Modificaci´n/Eliminaci´n de la informaci´n o o o Pol´ ıticas de contrasen˜s seguras en la BD. a Departamento de Computaci´n o
  • 132. 116 Numero: Nombre: Alcance: Prioridad: Ambiente: Anti-Actores: Niveles de derecho de acceso: Puntos de entrada: Atributos de seguridad afectados: Descripci´n: o Precondiciones: Post-Condiciones: Perfiles de potenciales anti-actores: Clientes y amenazas: Amenazas relacionadas: Recomendaciones arquitecturales: Cuadro D.10: Caso del Mal Uso MC-10 CINVESTAV MC-10 Modificar/eliminar los datos del CFD, datos de clientes o usuarios ganando acceso directo hacia el dispositivo Compromete el funcionamiento de la aplicaci´n. o Alta Host Integridad de la informaci´n,Disponibilidad o Nivel usuario o administrador Host Autenticidad de los datos, integridad, disponibilidad. Mediante los siguientes ataques: robo del dispositivo, explotar un control de acceso d´bil o una vulnerabilidad en el sistema operativo se logra e obtener acceso a par´metros susceptibles en la aplicaci´n y estos son a o modificados. 1.- El atacante obtiene el CFD u otros datos, y modifica o elimina los datos que solo le convengan a el. En el caso del CFD crea el sello digital con los datos nuevos generando una nueva factura v´lida. a Peor Caso Se modifican/eliminan los datos con exito. Medida de prevenci´n deseada o -Los parametros sensibles deben estar cifrados(contenedor seguro) Medida de detecci´n deseada o -Realizar funci´n de autoprueba o para comprobar integridad de datos. Medidia de recuperaci´n deseada. o Usuarios con conocimiento t´cnico agudo. e Clientes: Modificaci´n de facturas sin consentimiento del contribuyente. o Alteraci´n de la informaci´n, Revelaci´n de la informaci´n, Suplantaci´n o o o o o de identidad. -Contar con un contenedor seguro.-Tener una funci´n de autoprueba. o Departamento de Computaci´n o
  • 133. Casos de maluso 117 Numero: Nombre: Alcance: Prioridad: Ambiente: Anti-Actores: Niveles de derecho de acceso: Puntos de entrada: Atributos de seguridad afectados: Descripci´n: o Precondiciones: Post-Condiciones: Perfiles de potenciales anti-actores: Clientes y amenazas: Amenazas relacionadas: Recomendaciones arquitecturales: Cuadro D.11: Caso del Mal Uso MC-11 CINVESTAV MC-11 Modificar/eliminar los datos del CFD datos clientes o usuarios ganando acceso directo hacia el servidor de respaldo Compromete el funcionamiento de la aplicaci´n. o Alta Servidor Integridad de la informaci´n,Disponibilidad o Nivel usuario o administrador Servidor Autenticidad de los datos, integridad, disponibilidad. Mediante los siguientes ataques: robo del servidor, mala administraci´n o de cuentas de usurario, o una contrase˜a d´bil en el servidor el usuario n e elimina o modifica los CFD o datos de clientes o usuarios 1.- El atacante obtiene el CFD u otros datos, y modifica o elimina los datos que solo le convengan a el. En el caso del CFD crea el sello digital con los datos nuevos generando una nueva factura v´lida. a Peor Caso Se modifican/eliminan los datos con exito. Medida de prevenci´n deseada o -Los parametros sensibles deben de estar cifrados (contenedor seguro) Medida de detecci´n deseada o Medidia de recuperaci´n deseada. o Usuarios con conocimiento t´cnico agudo. e Clientes: Modificaci´n de facturas sin consentimiento del contribuyente. o Alteraci´n de la informaci´n, Revelaci´n de la informaci´n, Suplantaci´n o o o o o de identidad. -Contar con un contenedor seguro en el servidor Departamento de Computaci´n o
  • 134. 118 CINVESTAV Departamento de Computaci´n o
  • 135. Ap´ndice E e Arboles de ataque 119
  • 136. CINVESTAV ´ Figura E.2: Arbol de ataque: Modificar/Eliminar CFD ´ Figura E.1: Arbol de ataque: crear factura 120 Departamento de Computaci´n o
  • 137. ´ Figura E.3: Arbol de ataque: Modificar/Eliminar datos Arboles de ataque 121 CINVESTAV Departamento de Computaci´n o
  • 138. 122 CINVESTAV Departamento de Computaci´n o
  • 139. Bibliograf´ ıa [1] SANS Password Policy, web page www.sans.org. [2] Secretar´ de Hacienda y Cr´dito P´blico. Diario Oficial de la Federaci´n, Anexo ıa e u o 20 de la Resoluci´n Miscel´nea, 11 de junio 2010. o a [3] Secure Coding Guidelines for the Java Programming Language Version 3.0, http://www.oracle.com/technetwork/java/seccodeguide-139067.html. [4] Servicio de Administraci´n Tributaria. SAT (M´xico), Resoluci´n Miscel´nea o e o a Fiscal, 2010 . [5] Servicio de Administraci´n o http://www.sat.com.mx . Tributaria. SAT (M´xico), e web page [6] Simple XML Serialization, web page http://simple.sourceforge.net/. [7] The Stride Threat Model, MSDN http://msdn.microsoft.com/en-us/library/ . Library, web page. [8] C. Adams and S. Farrell. Internet X. 509 public key infrastructure certificate management protocols, 1999. [9] C. Adams and S. Lloyd. Understanding PKI: concepts, standards, and deployment considerations. Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA, 2002. [10] Deepa Padmanabhan Nancy R. Mead Ashwin Gayash, Venkatesh Viswanathan. SQUARE-Lite: Case Study on VADSoft Project. 2008. [11] Mary Beth Chrissis, Mike Konrad, and Sandy Shrum. CMMI Guidelines for Process Integration and Product Improvement. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2003. [12] M. Graff and K. van Wyk. Secure Coding: Principles and Practices. Sebastopol. O’Reilly, 2003. [13] M. Howard and D.E. Leblanc. Writing secure code. Microsoft Press Redmond, WA, USA, 2002. 123
  • 140. 124 BIBLIOGRAF´ IA [14] Michael Howard and Steve Lipner. The Security Development Lifecycle. Microsoft Press Redmond, WA, USA, 2005. [15] Julia H. Allen and Dr. Robert and J. Ellison and Dr. Nancy and R. Mead and Cigital Inc. A look at software security engineering: A guide for project managers, 2008. [16] J. Jurjens. Towards development of secure systems using UMLsec. Fundamental Approaches to Software Engineering, 2001. [17] J. Jurjens. UMLsec: Extending UML for Secure Systems Development, UML 2002. Lecture Notes in Computer Science, 2460, 2002. [18] J. Jurjens. Using UMLsec and goal trees for secure systems development. In Proceedings of the 2002 ACM symposium on Applied computing. ACM, 2002. [19] B. Kaliski. Pkcs #5: Password-based cryptography specification version 2.0, 2000. [20] N.R. Mead and T. Stehney. Security quality requirements engineering (SQUARE) methodology. In Proceedings of the 2005 workshop on Software engineering for secure systems for building trustworthy applications. ACM, 2005. [21] Menezes, Alfred J. and Vanstone, Scott A. and Oorschot, Paul C. Van. Handbook of Applied Cryptography. CRC Press, Inc., Boca Raton, FL, USA, 1st edition, 1996. [22] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams. X. 509 Internet public key infrastructure online certificate status protocol-OCSP, 1999. [23] National Institute of standards and Technology. SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES, FIPS 140-3, 2009. [24] Christof Paar and Jan Pelzl. Understanding Cryptography - A Textbook for Students and Practitioners. Springer, 2010. [25] G. Sindre and A.L. Opdahl. Eliciting security requirements with misuse cases. Requirements Engineering, 10(1), 2005. [26] Ian Sommerville. Software engineering (5th ed.). Addison Wesley Longman Publishing Co., Inc., Redwood City, CA, USA, 1995. [27] W. Stallings. Cryptography and network security. Prentice Hall New Jersey, 2003. [28] Douglas R. Stinson. Cryptography: Theory and Practice, Third Edition (Discrete Mathematics and Its Applications). Chapman & Hall/CRC, November 2005. CINVESTAV Departamento de Computaci´n o
  • 141. BIBLIOGRAF´ 125 IA [29] F. Swiderski and W. Snyder. Threat modeling. Microsoft Press Redmond, WA, USA, 2004. [30] Dan Taylor and Gary McGraw. Adopting a software security improvement program. IEEE Security and Privacy, 3:88–91, 2005. [31] W. Trappe, L. Washington, M. Anshel, and K.D. Boklan. Introduction to cryptography with coding theory. 2007. CINVESTAV Departamento de Computaci´n o

×