´
CENTRO DE INVESTIGACION Y DE
ESTUDIOS AVANZADOS
´
DEL INSTITUTO POLITECNICO NACIONAL

Unidad Zacatenco
Departamento de C...
ii
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...
iv

RESUMEN
Abstract
The use of electronic invoice in Mexico has spread in the last years since its
introduction in 2004. The Mexican ...
vi

ABSTRACT
Agradecimientos
Agradezco al CINVESTAV, ya que durante este tiempo curse materias que me
apasionaron y pude ampliar mi per...
viii

AGRADECIMIENTOS
´
Indice general
Resumen

III

Abstract

V

Agradecimientos

VII

´
Indice de figuras

IX

´
Indice de tablas

XI

1. Dise˜...
´
INDICE GENERAL

x

2.2.1. Criptograf´ . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ıa

11

2.2.2. Criptografi´...
´
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 ...
´
INDICE GENERAL

xii
6. Conclusiones y trabajo a futuro

87

6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . ...
´
Indice de figuras
2.1. Elementos de un Comprobante Fiscal Digital . . . . . . . . . . . . . .

10

2.2. Esquema de cripto...
xiv

´
INDICE DE FIGURAS

4.18. Diagrama de clase: Firma electr´nica . . . . . . . . . . . . . . . . . .
o

64

4.19. Diag...
´
Indice de cuadros
4.1. Metodolog´ SQUARE-Lite . . . . . . . . . . . . . . . . . . . . . . .
ıa

39

4.4.

Generaci´n de ...
xvi

´
INDICE DE CUADROS

D.9. Caso del Mal Uso MC-09 . . . . . . . . . . . . . . . . . . . . . . . . . 115
D.10.Caso del ...
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 abo...
2 Cap´
ıtulo 1
informaci´n sea comprometida. Debido a esto el SAT ha incorporado mecanismos pao
ra certificar e identificar ...
Dise˜o de la investigaci´n 3
n
o
Por otra parte con el advenimiento de servicios digitales se est´ tratando realizar
a
la ...
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...
Dise˜o de la investigaci´n 5
n
o
4. Pruebas de seguridad: Se har´n pruebas espec´
a
ıficas para encontrar efectos
colateral...
6 Cap´
ıtulo 1
Software Adicional
Adicionalmente para el desarrollo de este trabajo se utilizaron las siguientes herramien...
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...
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...
Facturaci´n Electr´nica en M´xico 9
o
o
e
Valor unitario, importe total y monto de los impuestos.
La cadena original con l...
10 Cap´
ıtulo 2

Figura 2.1: Elementos de un Comprobante Fiscal Digital

CINVESTAV

Departamento de Computaci´n
o
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...
12 Cap´
ıtulo 2

Figura 2.2: Esquema de criptogr´ de llave privada
ıa

La misma llave secreta es usada para cifrar y desci...
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 u...
14 Cap´
ıtulo 2
4. Dado dos mensajes diferentes debe de ser computacionalmente imposible que
tengan la misma huella digita...
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 es...
16 Cap´
ıtulo 2
La infraestructura de llave p´blica (PKI) es un conjunto de hardware, software,
u
pol´
ıticas y procedimie...
Facturaci´n Electr´nica en M´xico 17
o
o
e
membres´ de un individuo en una clase de usuarios especificados, sin especificar ...
18 Cap´
ıtulo 2
Firma Electr´nica Avanzada (FIEL) y certificado de firma electr´nica.
o
o
Certificados de Sello Digital (CSD)...
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
...
20 Cap´
ıtulo 2

Figura 2.5: Modelo operativo de la Facturaci´n Electr´nica
o
o

CINVESTAV

Departamento de Computaci´n
o
Cap´
ıtulo 3
Desarrollo de Software Seguro
En este cap´
ıtulo se detallan los fundamentos te´ricos que sirven como base pa...
22 Cap´
ıtulo 3
La idea de este enfoque es perfeccionar el desarrollo de la aplicaci´n y crear prototipos
o
automatizados ...
Desarrollo de Software Seguro 23

3.1.6.

Capability Maturity Model Integration

La integraci´n de Modelos de Madurez y Ca...
24 Cap´
ıtulo 3

3.2.2.

Ciclo de vida de Desarrollo Confiable de Microsoft

El ciclo de vida de Desarrollo Confiable de Mic...
Desarrollo de Software Seguro 25
Fase 5: Crear documentos de seguridad, herramientas, y mejores pr´cticas para
a
clientes:...
26 Cap´
ıtulo 3

Figura 3.1: Ciclo de vida de seguridad de McGraw y Taylor

En la fase de seguridad de requerimientos se m...
Desarrollo de Software Seguro 27
que ayudan a realizar el modelado de componentes cr´
ıticos y amenazas que puedan
present...
28 Cap´
ıtulo 3
7. Clasificaci´n de los requisitos. Esta fase consiste en distinguir entre los
o
requerimientos esenciales,...
Desarrollo de Software Seguro 29
Para seguir el m´todo STRIDE, se descompone el sistema en componentes signifie
cativos, tr...
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 e...
Desarrollo de Software Seguro 31
Pruebas Unitarias Se utilizan usualmente en la primera etapa de pruebas e
involucra proba...
32 Cap´
ıtulo 3

CINVESTAV

Departamento de Computaci´n
o
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 ...
34 Cap´
ıtulo 4
Reporte Contable
Consulta de CFD’s

4.1.3.

Caracter´
ısticas del usuario

El sistema esta destinado a per...
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 te...
36 Cap´
ıtulo 4
2. Correo electr´nico
o
3. Direcci´n:
o
4. RFC
Los datos del cliente se guardaran localmente en el disposi...
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 cont...
38 Cap´
ıtulo 4
R.14 Extracci´n de la informaci´n del Certificado Digital
o
o
Debido que el certificado digital generado por...
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
De...
40 Cap´
ıtulo 4
mostraremos un ejemplo de objetivo de seguridad identificado para el contexto de la
aplicaci´n a desarrolla...
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´...
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Tesis rodrigojurado
Upcoming SlideShare
Loading in …5
×

Tesis rodrigojurado

903 views

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
903
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Tesis rodrigojurado

  1. 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. 2. ii
  3. 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. 4. iv RESUMEN
  5. 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. 6. vi ABSTRACT
  7. 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. 8. viii AGRADECIMIENTOS
  9. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 26. 10 Cap´ ıtulo 2 Figura 2.1: Elementos de un Comprobante Fiscal Digital CINVESTAV Departamento de Computaci´n o
  27. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 48. 32 Cap´ ıtulo 3 CINVESTAV Departamento de Computaci´n o
  49. 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. 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. 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. 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. 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. 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. 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. 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. 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

×