Aplicación de bloqueo para la prevención de Shoulder Surfing

Seguridad en Android: Aplicación de
bloqueo para la prevención de Shoulder
Surfing
Cristian Torres Barrantes
Trabajo de Fin de Grado dirigido por
Manel Medina Llinàs
Departamento de Arquitectura de Computadores
Facultat d’Informàtica de Barcelona
Universitat Politècnica de Catalunya
Junio 2016
Resumen
Desde que a finales de 2008 salió al mercado la primera versión oficial del sistema operativo Android ha ido aumentando el número de usuarios de smartphones hasta que, en la
actualidad, el 82.8 % de éstos utilizan este sistema. Ante este hecho, el mundo del cibercrimen se ha volcado para encontrar vectores de ataque que permitan obtener los datos
privados de los usuarios. En este contexto, el proyecto que se presenta a continuación
pretende estudiar los mecanismos actuales de seguridad que son inherentes en Android,
las principales extensiones que resuelven situaciones no contempladas por los creadores
de este sistema y los principales métodos usados para comprometer la privacidad de
los usuarios. Por otro lado, se desarrolla una aplicación para proteger la sustracción de
información sensible de dichos usuarios ante un tipo concreto de ataque de ingenierı́a
social: Shoulder Surfing.
Índice
Resumen
I
Índice de figuras
V
Índice de códigos
VIII
Índice de tablas
X
1. Introducción
1.1. Formulación del problema . .
1.2. Contextualización . . . . . . .
1.2.1. Definición del contexto
1.2.2. Actores implicados . .
1.3. Estado del arte . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
2
2
3
2. Alcance del proyecto
2.1. Definición del alcance . . . . . . . .
2.2. Riesgos y obstáculos . . . . . . . . .
2.3. Metodologı́a y rigor . . . . . . . . .
2.3.1. Métodos de trabajo . . . . .
2.3.2. Herramientas de seguimiento
2.3.3. Métodos de validación . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
6
6
6
7
8
.
.
.
.
.
.
9
9
11
11
12
12
13
.
.
.
.
.
14
14
14
15
17
17
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3. Pliegue de condiciones
3.1. Descripción y motivación . . . . . . . .
3.2. Entorno . . . . . . . . . . . . . . . . . .
3.3. Estado actual . . . . . . . . . . . . . . .
3.4. Diseño arquitectónico e Implementación
3.5. Gestión de riesgos . . . . . . . . . . . .
3.6. Competencias técnicas de la especialidad
.
.
.
.
.
.
.
.
.
.
.
.
4. Planificación temporal
4.1. Planificación estimada del proyecto . . . . .
4.2. Descripción de las tareas . . . . . . . . . . .
4.3. Diagrama de Gantt . . . . . . . . . . . . . .
4.4. Recursos . . . . . . . . . . . . . . . . . . . .
4.5. Valoración de alternativas y plan de acción
ii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Índice
iii
5. Fundamentos teóricos
5.1. Sistemas Android . . . . . . . . . . . . . . .
5.1.1. Arquitectura del sistema . . . . . . .
5.1.1.1. Kernel . . . . . . . . . . . .
5.1.1.2. Librerı́as . . . . . . . . . .
5.1.1.3. Runtime . . . . . . . . . .
5.1.1.4. Framework de la aplicación
5.1.1.5. Aplicaciones . . . . . . . .
5.1.2. Arquitectura de una aplicación . . .
5.1.2.1. Android Manifest . . . . .
5.1.2.2. Actividades . . . . . . . . .
5.1.2.3. Servicios . . . . . . . . . .
5.1.2.4. Content providers . . . . .
5.1.2.5. Broadcast recievers . . . .
5.2. Seguridad en Android . . . . . . . . . . . .
5.2.1. Modelo de seguridad . . . . . . . . .
5.2.1.1. Sandboxing . . . . . . . . .
5.2.1.2. Gestión de permisos . . . .
5.2.1.3. Acceso a memoria . . . . .
5.2.1.4. Protección de datos . . . .
5.2.1.5. Signatura de código . . . .
5.2.1.6. Binder . . . . . . . . . . .
5.2.1.7. SEAndroid . . . . . . . . .
5.2.2. Extensiones de seguridad . . . . . .
5.2.2.1. Kirin . . . . . . . . . . . .
5.2.2.2. AdDroid . . . . . . . . . .
5.2.2.3. XManDroid . . . . . . . . .
5.2.2.4. ASF . . . . . . . . . . . . .
5.2.2.5. TaintDroid . . . . . . . . .
5.3. Inseguridad de la información . . . . . . . .
5.3.1. Ingenierı́a social . . . . . . . . . . .
5.3.1.1. Shoulder Surfing . . . . . .
5.3.1.2. Tapjacking . . . . . . . . .
6. Desarrollo del proyecto
6.1. Descripción de la aplicación . . . . . . .
6.2. Procedimiento . . . . . . . . . . . . . . .
6.3. Diagrama de flujo . . . . . . . . . . . . .
6.4. Funcionalidades . . . . . . . . . . . . . .
6.4.1. Estado de la protección . . . . .
6.4.2. Establecer PIN . . . . . . . . . .
6.4.3. Establecer taps invisibles . . . .
6.4.4. Entrenamiento . . . . . . . . . .
6.4.5. Historial . . . . . . . . . . . . . .
6.4.6. Protección de aplicaciones . . . .
6.4.7. Protección de contenido privado
6.4.8. Servicio . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18
18
19
20
21
21
22
23
24
25
25
27
28
29
30
30
30
31
32
33
34
34
35
37
38
39
41
42
44
45
46
48
49
.
.
.
.
.
.
.
.
.
.
.
.
52
52
54
55
58
59
61
63
68
70
72
75
80
Índice
iv
6.4.9. Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7. Gestión económica
7.1. Consideraciones iniciales .
7.2. Identificación y estimación
7.2.1. Costes directos . .
7.2.2. Costes indirectos .
7.2.3. Contingencia . . .
7.2.4. Imprevistos . . . .
7.2.5. Presupuesto . . . .
7.3. Control de gestión . . . .
. . . . . .
de costes
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
8. Sostenibilidad y compromiso social
8.1. Valoración de la sostenibilidad . .
8.2. Económica . . . . . . . . . . . . . .
8.3. Social . . . . . . . . . . . . . . . .
8.4. Ambiental . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
83
83
83
84
85
86
86
86
87
.
.
.
.
88
88
88
89
90
9. Conclusiones
91
Bibliografı́a
92
Índice de figuras
4.1. Datos del diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Arquitectura del sistema operativo Android . . . . . . . . . . . . . . . . . 19
5.2. Arquitectura de una aplicación . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3. Ciclo de vida de una Activity . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.4. Ciclo de vida de un servicio . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.5. Funcionamiento de los Content Providers . . . . . . . . . . . . . . . . . . 29
5.6. Comunicación entre procesos mediante Binder . . . . . . . . . . . . . . . . 35
5.7. Extensiones de seguridad
. . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.8. Comunicación entre librerı́as de publicidad y Android . . . . . . . . . . . 39
5.9. Comunicación entre librerı́as de publicidad y Android usando AdDroid . . 40
5.10. Arquitectura de seguridad de Android . . . . . . . . . . . . . . . . . . . . 43
5.11. Arquitectura de seguridad implantada por ASF . . . . . . . . . . . . . . . 43
5.12. Seguimiento multinivel de recursos de TaintDroid . . . . . . . . . . . . . . 44
5.13. Tapjacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.14. Tapjacking con pantalla transparente . . . . . . . . . . . . . . . . . . . . . 50
6.1. Panel Configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2. Panel Protección . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
v
Lista de figuras
vi
6.3. Diagrama de flujo ideal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.4. Espera activa del servicio . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.5. Pila de tareas recientemente abiertas . . . . . . . . . . . . . . . . . . . . . 57
6.6. Comprobación de cambio de aplicación . . . . . . . . . . . . . . . . . . . . 58
6.7. Diagrama de flujo final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.8. Opciones disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.9. Protección deshabilitada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.10. Establecer PIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.11. Ventana de bloqueo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.12. Bloqueo principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.13. Restablecer PIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.14. Taps con transparencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.15. Taps sin transparencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.16. Introducción de taps I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.17. Introducción de taps II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.18. Modificación del radio I . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.19. Modificación del radio II . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.20. Taps establecidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.21. Pantalla introductoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.22. Taps de entrenamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.23. Visualización gráfica I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.24. Resultados I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.25. Visualización gráfica II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.26. Resultados II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.27. Historial de accesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.28. Reinicio de contadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Lista de figuras
vii
6.29. Aplicaciones a proteger
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.30. Interfaz para proteger imágenes . . . . . . . . . . . . . . . . . . . . . . . . 76
6.31. Selección de imágenes de la galerı́a . . . . . . . . . . . . . . . . . . . . . . 76
6.32. Imágenes cifradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.33. Desproteger imagen
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.34. Lista de archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.35. Archivo cifrado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.36. Contenido del archivo cifrado . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.37. Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.38. Link del tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Índice de códigos
5.1. Código principal para implementar tapjacking . . . . . . . . . . . . . . . . 50
6.1. Opciones para deshabilitar la protección . . . . . . . . . . . . . . . . . . . 60
6.2. Configuración de la alarma . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.3. Parada del servicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.4. Ejecución de la alarma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.5. Configuración del PIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.6. Uso de SecurePreferences . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.7. Recogida de taps del usuario . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.8. Representación gráfica de los taps . . . . . . . . . . . . . . . . . . . . . . . 67
6.9. Almacenamiento de los taps . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.10. Evaluación de los taps introducidos . . . . . . . . . . . . . . . . . . . . . . 70
6.11. Gestión de cada entrada del historial . . . . . . . . . . . . . . . . . . . . . 71
6.12. Obtención de valores de la base de datos . . . . . . . . . . . . . . . . . . . 72
6.13. Realización de la búsqueda en segundo plano . . . . . . . . . . . . . . . . 73
6.14. Búsqueda de aplicaciones en el sistema . . . . . . . . . . . . . . . . . . . . 74
6.15. Guardar aplicaciones protegidas . . . . . . . . . . . . . . . . . . . . . . . . 74
6.16. Selección de contenido de la galerı́a . . . . . . . . . . . . . . . . . . . . . . 78
6.17. Contenido guardado para cifrar . . . . . . . . . . . . . . . . . . . . . . . . 78
6.18. Cifrado del contenido I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
viii
Lista de figuras
ix
6.19. Cifrado del contenido II . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.20. Descifrado del contenido . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.21. Consulta de la aplicación en primer plano . . . . . . . . . . . . . . . . . . 81
6.22. Comprobación del número PIN . . . . . . . . . . . . . . . . . . . . . . . . 81
Índice de tablas
7.1. Costes recursos humanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.2. Costes directos por actividad . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.3. Costes directos de material . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.4. Costes indirectos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.5. Costes contingencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.6. Costes imprevistos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.7. Presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
8.1. Valoración sostenibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
x
1. Introducción
1.1.
Formulación del problema
Desde que a finales de 2008 salió al mercado la primera versión oficial del sistema operativo Android ha ido aumentando el número de usuarios de smartphones hasta que,
en la actualidad, el 82.8 % [1] de éstos utilizan este sistema. Este hecho ha propiciado
el aumento del interés en atacar dicha plataforma con el fin de sustraer información
privada a los usuarios.
En este contexto, se pretende realizar una comprensión del funcionamiento de la seguridad en Android y de las técnicas más utilizadas para lograr evadir la protección que
ofrece este sistema operativo.
Centrando el foco de atención en un tipo concreto de estas técnicas se lleva a cabo el
desarrollo de una aplicación, alternativa a las ya existentes en el mercado, que proporciona una protección adicional en el momento de introducir un patrón de desbloqueo
a las aplicaciones instaladas. La finalidad es dotar al usuario de los medios necesarios
para acceder a sus datos privados en situaciones que puedan tener un impacto negativo
en su privacidad. De este modo, se solucionará el problema actual de las aplicaciones
que ofrecen la funcionalidad de bloquear en base a un patrón o PIN: la efectividad se ve
anulada cuando un tercero descubre la combinación correcta.
La situación a la cual se pretende dar solución con el diseño de esta aplicación es el
denominado Shoulder Surfing. Éste se basa en técnicas de observación directa de un
dispositivo con la finalidad de sustraer información sensible del usuario. Esto sucede
frecuentemente debido a la cantidad de situaciones en las cuales los usuarios utilizan
sus dispositivos móviles en público. Se puede ejemplificar con el siguiente caso: un compañero de clase observa el patrón de desbloqueo de la galerı́a de fotografı́as de otro y en
un posible descuido de éste último podrı́a ganar acceso a dicho contenido.
1
1 Introducción
Aunque se diera esta situación, o similares, el hecho de tener un segundo nivel de protección ignoto para el atacante dificultarı́a el acceso de éste a los recursos protegidos.
Con este fin se desarrolla la aplicación que se expone en este proyecto.
1.2.
1.2.1.
Contextualización
Definición del contexto
Este proyecto se enmarca en el ámbito de la seguridad en sistemas Android. En concreto, la aplicación creada atañe al concepto de ataque de ingenierı́a social. Éste se define
como un conjunto de técnicas de manipulación que se realizan sobre los usuarios con la
finalidad de conseguir información confidencial.
Existe un amplio abanico de técnicas que se engloban dentro de este tipo de ataque, las
cuales suelen implicar el uso de correo electrónico, teléfono u otro tipo de comunicación
que pretende provocar situaciones de urgencia, miedo u otras, con el fin de engañar al
usuario para que revele información sin ser consciente de estar siendo vı́ctima de un
fraude. No obstante, algunas de estas técnicas no requieren de un interacción directa
entre el atacante y su vı́ctima, como es el caso de Shoulder Surfing.
Shoulder Surfing es una de las prácticas más utilizadas para obtener información sensible
de los usuarios de Android. Esto se debe a la facilidad y a la diversidad de situaciones
en las cuales se puede llevar a cabo. La ejecución de esta técnica consiste en observar
disimuladamente las acciones que realiza otro usuario en su dispositivo. De este modo
es posible obtener claves de acceso al sistema, contraseñas u otros datos. En este tipo
de ataque el usuario es el factor vulnerable por lo que no se puede conseguir una total
erradicación del problema. Es aquı́ donde surge la idea de la aplicación desarrollada en
este proyecto.
1.2.2.
Actores implicados
Acto seguido, se describe el rol de cada una de las partes involucradas en el desarrollo del
proyecto y los potenciales destinatarios que se beneficiarı́an del resultado de este trabajo.
2
1 Introducción
Desarrollador: es el principal actor del proyecto. Es el responsable de recopilar, estructurar y redactar la información además de desarrollar la aplicación.
Director: Manel Medina Llinàs, Catedrático de Arquitectura de Computadores en la
Universitat Politècnica de Catalunya, es el encargado de guiar y asistir este proyecto.
Usuarios beneficiados: esta aplicación va dirigida a los usuarios que requieren mejorar la protección de la privacidad de sus dispositivos mediante un segundo nivel de
autenticación que pase desapercibido ante posibles observadores. Estos usuarios podrán
beneficiarse tanto en un entorno empresarial como en el personal con la finalidad de
restringir el acceso a documentos y aplicaciones confidenciales.
1.3.
Estado del arte
Android es un sistema operativo basado en el kernel de Linux diseñado originalmente
para dispositivos móviles con pantalla táctil. El uso de este sistema ha experimentado
un gran crecimiento y aceptación entre los usuarios de smartphones hasta el punto de
que a finales de 2015 ocho de cada diez dispositivos usaban Android.
La rápida expansión de Android se debe principalmente a la gran cantidad de aplicaciones que salen al mercado ofreciendo útiles funcionalidades a los usuarios. Este hecho
es consecuencia de la fácil adaptación que tienen los desarrolladores de software a la
arquitectura de este sistema.
Dicha arquitectura se compone de distintos módulos [2, 3] que se interconectan para
compartir información y hacer uso de las funcionalidades ofrecidas por el resto de ellos.
Esta modularidad permite a programadores y usuarios abstraerse de la compleja implementación interna y poder realizar sus tareas de una forma más cómoda.
Tanto para un usuario estándar como para un desarrollador, la piedra angular de este
sistema, la cual proporciona atracción y utilidad del mismo, son las aplicaciones.
Una aplicación está formada por varios componentes [4, 5] que proporcionan un amplio
abanico de funcionalidades para que puedan ser implementadas por el programador.
Éste es el encargado de interactuar con las interfaces que proporciona Android a fin de
facilitar el desarrollo de la aplicación de una forma correcta y segura.
3
1 Introducción
La necesidad de seguridad es inherente a cualquier sistema operativo, de tal modo que no
se contempla un escenario en el cual se pueda prescindir de una fuerte implementación
de ésta. Es por ello que Android establece un modelo de seguridad, basado en el modelo
de Linux, con la intención de blindar el sistema y evitar que sea comprometido. Dicho
modelo especifica cada una de las incorporaciones nativas [6–10] que han sido adoptadas
para proteger al usuario.
No obstante, se ha demostrado que estas medidas de seguridad tienen un alcance de
protección limitado y pueden ser evadidas [11–14] por atacantes. Esto propulsa la aparición de extensiones de seguridad [15–19] capaces de integrarse al sistema operativo con
la finalidad de suplir sus carencias.
4
2. Alcance del proyecto
2.1.
Definición del alcance
El presente proyecto se orienta a la creación de una aplicación móvil que, tal y como se
ha expuesto en apartados anteriores, pretende mejorar la seguridad de dispositivos con
sistema Android en situaciones en las que se pueda dar Shoulder Surfing. No obstante,
el diseño de esta aplicación no se puede concebir sin tener consolidados una serie de
conocimientos sobre este sistema.
Es por ello que, con la finalidad de conseguir una base teórica sólida, se ha otorgado un
peso considerable a la parte bibliográfica de este ámbito.
En primer lugar, se realiza un overview acerca del funcionamiento del sistema operativo
Android para poder entender algunos aspectos fundamentales en cuanto a la composición interna del mismo.
Posteriormente, se profundiza en la seguridad de Android debido a que es el aspecto
más importante y más estrechamente relacionado con la aplicación desarrollada en este
trabajo.
Por último, se hace una revisión sobre los métodos más comunes utilizados por los cibercriminales con la finalidad de sustraer información .
En cuanto a la parte práctica de este proyecto, lo que se pretende es crear una aplicación
que aporte un segundo nivel de protección, invisible para posibles observadores, que
proteja a las aplicaciones, evitando ası́ el Shoulder Surfing.
5
2 Alcance del proyecto
2.2.
Riesgos y obstáculos
Como en todo proyecto existen potenciales factores que pueden interferir en las expectativas fijadas desde un inicio. En este caso, los condicionantes principales hacen referencia
al tiempo y a los conocimientos sobre la materia.
La entrega de este trabajo está establecida en una fecha concreta y por tanto el perı́odo
de tiempo para su desarrollo debe respetar dicha fecha. Esto supone que cualquier contratiempo que se produjese podrı́a afectar al avance continuado del proyecto y conducir
al incumplimiento de los plazos. Debido a que no se concibe tal escenario, la planificación temporal se realizará de modo que tenga cabida la gestión de posibles adversidades
sin que interfieran en el flujo de este trabajo. Algunas de éstas que se consideran hacen
referencia a las funcionalidades que ya no son soportadas por Android, lo cual provoca
que se tenga que optar por alternativas que no aportan las mismas prestaciones.
Otro importante aspecto a considerar es el grado de conocimiento previo del alumno en
la materia a tratar. Éste influirá en la rapidez con la cual avanzará la implementación
del proyecto. A causa de la gran extensión que ha experimentado Android a lo largo
de los últimos años, un gran número de recursos están disponibles para que el alumno
pueda formarse y alcanzar los conocimientos necesarios para la correcta finalización de
las tareas programadas. Por tanto, a pesar de ser un factor importante no será del todo
condicionante.
2.3.
Metodologı́a y rigor
En esta sección se expondrá el método de trabajo elegido para fijar el rumbo del proyecto, el conjunto de herramientas seleccionadas para realizar un seguimiento del mismo y
la metodologı́a empleada para validar el cumplimiento de los objetivos fijados.
2.3.1.
Métodos de trabajo
Con la finalidad de establecer una disciplina para el correcto desarrollo del proyecto,
SCRUM ha sido la metodologı́a de trabajo elegida. Se trata de un modelo ágil de desarrollo que tiene definidas las conductas que se deben adoptar para finalizar el trabajo
en el plazo fijado y asegurar que las expectativas del cliente se han cumplido.
6
2 Alcance del proyecto
SCRUM tiene como caracterı́stica principal la constante interacción entre cliente y desarrollador (director y alumno) para seguir de cerca cada avance. Este hecho aporta flexibilidad ante cambios, ya que éstos, al formar parte del proceso de desarrollo, no se
entienden como un problema sino como algo necesario para que el producto sea mejor.
Además, permite identificar y reducir tareas innecesarias; agilizando ası́ el progreso.
Por otro lado, SCRUM sigue una estrategia de desarrollo incremental, la cual permite
que la planificación sea adaptable al trascurso del proyecto. Esto proporciona una mejor
predicción de los tiempos necesarios para realizar cada tarea.
Estas caracterı́sticas más significativas de SCRUM hacen que se ajuste a las necesidades
requeridas en este trabajo y en consecuencia se pondrán en práctica.
2.3.2.
Herramientas de seguimiento
A lo largo del desarrollo del proyecto se utilizarán distintas herramientas para asegurar
un correcto procedimiento y garantizar que la integridad del trabajo está protegida ante
circunstancias disruptivas.
La principal herramienta de trabajo será Android Studio, la cual proporciona todo un
entorno adaptado al desarrollo de aplicaciones para Android. Además, permite la conexión con un gestor de repositorios en red como Git, GitHub, Mercurial, etc., para tener
un control de versiones sobre el código implementado.
Por otro lado, una herramienta clave para evitar que los avances producidos dependan
del estado del dispositivo en el cual se lleva a cabo toda actividad es Mega. Este programa permite tener una carpeta en el escritorio del ordenador con sincronización constante
con la nube. De este modo, cualquier cambio realizado en un fichero queda registrado
tanto en la máquina fı́sica como en un medio de almacenamiento en lı́nea, el cual cuenta
con una capacidad de 50GB.
Además, Mega permite exportar un enlace que especifica la ruta de acceso a la carpeta
respaldada. Esta caracterı́stica será aprovechada para permitirle al director del proyecto
poder consultar los avances realizados de una forma cómoda y remota.
7
2 Alcance del proyecto
2.3.3.
Métodos de validación
Debido a las caracterı́sticas definidas anteriormente sobre el modelo de trabajo a seguir, SCRUM, los métodos de evaluación se ajustarán a las pautas que establece dicho
modelo. Es decir, el trabajo será evaluado con cierta periodicidad, a convenir con las
preferencias del director, para asegurar un desarrollo continuado y correcto del proyecto,
evitando ası́ desviaciones e incorrectas decisiones del alumno sobre las tareas a realizar.
La comunicación entre el director y el alumno se realizará semanalmente vı́a correo
electrónico. En ella, el alumno detallará los avances realizados a lo largo de la semana y
esperará el feedback del director para modificar el estado actual del trabajo, en caso de
haber tareas desarrolladas de forma errónea, y consolidar el rumbo a seguir; evitando
ası́ desviaciones. Con este fin se establece un perı́odo máximo de dos semanas en el cual
puede permanecer el proyecto sin ser evaluado.
8
3. Pliegue de condiciones
3.1.
Descripción y motivación
El conjunto de funcionalidades que proporciona Android, en combinación con la evolución tecnológica de los dispositivos móviles, ha propiciado que los usuarios encuentren
en este sistema un lugar en el cual gestionar gran parte de las acciones cotidianas que
llevan a cabo.
Entre éstas se encuentra una que es prácticamente inherente al usuario: la gestión de
información privada y confidencial. A pesar de no haber estadı́sticas que confirmen este
hecho se podrı́a estimar que alrededor de la totalidad de dispositivos con Android almacenan datos sensibles. Éstos pueden ser documentos, contenido multimedia, registros de
mensajerı́a instantánea, etc., o bien información que permita identificar y ubicar a un
usuario; historial de navegación, posicionamiento GPS, registro de llamadas, etc.
Ante este hecho, el mundo del cibercrimen se ha volcado en la exploración intensa de
este sistema para encontrar vectores de ataque que permitan obtener datos privados
de los usuarios; principalmente con ánimo de lucro. El objetivo sobre el cual recae el
foco de atención de un ataque es una vulnerabilidad persistente en todos los sistemas
informáticos: el usuario.
El usuario de hoy dı́a hace un uso constante de los dispositivos móviles ignorando los
peligros silenciosos que le rodean. Se expone a gran cantidad de situaciones adversas y
realiza acciones sin ser del todo consciente del impacto que pueden tener en su confidencialidad.
En vista de este escenario, este proyecto pretende estudiar los mecanismos actuales de
seguridad que son inherentes en Android y las principales extensiones que resuelven situaciones no contempladas por los creadores de este sistema.
9
3 Pliegue de condiciones
La parte teórica de este proyecto se combinará con una parte práctica que consistirá
en una aplicación destinada a proporcionar seguridad a los usuarios de Android. Dicha
aplicación se trata de un software que permitirá aplicar un control de acceso sobre otras
aplicaciones con un factor de protección adicional respecto a otras aplicaciones similares
en el mercado.
El funcionamiento consistirá en sobreponer una aplicación, la cual pide un PIN de desbloqueo, encima de la aplicación a proteger. Cuando el usuario introduzca correctamente
el PIN solicitado, tendrá un acceso aparente a la aplicación protegida. Es decir, creerá
que está interactuando con dicha aplicación pero en realidad lo estará haciendo con una
aplicación transparente que está a la escucha de los taps que hace el usuario en la pantalla. Dichos taps han sido establecidos inicialmente por el usuario y actúan como segundo
factor de autenticación.
A modo de ejemplo clarificador se expone la siguiente situación:
Un usuario A decide proteger la aplicación Whatsapp para que salga una ventana
que pida introducir PIN cada vez que se abra.
El usuario A requiere de hacer uso de Whatsapp en un lugar donde hay personas
alrededor (metro, universidad, lugar de trabajo, etc.). Introduce el PIN de desbloqueo.
Un usuario B está observando el momento en el que se introduce el PIN.
El usuario A, una vez ha desbloqueado aparentemente Whatsapp, realizará un
conjunto de taps en las posiciones de la pantalla que sólo él sabe teniendo como
imagen estática de fondo la interfaz gráfica de Whatsapp.
El usuario B (considerando la situación en la que dispone de un tiempo limitado
para consultar el WhatsApp del usuario A y dejar el dispositivo en su sitio original) ha sido capaz de contemplar el PIN pero al acceder y no introducir los taps
invisibles se le cierra la aplicación y le muestra de nuevo la pantalla de bloqueo.
El objetivo de esta aplicación es paliar el efecto de una conocida técnica de ingenierı́a
social llamada Shoulder Surfing, la cual, tal y como se ha comentado anteriormente,
consiste en técnicas de observación directa de un dispositivo con la finalidad de sustraer
información sensible del usuario.
10
3 Pliegue de condiciones
Este hecho se puede producir con facilidad en multitud de escenarios debido a que el
usuario se ve obligado a focalizar su atención en la pantalla en el momento de introducir
el PIN. Su visión debe centrarse en las teclas que tiene que pulsar y en consecuencia no
puede prestar atención a posibles observadores que están a su alrededor.
La aplicación que se expone en este proyecto permite que un usuario introduzca los taps
invisibles sin necesidad de mirar el dispositivo móvil. Por tanto, puede girar el teléfono
hacia abajo o levantar la cabeza y observar si hay alguien pendiente cerca suyo. La
precisión no es un elemento que juegue en contra del usuario, ya que éste puede graduar
el margen de error aceptable para considerar que el tap está dentro de la zona correcta.
3.2.
Entorno
Este proyecto pertenece a la modalidad B, en la cual el alumno realiza un perı́odo de
prácticas en una empresa relacionada con la temática de su proyecto, S21sec1 .
S21sec es una multinacional especializada en servicios y tecnologı́a de ciberseguridad
cuya finalidad es garantizar el desarrollo efectivo de los negocios. Su objetivo es la
protección de los activos digitales de mayor valor y crı́ticos en las organizaciones: la
información, las operaciones y la imagen de la compañı́a.
Cuenta con más de 16 años de experiencia con proyectos a nivel mundial y con una amplia
gama de servicios y productos destinados a garantizar la seguridad de los sistemas de
información de empresas e instituciones.
3.3.
Estado actual
Este trabajo no forma parte de ningún otro proyecto, parte desde cero y cuenta con la
personalización de todas y cada una de sus funcionalidades.
Es cierto que en el mercado existen numerosas aplicaciones de bloqueo que se diferencian
en el nivel de detalle a la hora de proteger. Es decir, unas permiten bloquear algunos
parámetros de configuración como la ubicación GPS, el uso de datos, etc., y otras se
limitan a proteger sólo aplicaciones.
1
http:www.s21sec.com
11
3 Pliegue de condiciones
La idea de la aplicación surge debido al factor común que comparte un gran número de
aplicaciones que personalmente he testeado: la seguridad radica en el momento en el cual
el usuario inserta el PIN. Este hecho hace que por más eficiencia algorı́tmica que haya
sido programada finalmente dependerá en última instancia de la discreción del usuario.
Por este motivo, se decide mejorar este tipo de aplicaciones, para que el usuario pueda
prevenirse de aquellas personas que están ojo avizor cuando se expone públicamente.
3.4.
Diseño arquitectónico e Implementación
La arquitectura de la parte práctica del proyecto constará de un conjunto de clases,
programadas en Java y XML, que serán las que conformen la aplicación que funcionará
sobre el sistema operativo Android.
La principal herramienta software que servirá para llevar a cabo todas las tareas de programación es Android Studio. Ésta consiste en un entorno adaptado para proporcionar
facilidades a los programadores de aplicaciones Android.
Por otro lado, el hardware sobre el cual se realizará la implementación del proyecto
consiste en un portátil y un dispositivo móvil.
3.5.
Gestión de riesgos
Los riesgos asociados a las herramientas y tecnologı́as empleadas en el desarrollo del
proyecto no suponen una gran amenaza para la evolución del mismo.
Al tratarse de una aplicación para Android no existen riesgos derivados del uso de licencias debido a que la programación para dicha plataforma es de libre acceso. Por otro
lado, el uso de estándares por parte de Android erradica cualquier situación de incompatibilidad con los protocolos existentes.
No obstante, al tratarse de un sistema muy fraccionado, es decir, existen múltiples versiones de éste, hace que ciertas funcionalidades deban implementarse de forma diferente
para garantizar la compatibilidad entre versiones. Esto provoca que el programador
realice implementaciones extras, las cuales no todas pueden llevarse a cabo a causa de
medidas de seguridad adoptadas por Google.
12
3 Pliegue de condiciones
El punto fuerte de Android que mitiga en gran parte estas complicaciones es la extensa
documentación que se proporciona desde fuentes oficiales ası́ como la ayuda que se puede
encontrar en comunidades tecnológicas.
3.6.
Competencias técnicas de la especialidad
Este proyecto pertenece a la especialidad de Tecnologı́as de la Información y las competencias técnicas elegidas en el momento de la inscripción del TFG fueron las siguientes:
CTI2.2: Administrar y mantener aplicaciones, sistemas informáticos y redes de
computadores.
CTI2.3: Demostrar comprensión, aplicar y gestionar la garantı́a y la seguridad de
los sistemas informáticos.
CTI3.1: Concebir sistemas, aplicaciones y servicios basados en tecnologı́as de red,
teniendo en cuenta Internet, web, multimedia, servicios interactivos y computación
ubicua.
CTI4: Utilizar metodologı́as centradas en el usuario i la organización para el desarrollo, la evaluación y la gestión de aplicaciones y sistemas basados en tecnologı́as
de la información que aseguren la accesibilidad, ergonomı́a y la usabilidad de los
sistemas.
La descripción del proyecto dada en secciones anteriores pone de manifiesto que se abordan los aspectos relacionados con las competencias CTI2.2, CTI2.3 y CTI4.
Por otro lado, la competencia CTI3.1 ha quedado finalmente excluida del alcance del
trabajo. Esto se debe a que en el momento de la elección de las competencias no fue
posible predecir los acontecimientos que sucederı́an a lo largo del proyecto que harı́an
que esta competencia no tuviera cabida.
El principal motivo para su eliminación ha sido proporcionar mayor confianza y seguridad al usuario. En un principio se iban a implementar funcionalidades que requerı́an
el permiso de Internet dentro de la aplicación, como por ejemplo el restablecer el PIN
en caso de olvidarlo. No obstante, el hecho de requerir el permiso de acceso y escritura
en la tarjeta SD, entre otros que también pueden considerarse sensibles, hace que en
combinación con el de Internet supongan un escenario que muy posiblemente no serı́a
aceptado por un usuario. Por tanto, para facilitar la aceptación y distribución de esta
aplicación se ha optado por prescindir de conexión con el exterior.
13
4. Planificación temporal
4.1.
Planificación estimada del proyecto
La realización de este proyecto tiene una duración estimada de cinco meses, con fecha
de inicio el dı́a 11 de enero de 2016 y de finalización el 10 de junio de 2016. A lo largo de
estos cinco meses, las horas de dedicación diarias fluctuarán en función del calendario
laboral y lectivo. No obstante, el promedio de horas dedicadas por dı́a se estima en 4,
lo cual hace un total de 620 horas.
4.2.
Descripción de las tareas
A continuación, se detallarán cronológicamente las tareas realizadas en este proyecto:
1. Primeros pasos: la primera tarea a realizar es la búsqueda de información, la
cual se lleva a cabo mediante la lectura y comprensión de diversos artı́culos, tesis,
capı́tulos de libros, etc. Una vez asimilado el contenido se seleccionan los conceptos
relevantes con los cuales se quiere trabajar y se estructuran para la posterior redacción. Todo este proceso requiere una dedicación aproximada de 3 semanas y media.
2. Gestión del proyecto: las tareas que se desarrollan en la asignatura de Gestión
de Proyectos están acotadas temporalmente por unos plazos preestablecidos. Mediante dichas tareas se define el alcance y contexto del proyecto, se realiza una
estimación temporal de su duración y se estudia el impacto económico y su sostenibilidad. La duración total de estas tareas es de 6 semanas.
3. Recopilación y redacción: se lleva a cabo una selección e integración de la información más pertinente para una posterior redacción personalizada del contenido.
Debido a la cantidad de fuentes que se han consultado y contrastado se necesitan
más de 7 semanas para poder concluir esta tarea.
14
4 Planificación temporal
4. Desarrollo de la aplicación: para ello es necesario un proceso de aprendizaje
autónomo sobre la programación en Android. Paralelamente se trabaja sobre el
diseño que tendrá la aplicación y se empiezan a implementar algunas funcionalidades. Este proceso de implementación junto con su posterior redacción es el más
extenso y se realiza a lo largo de más de 11 semanas.
5. Etapa final: para concluir el trabajo es necesaria una última revisión del contenido
del mismo. Además, se realiza la preparación de la defensa oral que se lleva a cabo
en una fecha posterior al 17 de junio. Ambas tareas ocupan 2 semanas y media.
4.3.
Diagrama de Gantt
En esta sección se muestra una tabla que especifica cada tarea junto con su tiempo requerido. Posteriormente, dicha tabla se presenta gráficamente en el diagrama de Gantt.
Figura 4.1: Datos del diagrama de Gantt
15
4 Planificación temporal
Figura 4.2: Diagrama de Gantt
16
4 Planificación temporal
4.4.
Recursos
A continuación, se enumeran los recursos utilizados a lo largo del proyecto:
Hardware:
− Ordenador portátil Fujitsu LifeBook S Series con Ubuntu 12.04.
− Samsung Galaxy S3 con Android 4.4.
Software:
− Editor de texto Libre Office y Texmaker.
− Entorno de programación Android Studio.
4.5.
Valoración de alternativas y plan de acción
La planificación temporal mostrada anteriormente ha sido diseñada teniendo en cuenta
la carga lectiva y laboral que acompaña en paralelo al trabajo final de grado. Por este motivo se han solapado algunas tareas y se ha alargado la duración de alguna de ellas.
No obstante, aún y habiendo adoptado estas medidas preventivas, es necesario identificar los principales obstáculos que podrı́an causar una desviación en la ruta fijada por
el diagrama de Gantt. Éstos son mi grado de desconocimiento en ciertos ámbitos de los
sistemas Android y la correcta compaginación de las diferentes actividades.
En consecuencia, se ha fijado como fecha lı́mite el 10 de Junio, siete dı́as antes de la
entrega final. Este margen de tiempo, combinado con los cinco dı́as de vacaciones de los
que dispongo, será suficiente para solventar los imprevistos más susceptibles de ocurrir;
ya que la jornada puede aumentarse a 15 horas diarias o las necesarias.
Estos imprevistos están vinculados con la parte práctica de la aplicación. Si a lo largo del
desarrollo del proyecto se considera, tanto por mi parte como por parte del director, que
existe cierto peligro de no cumplir con el plazo de finalización del mismo se descartará
la implementación de ciertas funcionalidades que requieren programarse de distintas
formas para garantizar la compatibilidad con la gran mayorı́a de versiones de Android.
Es decir, se acortará el target para que la aplicación funcione a la perfección en un
número determinado de versiones.
17
5. Fundamentos teóricos
5.1.
Sistemas Android
Android fue fundado por Android Inc. en 2003 y adquirido por Google en 2005 [20]. Tres
años después, a finales de 2008, verı́a la luz la primera versión oficial de este sistema, el
cual tuvo una gran acogida por parte de usuarios y desarrolladores.
Su rápida expansión provocó que sus competidores más cercanos, iOS y Windows Phone,
se repartieran una menor parte del mercado y que sistemas operativos como BlackBerry
y Symbian prácticamente dejasen de ser utilizados. Esta superioridad también es notable
en la tienda de aplicaciones Google Play Store, la cual cuenta con más de 1,6 millones
de aplicaciones, superando a Apple Apps Store, su principal competidor.
Con una cuota de mercado estimada en el 82.8 %, Android se ha convertido en el sistema
operativo más popular para smartphones y tablets con más de 350 millones de dispositivos activos y con expectativas de alcanzar los 1.000 millones en 2017.
Google ha convertido a Android en uno de los competidores más importantes en el sector móvil. Gran parte de este éxito se debe al carácter open source de éste, el cual, a
diferencia de otras plataformas, permite a fabricantes y desarrolladores integrar tanto
su hardware como software con este sistema.
Son varias las condiciones que posee Android que facilita el trabajo de los desarrolladores.
De entre las más favorables destaca el uso de lenguajes de programación ampliamente
extendidos como son Java y XML. Además, la guı́a para los desarrolladores y la documentación sobre las funcionalidades disponibles es extensa, detallada y dispone de
diversos ejemplos de implementación.
No obstante, a la par que proporciona ventajas también genera inconvenientes que afectan a desarrolladores y fabricantes de dispositivos. El más significativo hace referencia
18
5 Fundamentos teóricos
a la fragmentación de la plataforma. Es decir, la cantidad de versiones existentes de
Android, las cuales tienen integradas funcionalidades diferentes, hace que la compatibilidad entre dichas versiones se vea reducida, lo cual puede causar problemas de diseño
y desarrollo a la hora de crear un aplicación.
Sin embargo, hoy en dı́a en este sistema son más los puntos fuertes que débiles y en
consecuencia los usuarios, desarrolladores y fabricantes se decantan preferiblemente por
Android.
5.1.1.
Arquitectura del sistema
La complejidad del software que constituye el sistema operativo Android se organiza
de forma modular, donde cada módulo consiste en una agrupación de funcionalidades y
servicios afines. Esta organización permite a desarrolladores y a usuarios trabajar en un
nivel de abstracción que no requiere profundos conocimientos del funcionamiento interno
y proporciona comodidad para interactuar con el sistema.
La interconexión de los distintos módulos se produce en forma de servicios que ofrece un
módulo a otros de niveles superiores y al uso que hace éste de los de módulos inferiores,
tal y como se ilustra en la siguiente figura.
Figura 5.1: Arquitectura del sistema operativo Android
19
5 Fundamentos teóricos
A continuación, se analizará cada uno de los cinco módulos ası́ como la relación que
establecen con sus adyacentes.
5.1.1.1.
Kernel
El kernel de Linux es el módulo base sobre el cual se asenta todo el software de Android.
La versión usada del kernel en los inicios de Android pertenece a la serie 2.6 y ésta
evolucionó hasta la actual 3.18. Ambas cuentan con implementaciones adicionales para
satisfacer necesidades especı́ficas de la plataforma.
Tal y como ocurre en todos los sistemas Unix, el kernel proporciona drivers para que
cualquier componente hardware pueda ser usado. Además, provee acceso al sistema de
ficheros, funcionalidades de red, gestión de energı́a, memoria y procesos.
A pesar de que Android esté basado en Linux, no se considera que sea una distribución
de este último. De hecho, existen diferentes funcionalidades [2] que se han añadido a
Android y otras que eran inherentes al kernel de Linux se han visto adaptadas. Las
principales diferencias que han adoptado en Android son:
Ashmem: hace referencia al sistema de memoria compartida (Anonymous SHared MEMory) que permite a múltiples procesos compartir recursos. El concepto
Anonymous se debe a que los bloques en los que se divide la memoria no son
asignados a un proceso de forma exclusiva, permitiendo ası́, por ejemplo, poder
compartir un mismo icono entre aplicaciones.
Binder: debido a que Google consideraba que los mecanismos estándar para la
comunicación entre procesos (signals, pipes, sockets, memoria compartida, etc.) no
eran lo suficientemente flexibles para Android, implementó su propio método llamado Binder, el cual se analizará en próximas secciones.
Gestión de energı́a: Google diseñó un nuevo sistema de gestión de energı́a para
poder dilatar la duración de la baterı́a de los dispositivos móviles. Para ello, se
crearon drivers especı́ficos que controlan el consumo de componentes hardware,
como es el caso de la iluminación de pantalla.
20
5 Fundamentos teóricos
5.1.1.2.
Librerı́as
Este módulo centraliza las librerı́as que proporcionan servicios al módulo Framework
de la aplicación. Estas librerı́as están escritas en C/C++ e implementan llamadas a
sistema que permiten a las aplicaciones hacer uso de las funcionalidades intrı́nsecas de
Android. Por ejemplo, la librerı́a Surface Manager ofrece la capacidad de componer los
diferentes elementos de navegación de pantalla ası́ como también gestionar las ventanas
de las aplicaciones.
Entre las librerı́as más representativas de Android se encuentran:
Libc: incluye todas las cabeceras y funciones del lenguaje C.
SQLite: permite la creación y gestión de bases de datos.
WebKit: proporciona soporte para aplicaciones de tipo navegador.
OpenGL y SGL: sustentan la capacidad gráfica 2D y 3D de Android.
5.1.1.3.
Runtime
El tiempo de ejecución de Android, más conocido como Runtime, se divide en dos diferenciadas secciones: las librerı́as del núcleo (Core Libraries) y la máquina virtual Dalvik
(Dalvik VM).
En cuanto a las librerı́as del núcleo, proporcionan una interacción directa con una instancia de la Dalvik VM. Están escritas, normalmente, en Java y son las encargadas de
proporcionar soporte en la manipulación de ficheros, gestión de estructuras de datos, etc.
Por otro lado, Dalvik es el nombre de la máquina virtual que utiliza Android para llevar
a cabo la ejecución de sus aplicaciones. En lugar de hacer uso de la Java Virtual Machine
(JVM), Google decidió crear su propia máquina virtual optimizada para entornos significativamente más reducidos en cuanto a recursos fı́sicos, es decir, dispositivos móviles.
Esta optimización radica en la forma que tiene Dalvik de generar código ensamblador.
En lugar de usar la pila, como hace hace la JVM, utiliza los registros como unidad
primaria de almacenamiento; los cuales proporcionan un mejor rendimiento debido a la
reducción de instrucciones necesarias [3].
21
5 Fundamentos teóricos
En la versión 4.4 de Android se introdujo una nueva máquina virtual, ART, para sustituir a la Dalvik. La principal diferencia entre ambas es el orden que establecen para
compilar una aplicación. Mientras que en la Dalvik se realiza la compilación cuando una
aplicación es lanzada por primera vez, en ART este proceso se realiza directamente en el
momento de la instalación de la aplicación y tiene como consecuencia una mayor rapidez
de ejecución.
Puesto que la finalidad de esta sección es tener una visión panorámica de la arquitectura
de Android, con un sondeo técnico, no se entrará en detalle en caracterı́sticas internas
de estas máquinas virtuales.
5.1.1.4.
Framework de la aplicación
El Framework de la aplicación consiste en el conjunto de herramientas de desarrollo accesible a los programadores de aplicaciones. Las funciones que proporciona son un nexo
entre el sistema y el desarrollador, a fin de que éste último pueda utilizar los recursos
de Android sin necesidad de integrar complejas funcionalidades por su cuenta.
Esta agrupación de tareas ya programadas que ofrece simples llamadas como medio de
interacción, escondiendo la complejidad de trasfondo, se conoce como Application Programming Interface (API).
Google, a lo largo de la evolución de Android, ha ido incorporando nuevas APIs a su
sistema. A fin de mantener un histórico y tener organizadas las APIs según su aparición
se agruparon por niveles, los cuales a principios de 2016 forman un total de 23.
El primer nivel de API apareció en 2008 con la versión 1.0 de Android. A medida que
ha pasado el tiempo han salido nuevas versiones de Android, identificadas con nombres
diferentes (Cupcake, Eclair, Froyo, etc.) a las cuales se les atribuye un nivel de API
distinto. A pesar de que cada nivel incluye algunas mejoras o funcionalidades nuevas, las
siguientes APIs troncales [4] de este sistema siguen manteniendo la misma estructura:
Activity Manager : proporciona un conjunto de métodos que permiten la gestión
del ciclo de vida de las aplicaciones, ası́ como conocer el estado de los recursos del
sistema. Además, permite consultar la memoria usada por un proceso, los servicios
del sistema, entre otros.
22
5 Fundamentos teóricos
Content Providers: gestionan la compartición de datos (contactos, agenda, mensajes, etc.) entre aplicaciones.
Notification Manager : se encarga de comunicar al usuario eventos que ocurren
en el sistema, como una llamada entrante, un mensaje recibido, baterı́a baja, etc.
Telephone Manager : además de ser un potente sistema operativo, con complejas funciones, Android incorpora clases vinculadas a la finalidad esencial de un
dispositivo móvil; la telefonı́a (llamadas, mensajes, etc.)
View Manager : proporciona un gran número de elementos para poder construir
las interfaces de usuario (GUI) de las aplicaciones.
Window Manager : sus funcionalidades permiten la gestión de las ventanas,
determinar cuáles son visibles y cómo se posicionan en la pantalla. Por otro lado,
realiza automáticamente las transiciones y las animaciones de apertura y cierre de
una aplicación, ası́ como también la rotación de éstas.
Tal y como se verá más adelante, el hecho de tener conocimiento de cómo y mediante
qué mecanismos se realizan las acciones del sistema, es decir, discernir entre las APIs
que potencialmente pueden aprovechar agujeros de seguridad y las que no, será vital
para poder realizar un ataque y/o una buena defensa.
5.1.1.5.
Aplicaciones
El módulo superior del software de Android está destinado a las aplicaciones, las cuales
proporcionan una interfaz gráfica a los usuarios para que interactúen. Todas tienen la
misma estructura y utilizan las APIs y librerı́as de módulos inferiores, permitiendo al
programador desconocer los detalles de implementaciones internas.
En función de su origen se distinguen dos tipos de agrupación: las aplicaciones nativas
del sistema y las de terceras personas (ajenas al sistema).
Las aplicaciones nativas se incluyen en la imagen del sistema y en caso de considerarse
vitales no pueden ser desinstaladas o cambiadas por los usuarios. En consecuencia, se
consideran seguras y por ello tienen mayores privilegios, a diferencia de las instaladas por
los usuarios, para realizar acciones como el acceso al hardware, a librerı́as del sistema, etc.
23
5 Fundamentos teóricos
Por otro lado, las aplicaciones ajenas al sistema se ejecutan en una Sandbox (Sección
5.2.1.1) individual para aislarlas de otras aplicaciones o de información sobre la cual el
acceso no deberı́a estar permitido. La peligrosidad de éstas, aunque hayan sido descargadas de la tienda de Google, es que pueden incorporar código malicioso que se salte
todo tipo de control y pueda comprometer el dispositivo, tal y como se verá en próximas
secciones.
5.1.2.
Arquitectura de una aplicación
Las aplicaciones son la pieza clave del sistema operativo Android y las que lo dotan
de todo su potencial. El desarrollo de éstas se realiza principalmente mediante dos lenguajes; Java para gestionar la parte funcional (aunque también podrı́an emplearse otros
lenguajes como C/C++) y XML para tratar la parte visual, es decir, los componentes
de la interfaz gráfica.
Toda aplicación consiste de un conjunto de componentes, que pueden ser usados por
los desarrolladores, y requiere de un entorno creado por el sistema que permita la ejecución segura de una aplicación. Ambos conceptos se ven ilustrados en la siguiente figura.
Figura 5.2: Arquitectura de una aplicación
Como puede observarse, Android crea un proceso donde ejecutará una instancia de la
máquina virtual Dalvik, la cual será el entorno real en el que correrá una aplicación.
24
5 Fundamentos teóricos
Ésta, a su vez creará hilos de ejecución (Threads) para gestionar cada uno de los principales componentes: Actividades, Servicios, Content Providers y Broadcast Receivers.
El análisis de los componentes que conforman la estructura de una aplicación se muestra
en las siguientes secciones.
5.1.2.1.
Android Manifest
A pesar de no considerarse un componente como tal, toda aplicación necesita tener
un documento XML en el directorio raı́z llamado AndroidManifest.xml. Este fichero
proporciona información precisa de los componentes que usará la aplicación. Se podrı́a
entender como una declaración de intenciones, es decir, el programador se ve forzado
a definir lo que necesita para que el usuario pueda tener una cierta garantı́a de que
esa aplicación es lo que dice ser. Por ejemplo, si se requiere del permiso para acceder a
Internet, éste será mostrado al usuario en el momento de la instalación para que dé su
conformidad. Si la aplicación a parte de Internet necesita enviar un mensaje de texto no
podrá hacerlo a menos que haya sido declarado explı́citamente el permiso necesario.
5.1.2.2.
Actividades
Una Activity es el principal componente de las aplicaciones en Android. Su función es
llevar a cabo una actividad concreta y normalmente va acompañada de una interfaz
gráfica mediante la cual el usuario interactúa con la aplicación.
En el AndroidManifest.xml se pueden declarar tantas actividades como el programador
crea necesarias. Cada una de ellas puede interactuar con las otras o colaborar independientemente en el desarrollo de una tarea. Por ejemplo, una aplicación para gestionar el
correo puede hacer uso de una primera Activity para listar los contactos, una segunda
para escribir un nuevo correo, otra para añadir un adjunto, etc.
Un factor que tienen en común las actividades que se crean en Android es el ciclo de
vida, donde se define un conjunto de estados por los cuales puede pasar una Activity.
Existe un total de siete estados relacionados entre ellos que permiten especificar el comportamiento de la aplicación en todo momento, tal y como se puede observar en la
siguiente figura.
25
5 Fundamentos teóricos
Figura 5.3: Ciclo de vida de una Activity
Estos estados son descritos y agrupados por Google de la siguiente manera [5]:
Ciclo de vida entero: engloba desde el estado onCreate(), el cual sucede cuando
se crea la Activity, hasta el estado onDestroy(), que libera los recursos reservados
por el sistema.
Ciclo de vida visible: abarca desde el estado onStart() hasta onStop(). Durante
este tiempo el usuario puede ver la ventana de la aplicación e incluso interactuar
con ella. Si otra Activity es lanzada, la anterior pasa al estado onStop() y en caso
de que el sistema no la elimine por falta de recursos, volverá al estado onStart()
pasando previamente por onRestart().
26
5 Fundamentos teóricos
Ciclo de vida en primer plano: este ciclo es el que se da entre los estados
onResume() y onPause(). Entre ellos, la Activity afectada se encuentra en un
primer plano y es la que mantiene el foco de entrada. El estado onPause(), es
llamado, por ejemplo, cuando se produce un mensaje emergente que requiere el
foco o cuando la actividad del usuario cesa durante un tiempo y el dispositivo
entra en modo reposo.
El conocimiento de estos estados y las transiciones que se producen entre ellos es fundamental para saber cómo se comportará la aplicación en todo momento. Esto se experimentará más adelante.
5.1.2.3.
Servicios
Un servicio es un componente diseñado para realizar tareas en un segundo plano sin la
necesidad de proporcionar una interfaz gráfica al usuario. Los servicios son usados con
frecuencia para gestionar operaciones que requieren de un largo tiempo de ejecución,
como por ejemplo la descarga de un fichero, sin cortar la interacción del usuario con la
aplicación.
A diferencia de los servicios del sistema, los cuales siempre están ejecutándose, los servicios de las aplicaciones se inician y se paran bajo demanda de la aplicación o bien por
la intervención del usuario. Éstos se dividen en: enlazados y desenlazados.
Los servicios enlazados (Bounded services) se invocan mediante la llamada bindService()
y se caracterizan por ofrecer una interfaz cliente-servidor al resto de componentes que
quieran interactuar. Estos componentes son clave para mantener la ejecución del servicio, ya que la desconexión de todos y cada uno de ellos provocará la destrucción del
servicio.
Por otro lado, los servicios desenlazados (Unbounded services) se crean mediante la función startService() y se ejecutan indefinidamente hasta que se auto-destruyen o bien son
parados por los usuarios. Su ejecución es independiente de la del componente que los ha
iniciado debido a que la destrucción de este último no implicarı́a una parada del servicio.
En la siguiente figura se muestra gráficamente el ciclo de vida de un servicio enlazado
(derecha) y uno desenlazado (izquierda).
27
5 Fundamentos teóricos
Figura 5.4: Ciclo de vida de un servicio
5.1.2.4.
Content providers
Los proveedores de contenido, Content Providers, gestionan el acceso a la información
de una aplicación. En concreto, permiten almacenar, recuperar, actualizar y compartir
los datos de una aplicación mediante el uso de un conjunto de métodos.
Tal y como se muestra en el siguiente esquema, los datos pueden ser almacenados en un
fichero, en una base de datos SQLite o en cualquier otro formato. Para acceder a ellos,
las aplicaciones pueden instanciar un objeto Content Resolver para poder comunicarse
con el Content Provider y acceder ası́ a la información o a un subconjunto de ésta. Dicho
acceso puede realizarse tanto desde actividades como servicios.
28
5 Fundamentos teóricos
Figura 5.5: Funcionamiento de los Content Providers
5.1.2.5.
Broadcast recievers
Un aspecto caracterı́stico del diseño del sistema operativo Android es que cualquier aplicación puede lanzar un componente perteneciente a otra aplicación. Por ejemplo, si un
usuario quiere hacer uso de la cámara del dispositivo móvil dentro de una aplicación,
en lugar de que ésta incorpore una Activity con todo el código necesario para hacer
una fotografı́a, lo que se hace es invocar a una aplicación que ya realice de por si dicha
tarea y libere al programador de tener que implementarla. Este proceso es totalmente
transparente al usuario.
Debido a que el sistema ejecuta cada aplicación en un proceso diferente, no existe una
comunicación directa con las otras aplicaciones. Por ello, para hacer uso de la cámara,
la aplicación deberá comunicárselo al sistema y éste se encargará de escoger la aplicación disponible para dicha tarea. Concretamente, el sistema difundirá este evento y
la aplicación que esté a la espera de tal evento responderá ofreciendo sus funcionalidades.
Esta predisposición de las aplicaciones a reaccionar ante eventos se implementa mediante
el uso de Broadcast Receivers. Este componente principal de una aplicación Android
no precisa de interfaz gráfica y en caso de necesitar notificar un evento por pantalla,
por ejemplo un SMS recibido, puede hacer uso de la API Notification Manager, vista
anteriormente.
29
5 Fundamentos teóricos
5.2.
Seguridad en Android
En esta sección se analizarán los principales mecanismos que implementa Google para
securizar Android. Éstos conforman el llamado modelo de seguridad de Android, en el
cual se establece el conjunto de medidas necesarias para proteger las zonas más crı́ticas y
propensas a ser atacadas: sistema de ficheros, memoria, zonas restringidas al sistema, etc.
Por otro lado, una vez vista la seguridad nativa de Android, se mostrarán las insuficiencias que sufre dicho modelo y las extensiones propuestas que han aportado investigadores
a fin de paliar las brechas de seguridad existentes y hacer este sistema más robusto.
5.2.1.
Modelo de seguridad
Tal y como se acaba de comentar, el modelo de seguridad de Android son las medidas de
protección implementadas de serie en cada versión de este sistema. A continuación, se
detallarán los aspectos más relevantes de este modelo, como son la filosofı́a de seguridad,
el control de acceso a recursos y a memoria, las comunicaciones internas, entre otros.
5.2.1.1.
Sandboxing
Tal y como se ha mencionado anteriormente, Android crea un nuevo proceso que inicializa una instancia de la máquina virtual Dalvik con el fin de ejecutar una aplicación. Este
entorno creado para cada aplicación, conocido como Sandbox [6], tiene como finalidad
proporcionar aislamiento entre aplicaciones. Como resultado, una aplicación no puede
acceder a datos ni código de otras.
Este aislamiento se complementa con el sistema de seguridad que Android adoptó de
Linux; los identificadores únicos. Cada aplicación, en el momento de su instalación recibe
un identificador único (UID) para poder ser diferenciada de otras aplicaciones. De este
modo, se pueden aplicar restricciones de acceso con mayor facilidad.
El objetivo de este diseño es proporcionar un entorno estable, seguro y reducido para
que el impacto de la ejecución de una aplicación al resto del sistema sea el menor posible.
Es por esto que las Sandboxes son usadas con regularidad para escanear aplicaciones en
busca de malware y prevenir ası́ la infección a otras aplicaciones.
30
5 Fundamentos teóricos
5.2.1.2.
Gestión de permisos
Debido a que las aplicaciones se ejecutan en una Sandbox, y por tanto sólo pueden acceder
a sus propios ficheros y a recursos globales del sistema, Google tuvo que implementar
un mecanismo que permitiera a las aplicaciones, de forma segura y controlada, tener
una serie de privilegios a fin de poder proporcionar a los usuarios funcionalidades más
avanzadas. De esta necesidad surgieron los derechos de acceso, conocidos como permisos.
El pilar sobre el cual se sustenta la seguridad de una aplicación radica en los permisos,
los cuales restringen las operaciones que se pueden llevar a cabo, como por ejemplo, el
acceso a Internet, al uso de la cámara, etc. Por defecto, una aplicación no tiene ningún
permiso asociado que permita realizar acciones perjudiciales al usuario o a los datos del
sistema. Es por eso que, para dotar a una aplicación de funcionalidades más complejas,
los desarrolladores necesitan declarar los permisos mı́nimamente necesarios en el fichero
AndroidManifest.xml.
En el momento de la instalación, Android consulta este fichero y muestra por pantalla
todos y cada uno de los permisos que serán concedidos a la aplicación. En cuanto el
usuario da su aprobación, la instalación sigue su curso y se asignan los permisos de
manera irrevocable y sin la necesidad de una confirmación adicional en el momento de
la ejecución.
Existen cuatro categorı́as para clasificar los permisos:
Normal : en esta categorı́a se agrupan los permisos que proporcionan a las aplicaciones acceso a caracterı́sticas aisladas, las cuales tienen un riesgo mı́nimo para
otras aplicaciones, el sistema o el usuario. No requieren de una aprobación explı́cita, aunque el usuario siempre tiene la posibilidad de ver cuáles son.
Dangerous: estos permisos otorgan acceso a las aplicaciones a datos privados del
usuario o proporcionan un control sobre el dispositivo que puede impactar negativamente sobre el sistema. Requieren permiso explı́cito por parte del usuario.
Signature: este permiso sólo se concede si la aplicación solicitada está firmada
con el mismo certificado que la aplicación que declara el permiso.
SignatureOrSystem: la otorgación de este tipo de permiso sigue la misma norma
que el tipo Signature y además se atribuye a aplicaciones del sistema.
31
5 Fundamentos teóricos
El hecho de depositar gran parte de la seguridad de Android en el uso de los permisos
ha sido un tema discutido en la comunidad tecnológica [7] debido a que éstos, en última
instancia, requieren de la intervención humana.
Aunque es un hecho necesario, a fin de que los usuarios tengan potestad sobre su privacidad, la metodologı́a usada por Android es cuestionada. Otras alternativas han sido
propuestas para mejorar la seguridad, como por ejemplo especificar con mayor detalle las
acciones que podrı́an realizarse detrás de cada permiso, o bien requerir el consentimiento
del usuario en el momento de la ejecución en lugar de hacerlo únicamente durante la
instalación; permitiendo ası́ una mejor asociación e interpretación del motivo por el cual
se requiere cierto permiso.
5.2.1.3.
Acceso a memoria
Desde los inicios de Android, la memoria del sistema ha sido un importante punto de
interés a atacar. Esto es debido a que las técnicas usadas para corromper la memoria
permiten llevar a cabo una escalada de privilegios, lo cual se traduce en la posibilidad
de ejecutar comandos sin restricciones.
La corrupción de memoria ocurre cuando el contenido de la memoria de una aplicación
es modificado debido a errores de programación. Cuando la aplicación accede a este contenido deja de funcionar. Este hecho puede ser aprovechado por atacantes para inyectar
código en esa región de memoria y reconducir ese error ejecutando los comandos que
permitan al atacante crear un impacto en el sistema.
Para llevar a cabo esta corrupción existen múltiples técnicas que permiten el desbordamiento del buffer de la memoria (Buffer Overflow).
En cada versión de Android se han ido añadiendo diferentes mecanismos de protección
para mitigar los efectos que estas técnicas iban produciendo. Las incorporaciones más
destacadas que han tenido lugar desde las primeras versiones de Android son: ProPolice,
NX, ASLR [8].
ProPolice se incorporó a partir de la versión 1.5. Su funcionamiento se basa en el uso de
’canarios’ para evitar ataques de desbordamiento del buffer. Los ’canarios’ consisten en
un conjunto de valores situados en ciertas zonas de la memoria cuyo valor se comprueba
para detectar ası́ si ha habido un desbordamiento.
32
5 Fundamentos teóricos
NX (No eXecute) es un mecanismo incluido a partir de la versión 2.3 con el objetivo
de prevenir la ejecución de código en memoria (heap y pila). Consiste en un bit que
permite marcar ciertas áreas de la memoria para que en caso de ser accedidas se impida
su ejecución.
ASLR (Address Space Layout Randomization) fue creado en la versión 4.0 para paliar
los nuevos vectores de ataque de corrupción de memoria. Debido a que el éxito de esta corrupción radica en el conocimiento que tiene el atacante sobre la localización del
ejecutable en la memoria, el ASLR asigna posiciones de memoria de manera aleatoria;
impidiendo que el atacante conozca la ubicación exacta.
Estas medidas de seguridad, de forma aislada, son insuficientes para proteger el acceso
indebido a memoria. Esto se debe a que a raı́z de la aparición de NX se aplicaron
otras técnicas de ataque, como por ejemplo Return-Oriented Programming, que eluden
la protección de NX o heap spraying que evitan el efecto de ASLR. En consecuencia,
para garantizar una buena protección de la memoria es necesario usar una combinación
de ambas (NX y ASLR), ya que se complementan mutuamente.
5.2.1.4.
Protección de datos
El contenido privado de un usario es el bien más preciado y por tanto deben aplicarse
medidas de protección que eviten tener que depositar toda confianza únicamente en el
aislamiento que proporciona una Sandbox, ya que éste no es suficiente, y garanticen la
confidencialidad e integridad de los datos.
Android proporciona mecanismos para proteger la información de un dispositivo y de
las comunicaciones que se realicen con el exterior. Por un lado, proporciona un control
de acceso general que puede aplicarse por medio de un PIN numérico, patrones e incluso
en los dispositivos más actuales reconocimiento de huella dactilar. No obstante, cuando
un atacante tiene acceso fı́sico a un dispositivo, estos métodos no suponen un gran contratiempo [9] para acabar accediendo a los datos.
Por otro lado, Android permite a los desarrolladores implementar aplicaciones que permitan el cifrado de datos. Para ello, les ofrece diversos algoritmos criptográficos que pueden
aplicarse de una forma cómoda y sin requerir altos conocimientos de criptografı́a. Este
cifrado, aplicado con una configuración correcta, securiza los datos almacenados y las
comunicaciones que se realicen con un servidor externo.
33
5 Fundamentos teóricos
Sin embargo, en este último caso, Android facilita aún más esta tarea debido a que aconseja utilizar el protocolo HTTPS, sin tener que hacer configuraciones extras. Además,
en caso de querer establecer un túnel, Android recomienda usar la clase HttpsURLConnection o SSLSocket; desalentando al desarrollador a implementar su propio protocolo.
No obstante, si éste se viera forzado a hacerlo, al menos deberı́a asegurarse de usar un
algoritmo criptográfico como AES o RSA y descartar la posibilidad de crear uno propio.
La clase Cipher de Android proporciona llamadas a funciones que permiten aplicar los
algoritmos de cifrado de una forma limpia y cómoda, tal y como se verá más adelante.
5.2.1.5.
Signatura de código
Toda aplicación en Android está contenida en un archivo .apk, el cual incluye tanto los
ficheros de código como otros recursos (imágenes, audio, etc.). Este .apk debe contener
una firma digital en el momento de la instalación, de lo contrario Android denegará este
proceso impidiendo la ejecución de la aplicación en el dispositivo. Este rechazo a aplicaciones que no incluyen dicha firma también se aplica en la polı́tica que tiene Google
Play (tienda oficial de aplicaciones) a la hora de permitir la publicación de la aplicación.
Mediante la signatura de código (firma digital) se consigue identificar el autor de una
aplicación ası́ como también facilitar las actualizaciones que ésta requiera. Además, permite que dos o más aplicaciones de un mismo desarrollador puedan interactuar con
mayor facilidad.
Las aplicaciones pueden estar firmadas por una entidad externa o auto-firmadas. En este
último caso, Android permite la firma mediante el uso de certificados generados por los
propios desarrolladores, sin necesidad de participaciones externas. Esta firma se realiza
mediante un proceso criptográfico que hace uso de certificados digitales.
5.2.1.6.
Binder
Debido a que por razones de seguridad y estabilidad los procesos deben estar aislados
y tener su propio espacio de direcciones en la memoria es necesario un mecanismo que
permita la comunicación entre ellos (Inter-Process Communication). Tal y como se ha
mencionado anteriormente, Binder [10] es el mecanismo que usa Android para permitir
dicha comunicación.
34
5 Fundamentos teóricos
Binder surge como una alternativa a otros mecanismos de comunicación empleados en
sistemas basados en el kernel de Linux, como son signals, semáforos, pipes, etc., aportando funcionalidades adaptadas al sistema Android.
La manera en la que Binder gestiona la comunicación entre procesos se observa en la
siguiente figura.
Figura 5.6: Comunicación entre procesos mediante Binder
Tal y como se muestra, cuando el proceso A quiere comunicarse con el B necesita hacer
uso de un cliente Binder para que emplee el método transact(), el cual contendrá la
referencia del objeto destino, el identificador del comando a ejecutar (por ejemplo BINDER WRITE READ) y un buffer con datos a enviar. Toda esta información se transmite
al driver de Binder en el kernel de Linux. Éste añade información que permite identificar
al proceso A y la envı́a al B para que éste decida si permite que se realicen las acciones
del primero.
La seguridad de este mecanismo radica en el hecho de que es el kernel quien identifica
al proceso A e impide que éste pueda falsear maliciosamente su identidad; previniendo
ası́ una escalada de privilegios.
5.2.1.7.
SEAndroid
SEAndroid [12] es un mecanismo de control de acceso que deriva de SELinux. Éste, a
su vez, se creó como alternativa al modelo de seguridad que incorporaban los sistemas
Unix.
35
5 Fundamentos teóricos
En Unix, y por extensión en sistemas basados en el kernel de Linux, la polı́tica de seguridad se regı́a por el Discretionary Access Control (DAC). Éste es un mecanismo, basado
en permisos, mediante el cual el usuario puede establecer una polı́tica de seguridad para
permitir o denegar el acceso a un recurso del cual es propietario, por ejemplo controlar
quién puede escribir o leer un fichero que haya creado.
Una de las caracterı́sticas de DAC es que el usuario puede transferir la propiedad que
tiene sobre un recurso y determinar el acceso de otros usuarios. Esto puede dar lugar a
situaciones en las que los usuarios establezcan permisos inseguros a recursos. Para dar
solución a este problema, se creó una nueva extensión de seguridad: SELinux (SecurityEnhanced Linux).
SELinux incorpora un mecanismo de control de acceso diferente a DAC. En concreto,
su polı́tica de seguridad está basada en el Mandatory Access Control (MAC), en el cual
es el sistema, en lugar del usuario, el que establece los permisos necesarios de acceso
sobre un recurso. De tal forma que los usuarios no pueden tener un impacto, accidental
o malintencionado, sobre los recursos del sistema. Este factor de seguridad previene que
el usuario realice una escalada de privilegios.
Debido a que SELinux se integró en el kernel de Linux y Android está basado en dicho
kernel, serı́a lógico pensar que podrı́a funcionar en este último. No obstante, tal y como
se ha visto anteriormente, Android incorpora sus propias modificaciones en el kernel, lo
cual hace necesario adaptar SELinux; motivo por el que se creó SEAndroid (SecurityEnhanced Android).
Una de las principales adaptaciones que se tuvieron que realizar sobre SELinux fue el
soporte a la comunicación entre procesos mediante Binder. Además, se tuvieron que
añadir librerı́as necesarias como la libselinux para conseguir una completa interacción.
Por otro lado, un factor interesante de seguridad que se añadió a SEAndroid fue Middleware MAC. Éste consiste en un control de acceso a nivel de Framework y, por tanto,
separado de la implementación MAC que se realiza a nivel de kernel. Su finalidad es
imponer un conjunto de restricciones que complementen las polı́ticas por las cuales se
rige MAC.
36
5 Fundamentos teóricos
5.2.2.
Extensiones de seguridad
Tal y como se ha observado, el epicentro de la seguridad en Android consiste en el
aislamiento de las aplicaciones, la signatura de código y el control de acceso mediante
permisos y polı́ticas. Estas incorporaciones nativas de seguridad no son suficientes para
garantizar un entorno seguro al usuario, el cual es el último responsable de permitir la
instalación de una aplicación.
A parte del impacto que puedan tener la decisiones erróneas de un usuario, existen ciertas vulnerabilidades en Android que son aprovechadas por atacantes y por el malware
que crean. Uno de los principales objetivos de éstos es evadir todas las restricciones de
acceso y control que impone Android, es decir, hacer una escalada de privilegios hasta
conseguir realizar acciones con total autoridad en el sistema. En este sentido, Android no
proporciona los suficientes mecanismos de protección para evitar dicha toma de control.
Para llevar a cabo una escalada de privilegios existen dos técnicas diferentes: Confused
deputy y Colluding. La primera, menos usada, hace referencia a situaciones en las cuales
una aplicación maliciosa emplea métodos de engaño, aprovechando vulnerabilidades en
funciones que se encargan de importar archivos, para confundir a otras aplicaciones con
mayores privilegios.
Por otro lado, la segunda técnica consiste en aprovechar la transitividad de permisos
entre aplicaciones. Por ejemplo, un desarrollador puede implementar una aplicación que
requiera acceso a INTERNET y otra con el permiso READ SMS, de tal modo que
puedan combinar sus funcionalidades para permitir la lectura de los mensajes del dispositivo desde el exterior. Dicha combinación podrı́a resultar sospechosa y ser detectada,
mediante extensiones de seguridad, como potencialmente peligrosa. Por este motivo,
aprovechando la facilidad de comunicación entre aplicaciones que comparten firma de
un mismo desarrollador, se distribuyen los permisos para conseguir privilegios que no
son permitidos y realizar ası́ una escalada de privilegios.
Otro aspecto difı́cil de controlar en Android es el uso que hacen las aplicaciones sobre
los datos privados de un usuario. Éstas pueden esconder sus verdaderas intencionalidades detrás de permisos que parecen necesarios para la aplicación y estar obteniendo
información privada sin el conocimiento del usuario. Este hecho se conoce como fuga de
información.
37
5 Fundamentos teóricos
Por los motivos anteriormente mencionados, entre otros, se han realizado investigaciones
para incorporar nuevos mecanismos de protección al modelo de seguridad de Android,
alguno de los cuales, como por ejemplo SEAndroid, se han incorporado de forma nativa
en recientes versiones.
En la figura 5.7 se muestra una recopilación de las extensiones de seguridad más populares separadas por la temática a la que atañen. Algunas de ellas serán analizadas en los
siguientes apartados.
Figura 5.7: Extensiones de seguridad
5.2.2.1.
Kirin
Kirin [13] es una extensión de seguridad que tiene como finalidad impedir la instalación
de aplicaciones sospechosas de tener un comportamiento malicioso.
Debido a que para los usuarios es difı́cil conocer el alcance real de los permisos que
aceptan pueden estar dando consentimiento a las aplicaciones para que actúen a su libre
albedrı́o. Es aquı́ donde interviene Kirin, no permitiendo la instalación de aplicaciones
con algunos permisos que considera dañinos.
Kirin utiliza reglas de seguridad predefinidas para detectar posibles combinaciones peligrosas de permisos en una misma aplicación.
38
5 Fundamentos teóricos
No obstante, sólo lleva a cabo este proceso de forma individual, es decir, analiza una
aplicación pero no es capaz de detectar una posible fuga de información a causa de la
combinación de permisos entre aplicaciones.
Algunos ejemplos de reglas representativas son:
1. Una aplicación no puede tener el permiso SET DEBUG APP
2. Una aplicación no puede tener el permiso RECORD AUDIO y INTERNET
3. Una aplicación no puede tener el permiso SEND SMS y WRITE SMS
Existe una extensión opcional que, una vez se ha analizado una aplicación, muestra al
usuario una lista detallada de todos los permisos que podrı́an tener un impacto en el
sistema. De este modo, el usuario es consciente de lo que puede implicar aceptarlos y
ası́ decide si proceder con la instalación o no.
5.2.2.2.
AdDroid
Otra herramienta de protección de software malicioso (malware) es AdDroid [14]. A diferencia de Kirin, AdDroid se focaliza en un ámbito concreto: las librerı́as de publicidad.
Cuando una agencia de publicidad quiere dar a conocer su producto a un amplio público,
la forma más fácil de hacerlo es contactar con los desarrolladores de las aplicaciones más
descargadas. Éstos incorporarán en su código las librerı́as de publicidad que les serán
otorgadas, las cuales proporcionan APIs que permiten la ubicación de dicha publicidad
dentro de la aplicación y gestionan la interacción con el usuario cuando pulsa sobre ésta.
El proceso de comunicación de estas librerı́as con el exterior queda ilustrado en la siguiente figura:
Figura 5.8: Comunicación entre librerı́as de publicidad y Android
39
5 Fundamentos teóricos
Tal y como puede observarse, las librerı́as de publicidad se comunican con la aplicación
y ésta es la que accede, mediante el uso de Binder, a recursos y servicios del sistema.
Por tanto, de este comportamiento se deduce que dichas librerı́as gozarán de los mismos
privilegios que tenga la aplicación. Esto se produce debido a que Android es incapaz de
diferenciar qué componente de la aplicación es el que realiza la petición, lo cual supone
un agujero de seguridad potencialmente peligroso.
Con la finalidad de regular las comunicaciones en Android que se realizan debido a la
incorporación de librerı́as de publicidad, se crearon diversas herramientas, entre las cuales destaca AdDroid.
Esta extensión de seguridad establece los permisos necesarios mı́nimos para que una
aplicación que requiera publicidad pueda mostrarla de forma segura al usuario. Esto se
realiza mediante el uso de una librerı́a y un servicio de AdDroid, los cuales se comunican
de forma segura sin hacer uso de librerı́as de terceros. El servicio de AdDroid es el encargado de gestionar la conexión con la publicidad y aportar abstracción a este proceso
entre la aplicación y la agencia, como se muestra en la figura 5.9.
Figura 5.9: Comunicación entre librerı́as de publicidad y Android usando AdDroid
40
5 Fundamentos teóricos
5.2.2.3.
XManDroid
A parte del malware existen otro tipo de amenazas, como la escalada de privilegios,
tal y como se ha descrito anteriormente, que no son prevenidas por Android. Es por este motivo por el cual surgen extensiones como XManDroid, QUIRE, IPC Inspection, etc.
En este apartado se analizará XManDroid [15], el cual protege ante situaciones que conducen a una escalada de privilegios, ya sea mediante la técnica de Colluding o Confused
deputy.
XManDroid (eXtended Monitoring on Android) es una extensión de seguridad que se
encarga de monitorizar y analizar, en tiempo de ejecución, las comunicaciones que se
establecen entre las aplicaciones. Su finalidad es detectar las combinaciones de permisos
potencialmente peligrosas que resultan de dichas comunicaciones.
El funcionamiento interno se rige entorno a una polı́tica de seguridad basada en reglas
predeterminadas. Consiste en comprobar que los permisos del emisor en la comunicación
no suponen un riesgo para el usuario y el sistema cuando se combinan con los permisos
del receptor. Dicha polı́tica de seguridad es parecida a la que implementa Kirin para
prevenir la instalación de aplicaciones maliciosas, pero en lugar de hacerlo de forma individual actúa sobre la interacción entre aplicaciones; permitiendo ası́ que un conjunto
aislado de permisos no pueda combinarse para proporcionar mayores privilegios de los
concedidos.
Algunos ejemplos de estas reglas predefinidas para identificar comunicaciones peligrosas
son:
1. Una aplicación que tiene permiso para leer SMS del usuario no puede comunicarse
con otra aplicación que pueda conectarse a Internet.
2. Una aplicación que reaccione ante una llamada entrante y tenga el permiso de
grabar audio no puede comunicarse con una aplicación que pueda conectarse a
Internet.
3. Una aplicación que puede obtener la información de localización no puede comunicarse con una aplicación que pueda conectarse a Internet.
41
5 Fundamentos teóricos
5.2.2.4.
ASF
Debido a que la escalada de privilegios puede darse en los diferentes módulos (niveles)
que componen el sistema operativo Android, diversas extensiones de seguridad se crearon para ofrecer una protección multinivel. Una de ellas es la ya mencionada SEAndroid,
la cual fue incorporada posteriormente como protección nativa del sistema.
A parte de SEAndroid, una importante contribución en la securización de Android es la
extensión ASF [18] (Android Security Framework).
Actualmente, las soluciones de seguridad creadas para reforzar la insuficiente protección
que ofrece Android se aplican de dos formas distintas. La primera consiste en el desarrollo de software que se incorpora a modo de parche en el módulo del sistema que se
ve afectado y la segunda se basa en integrar, de forma nativa, dicho software en nuevas
versiones de Android.
Ambas situaciones, a pesar de proporcionar remedio a las carencias del sistema, presentan inconvenientes relacionados con la total adaptación de las extensiones, la dificultad
que supone un correcto mantenimiento y actualización, etc.
Debido a este contexto se creó ASF, el cual se propone como la solución que permite
integrar, tanto a nivel de kernel como de aplicación, cualquier extensión de seguridad
ofreciendo, por un lado, una completa adaptación y compatibilidad con el sistema y
demás extensiones, y por otro lado, un conjunto de APIs para que los desarrolladores
de extensiones de seguridad puedan integrar sus implementaciones con mayor facilidad
y abstracción.
La arquitectura de seguridad de Android, tal y como se ha ido desgranando a lo largo
del proyecto, se ve reflejada en la figura 5.10.
Como puede observarse, una aplicación puede realizar llamadas a sistema para comunicarse con el kernel a fin de poder acceder, por ejemplo, a la SDCard. Para ello, hará
uso de un conjunto de APIs que, después de pasar los controles de acceso DAC y MAC,
tramitará la petición del usuario. Por otro lado, una aplicación puede hacer uso del mecanismo de comunicación entre procesos (Binder) para acceder a los servicios del sistema
que estén dentro de su alcance.
42
5 Fundamentos teóricos
Figura 5.10: Arquitectura de seguridad de Android
Tomando como base el esquema anterior, ASF se integra completamente en cada uno de
los diferentes módulos, tal y como se observa en la figura 5.11. Las incorporaciones que
se muestran marcadas en color azul son funciones dedicadas a proteger un recurso en
concreto del módulo sobre el cual actúan. Dichas funciones tienen comunicación entre
ellas para garantizar un flujo de seguridad ininterrumpido. Por otro lado, los módulos de
seguridad, mostrados de color verde, son los encargados de la toma de decisiones seguras
en base a un conjunto de polı́ticas establecidas.
Figura 5.11: Arquitectura de seguridad implantada por ASF
43
5 Fundamentos teóricos
5.2.2.5.
TaintDroid
Las extensiones de seguridad descritas hasta el momento están enfocadas a proteger al
usuario de software malicioso capaz de comprometer el sistema. No obstante, el uso que
hacen las aplicaciones con los datos privados de los usuarios no entra en el alcance de
protección. Por este motivo se desarrollaron herramientas como TaintDroid [15].
TaintDroid se propone como solución de seguridad al insuficiente control que proporciona Android a los recursos (fotografı́as, documentos, etc.) particulares de los usuarios. Su
funcionamiento se basa en realizar un seguimiento a cada recurso para que sea posible
monitorizar el flujo de datos entre aplicaciones.
El análisis que realiza TaintDroid de múltiples recursos, potencialmente sensibles, simultáneamente es en tiempo real para proporcionar un feedback instantáneo al usuario.
De este modo, éste último será consciente del uso concreto, y posiblemente malicioso
o poco lı́cito, que está haciendo una aplicación sobre un recurso determinado. Esto es
posible gracias al sistema de etiquetado de recursos de TaintDroid, el cual permite hacer
un seguimiento a través de los distintos módulos del sistema, tal y como se muestra en
la siguiente figura.
Figura 5.12: Seguimiento multinivel de recursos de TaintDroid
Como se observa, TaintDroid no sólo rastrea y registra movimientos de ficheros sino que
también permite etiquetar métodos que hacen uso de librerı́as, variables de programación (int, float, etc.) y mensajes transmitidos a través de Binder.
Un estudio [19] realizado con TaintDroid sobre las aplicaciones más descargadas de
Google Play reveló que dos terceras partes de éstas hacen un uso inapropiado de recursos
del usuario y sistema mediante el uso de permisos aparentemente inofensivos.
44
5 Fundamentos teóricos
Por ejemplo, se detectó que en múltiples aplicaciones se enviaba el identificador único
del dispositivo y número de teléfono a un servidor externo.
5.3.
Inseguridad de la información
Hoy en dı́a, el avance tecnológico ha conseguido facilitar de tal modo la vida de las
personas que prácticamente no se contempla seguir usando métodos rudimentarios del
pasado. Las potentes funcionalidades de los nuevos dispositivos que han salido al salido
al mercado en esta última década han cambiado la forma en la cual las personas organizan su tiempo, sus actividades y su información.
Estos dispositivos, a diferencia de los ordenadores convencionales, tienen la caracterı́stica
de ser ligeros y ofrecer cómodas prestaciones para un uso diario y continuado. Cada vez
más disponen de mayor capacidad para almacenar gran cantidad de contenido multimedia, documentos de texto y en general cualquier información que se pueda representar
en bytes.
Los cibercriminales son conscientes de este auge tecnológico y en consecuencia se han
modernizado adaptando su forma de actuar. Mediante el uso de las nuevas tecnologı́as
es posible obtener información de los usuarios de un sistema sin que apenas lleguen a
saberlo. Dicha información engloba todo tipo de contenido sensible que puede ser almacenado en un smartphone, tablet, portátil, etc.
Android se ha convertido en un extendido sistema operativo móvil y este hecho no ha
pasado desapercibido para los cibercriminales, los cuales han invertido en conocimiento para poder actuar con éxito sobre dicha plataforma. Utilizan multitud de métodos
distintos que de forma genérica pueden agruparse en ataques a la tecnologı́a y ataques
a los usuarios. A menudo es necesario una combinación de ambos para lograr su objetivo.
En cuanto a los ataques a la tecnologı́a, en este caso concreto Android, el modus operandi consiste en buscar vulnerabilidades conocidas que tenga la plataforma e intentar
explotarlas sobre un dispositivo en concreto. Este método puede ser bastante efectivo
contra aquellos usuarios que dispongan de una versión obsoleta o no soportada por los
desarrolladores de Android. En caso de que esto no fuera fructuoso, el cibercriminal
podrı́a analizar las comunicaciones externas del dispositivo a fin de encontrar cifrados
y/o protocolos débiles, lo cual le permitirı́a interceptar el tráfico (Man in the middle).
45
5 Fundamentos teóricos
Esta tarea serı́a más exitosa aún si el usuario interactúa con aplicaciones que envı́en las
credenciales en texto plano, es decir, sin cifrar.
Otros ataques más avanzados sobre Android consistirı́an en encontrar vulnerabilidades
no conocidas (0 days) para aplicaciones que utiliza el sistema. A modo de ejemplo, si
se consiguiera encontrar un bug en Adobe Reader que permitiera explotar otras vulnerabilidades y obtener acceso privilegiado sobre el sistema, los usuarios que abrieran un
archivo .pdf malicioso serı́an infectados. No obstante, este tipo de ataque requiere de
altos conocimientos técnicos para desarrollarlo.
Si los métodos anteriores, entre otros posibles no mencionados, no permitieran la substracción de la información deseada se deberı́an buscar opciones alternativas que requieran
la colaboración (in)consciente del usuario. Por tanto, el escenario de ataque planteado
en un principio cambia: si no se puede entrar desde fuera que sea el usuario quien abra
desde dentro.
Aquı́ es donde entra el conjunto de ataques dirigidos a los usuarios, los cuales pueden
entregar el control de su sistema sin saberlo. El conjunto de técnicas para llevarlos a
cabo se conoce como ingenierı́a social, la cual se detalla en la siguiente sección debido
a su alta implicación con la finalidad del proyecto. Una vez aplicada con éxito sobre el
usuario, los atacantes ya han conseguido evadir la restricción de acceso que les impedı́a
absoluta libertad y pueden hacer uso de malware que permita robar información, espiar
comunicaciones, mantener conexión constante entre vı́ctima y atacante, propagarse a
fin de infectar otros contactos, cifrar los datos del usuario para una posterior extorsión,
destruir el sistema de ficheros, etc.
Debido a la inmensidad de técnicas existentes contra sistemas y usuarios, ası́ como
también el amplio abanico de software malicioso que puede ser usado, el foco de este
proyecto se ha fijado en proporcionar una implementación práctica que proporcione
protección al usuario para evitar que sea vı́ctima de un tipo concreto de ingenierı́a
social: el Shoulder Surfing.
5.3.1.
Ingenierı́a social
La ingenierı́a social engloba un conjunto de técnicas que se basan, de forma genérica,
en la manipulación y engaño de las personas con la finalidad de evadir los sistemas de
seguridad y obtener información sensible y confidencial.
46
5 Fundamentos teóricos
Es decir, es el arte de persuadir a los usuarios para que lleven a cabo acciones que tengan
un impacto negativo en su privacidad o en la de la organización en la cual trabajen. Por
otro lado, la ingenierı́a social también incluye métodos en los cuales no se requiere de
la interacción con el usuario para obtener la información deseada, lo cual hace que la
substracción de datos sea sigilosa e inadvertida ante éste.
El éxito de todas estas técnicas no radica en los avanzados conocimientos técnicos del
atacante sino en sus habilidades sociales para ganarse la confianza de los usuarios de
un sistema sin que éstos sospechen de sus verdaderos propósitos. A menudo se recurre
a la ingenierı́a social cuando otros tipos de ataques, de carácter técnico, no consiguen
vulnerar el sistema atacado o bien obtener la información necesaria para hacerlo.
Por más que los desarrolladores de software optimicen sus sistemas y solucionen las vulnerabilidades que tienen sus productos, la confidencialidad e integración de los datos
sensibles almacenados en ellos dependerá de la administración y gestión de los usuarios
sobre dicho software. Por este motivo es por el cual las técnicas de ingenierı́a social cobran gran importancia y fijan su objetivo en el usuario; el eslabón más débil de la cadena.
Dos de éstas técnicas han afectado a un alto porcentaje de usuarios en Android:
Drive by download : este método se basa en la descarga de apps maliciosas de
forma automática cuando el usuario visita una web, la cual puede estar diseñada
para tal finalidad o simplemente haber sido vı́ctima de la intrusión de un cibercriminal. Estas aplicaciones presentan un nombre inofensivo para engañar al usuario
e incitarlo a abrirlas sin preocupación. La simple descarga por sı́ sola no compromete el sistema sino que requiere de un usuario confiado y curioso que la instale.
Phishing : esta técnica es un clásico para engañar a un usuario independientemente
del sistema operativo que esté usando. No obstante, desde la aparición de los nuevos
dispositivos móviles se ha incrementado el uso de Phishing. Esta técnica consiste
en enviar un email a la vı́ctima en nombre, por ejemplo, de su entidad bancaria
y proporcionarle un enlace para que ingrese a su supuesta cuenta. El éxito de
engañar al usuario se incrementa si éste usa un sistema operativo como Android,
el cual, a fin de proporcionar mejor experiencia al usuario, oculta la URL accedida.
Por otro lado, haciendo uso de algunos componentes disponibles en el desarrollo de
una aplicación es posible incrustar una web maliciosa sin ni siquiera presentar la
URL al usuario, con lo cual éste puede llegar a confiar en el sitio web simplemente
por ver una interfaz gráfica idéntica a la de su entidad bancaria.
47
5 Fundamentos teóricos
Éstas dos técnicas tan sólo son una pequeña representación de los distintos vectores
de ataque destinados a comprometer la seguridad de Android. A continuación, se comentarán con más profundidad dos técnicas incluidas dentro de la ingenierı́a social que
están más estrechamente relacionadas con la aplicación que se ha desarrollado en este
proyecto. La primera, Shoulder Surfing, es la técnica a la que se quiere neutralizar con
la implementación práctica de este trabajo. La segunda, Tapjacking, es la manera de
utilizar maliciosamente la funcionalidad que en este caso se ha aplicado para proteger
al usuario.
5.3.1.1.
Shoulder Surfing
Shoulder Surfing es una de las técnicas más fáciles de llevar a cabo ya que no requiere
tener conocimiento técnico alguno. Como se ha mencionado con anterioridad, este método consiste en observar, con el mayor grado de disimulo posible, las acciones que está
realizando otro usuario con su dispositivo.
Hay situaciones en las cuales es inevitable usar un smartphone sin que las personas
que están alrededor se percaten de cuál es el PIN del usuario, patrón, qué comenta
por Whatsapp, qué imagen abre, etc. Esta proximidad hace que sea mucho más fácil
la substracción de información, no obstante, desde una cierta lejanı́a también es posible predecir dónde está pulsando el usuario para introducir el PIN de desbloqueo. Este
hecho puede conseguirse, por ejemplo, haciendo uso de las recientes gafas de realidad
aumentada de Google u otro dispositivo capaz de grabar y ampliar la imagen con nitidez.
Por otro lado, existen situaciones en las cuales las personas de alrededor no son desconocidos sino todo lo contrario. En estos casos puede resultar incómodo decirle a un
amigo, compañero de trabajo, jefe, etcétera, que desvı́e momentáneamente la vista del
dispositivo para que no vean la introducción de una contraseña o PIN. Entonces suele
darse un momento de confianza forzada que conlleva a mostrar información sensible.
Sea cual sea la situación, el resultado acaba siendo la perdida de privacidad por parte del
usuario. A fin de solucionar dicho suceso, el desarrollo práctico de este proyecto aportará
una medida de protección adicional que permitirá mantener la privacidad del usuario e
impedirá que el simple hecho de mirar disimuladamente el dispositivo de otro usuario
sea una tarea totalmente exitosa.
48
5 Fundamentos teóricos
5.3.1.2.
Tapjacking
Otra técnica usada para engañar al usuario y obtener información de éste es Tapjacking.
A diferencia del Shoulder Surfing, esta técnica requiere de la interacción del usuario para
que se realice correctamente.
Su funcionamiento consiste en mostrar al usuario una interfaz que parezca una aplicación
interactiva pero en realidad no es más que una ventana que deja pasar los taps a través
de ella permitiendo que el usuario esté realizando acciones sin saberlo. Por ejemplo, el
usuario puede ver en un primer plano una pantalla opaca con un texto que le indique
’Pincha el globo’ y un globo que vaya apareciendo en distintas partes de la pantalla.
A cada pulsación sobre el supuesto globo, el usuario inconscientemente puede estar
seleccionando opciones de configuración que puedan comprometer su seguridad, como
por ejemplo habilitar la instalación de aplicaciones procedentes de fuentes no seguras.
Figura 5.13: Tapjacking
Una variante de esta técnica consiste en sobreponer una pantalla y asignarle la propiedad
de invisibilidad. De este modo el usuario verá a través de ella pensando que la aplicación
en primer plano con la que está interactuando es la que puede ver en pantalla. No
obstante, todos los taps que introduzca serán recogidos en primer lugar por la pantalla
transparente y luego se transferirán a la pantalla que se encuentra justo detrás de ésta.
49
5 Fundamentos teóricos
Este caso se muestra gráficamente en la siguiente figura, donde se observa como las
credenciales introducidas en una aplicación de una entidad bancaria podrı́an ser interceptadas y enviadas a un servidor externo.
Figura 5.14: Tapjacking con pantalla transparente
Para ello tan sólo es necesario implementar un servicio que esté a la escucha de los taps
que introduce el usuario y almacene las coordenadas de cada uno de ellos a fin de mapearlas posteriormente con las teclas pulsadas.
Como se puede observar en el siguiente código, los componentes View y WindowManager
permiten crear una ventana a la cual se le indica que debe estar atenta a las pulsaciones
que se produzcan sobre el dispositivo (34).
Código 5.1: Código principal para implementar tapjacking
50
5 Fundamentos teóricos
Acto seguido, a dicha ventana se le asignan un conjunto de flags para que tenga las
propiedades deseadas. El primero le indica que debe situarse por encima de otras aplicaciones (38), el segundo le asigna la propiedad de escuchar los eventos (pulsaciones) que
sucedan tanto dentro como fuera de la ventana (39) y el último le atribuye la propiedad
de ser transparente al usuario (40).
No obstante, Google se percató de este tipo de ataque y actualizo sus librerı́as de tal
modo que las versiones con una API level mayor o igual a 14, lo que corresponde a
versiones de Android 4.0 en adelante, ya no son vulnerables a este tipo de ataque.
Por otro lado, los desarrolladores pueden implementar en sus aplicaciones el atributo
android:filterTouchesWhenObscured=’true’ para impedir que sus aplicaciones reciban
los taps cuando otra aplicación se sobrepone. De este modo el usuario podrá percatarse
de que algo fuera de lo normal está ocurriendo.
51
6. Desarrollo del proyecto
6.1.
Descripción de la aplicación
Tal y como se ha descrito anteriormente, ésta aplicación tiene como objetivo aportar un
grado más de seguridad a los usuarios que requieran de proteger datos sensibles en su
dispositivo móvil.
Para ello, la aplicación cuenta con una interfaz que proporciona al usuario un conjunto de
funcionalidades para personalizar la protección que quiera llevar a cabo. Dicha interfaz se
muestra en las siguientes figuras, donde se pueden diferenciar los dos paneles principales.
Figura 6.1: Panel Configuración
Figura 6.2: Panel Protección
Como puede observarse, el diseño ha sido implementado de tal forma que el usuario
tenga una visión rápida y concisa de qué puede hacer con esta aplicación.
52
6 Desarrollo del proyecto
Es por eso que se ha optado por dividirla en sólo dos paneles; el de Configuración, el cual
permite gestionar el comportamiento de la aplicación, y el de Protección, que muestra
los recursos que pueden ser protegidos.
Entrando un poco más en detalle, el panel Configuración proporciona los siguientes cinco
ı́tems:
Estado de la protección: esta entrada permite iniciar y detener la protección
que ofrece la aplicación. De este modo, cuando el usuario se encuentre en un lugar
en el cual crea que está lo suficientemente seguro como para no necesitar ningún
bloqueo podrá desactivar dicha protección con tan sólo dos taps; sin necesidad de
navegar a través de múltiples menús. Además, tendrá la opción de hacerlo durante
un tiempo determinado (30min, 1h, 4h, 8h o hasta próximo reinicio), lo cual hará
que se reactive la protección pasado ese tiempo sin necesidad de volver al panel
Configuración.
Establecer PIN: este ı́tem permite configurar el PIN que protegerá a las aplicaciones que haya elegido el usuario cuando éstas sean lanzadas. El bloqueo con
PIN es el primer factor que debe afrontar el usuario para entrar a una aplicación
restringida.
Establecer taps invisibles: esta opción es la pieza angular de la aplicación. Proporciona al usuario la posibilidad de añadir un segundo factor de autenticación
una vez ha introducido correctamente el PIN. Para ello le permite establecer el
número de taps y la posición de éstos en la pantalla. Este segundo factor también
se puede deshabilitar y dejar sólo el bloqueo con PIN por defecto.
Entrenamiento: esta entrada proporciona al usuario un lugar en el cual practicar
su precisión para acertar sus taps. Esta funcionalidad se ha implementado porque
una vez se configura el patrón con dichos taps; los cuales son mostrados por pantalla al usuario, ya no los volverá a ver debido a que la pantalla transparente que
los recoge no muestra información sobre la posición pulsada.
Historial: en esta opción se mostrará al usuario el listado de aplicaciones protegidas junto con el número de aciertos y fallos que se han realizado para cada una
de ellas. Además, la fecha y hora del último acceso también quedarán reflejadas.
De este modo el usuario podrá saber si se ha realizado algún intento de espionaje
sobre su dispositivo durante el tiempo que se ha ausentado de éste.
53
6 Desarrollo del proyecto
En cuanto al panel Protección, como puede observarse en la figura anterior, hay cuatro
tipos de recursos que pueden ser protegidos con la aplicación. El recurso principal, para
el cual ha sido diseñada esta app, es el conjunto de aplicaciones que hay en sistema.
Complementariamente se han añadido el conjunto de imágenes, vı́deos y archivos del
usuario en el dispositivo.
La protección de éstos tres últimos funciona diferente a la protección de aplicaciones
debido a razones técnicas que se explicarán más adelante.
6.2.
Procedimiento
El funcionamiento principal de la aplicación se realiza en un segundo plano, es decir, sin
necesidad de interactuar con la interfaz gráfica. Esto se consigue mediante el uso de un
servicio que está activo todo el tiempo.
La finalidad de este servicio es detectar las aplicaciones lanzadas y aplicar el bloqueo a
aquellas que se han seleccionado para protegerlas. Para ello, lo ideal serı́a que el servicio
estuviera en un estado de reposo y una vez se lanzara dicha aplicación se despertara para
actuar. Sin embargo, cuando una aplicación se lanza, el sistema no envı́a información al
resto de las aplicaciones sobre este hecho, lo cual hace que no sea factible implementar
un broadcast receiver para este evento en el servicio.
Por tanto, es necesario implementar un método de espera activa. Éste consiste en consultar repetidamente si ha ocurrido tal evento en lugar de esperar un aviso por parte de
éste. La contrapartida de este método es el consumo de baterı́a, pero actualmente es la
única opción que ofrece Android.
Una vez detectada la aplicación, el siguiente paso serı́a guardar el nombre de ésta,
impedir que se abra, lanzar la aplicación de bloqueo y en caso de que se introdujese
correctamente el PIN volver a lanzar la aplicación protegida sin pedir esta vez el PIN.
No obstante, una aplicación no puede detener a otra a no ser que tenga el permiso de
root y el dispositivo esté rooteado. Sólo está permitido detener activities que compartan
el mismo UID, es decir, dentro de una misma aplicación.
54
6 Desarrollo del proyecto
Esto obliga a aceptar que dicha aplicación se abrirá sı́ o sı́ y es entonces cuando el servicio en segundo plano debe lanzar la app de bloqueo para que se posicione justo encima
e impida ver el contenido de la protegida.
Este escenario provoca que se cree una situación difı́cil de controlar. Ésta se produce
entre el lanzamiento de la aplicación a proteger y la espera activa del servicio que consulta si debe o no activar la protección. Por ejemplo, si el servicio comprueba cada dos
segundos cuál es la aplicación que está en primer plano y justo después el usuario lanza
la que se tiene que proteger, el tiempo hasta que el servicio vuelva a hacer la consulta
será tiempo en el cual se previsualizará el contenido de la app protegida. El problema se
puede resolver reduciendo el tiempo de consulta del servicio pero esto tiene un impacto
en el consumo de energı́a.
Una vez se ha lanzado la protección con bloqueo, el siguiente paso es recoger el PIN
introducido y validar el acceso. En caso de que sea correcto, el servicio comprobará si
el usuario habilitó el segundo factor de autenticación y en caso afirmativo lanzará una
pantalla transparente. Ésta se encargará de recoger los taps que introduzca el usuario y
comprobar que lo haya hecho en la posición correcta (con un margen de error también
elegido por el usuario).
Si este proceso lo realiza satisfactoriamente, la pantalla transparente desaparecerá como
si nada hubiera pasado, es decir, no mostrará ningún mensaje de acierto al usuario y le
permitirá interactuar con la aplicación protegida. En caso contrario, el servicio volverá
a lanzar la pantalla de bloqueo con PIN simulando un comportamiento inesperado de la
aplicación pero sin informar de la existencia de un segundo factor invisible que ha sido
fallido.
Todo este procedimiento tiene como finalidad proteger con discreción, de tal modo que un
observador no reciba ningún tipo de información sobre lo que realmente está ocurriendo.
6.3.
Diagrama de flujo
En esta sección se detallará gráficamente, mediante un diagrama de flujo, todo el procedimiento explicado en la sección anterior. Pero antes se mostrará el diagrama que hubiera
sido ideal para optimizar el uso de la baterı́a pero que no ha sido posible implementar
por las cuestiones técnicas ya comentadas.
55
6 Desarrollo del proyecto
El diagrama de flujo ideal sobre el cual se parte y se adapta a las condiciones de Android
puede observarse en la siguiente figura.
Figura 6.3: Diagrama de flujo ideal
El inicio de todo el proceso radica en que el sistema operativo comunica al servicio que
la aplicación que se quiere proteger ha recibido una petición de lanzamiento (A). Entonces, el servicio cierra la aplicación (B) antes de que llegue a mostrarse por pantalla
y en su lugar abre la aplicación de bloqueo (C). El resto del procedimiento (D, E, F, G)
corresponde a la validación del PIN y de los taps posteriores.
Debido a que los tres primeros pasos marcados en rojo no pueden implementarse de la
forma mostrada se han reemplazado por la espera activa del servicio, la cual chequea
constantemente si se ha abierto alguna de las aplicaciones que el usuario ha marcado
como protegidas. Ésta se muestra en la siguiente figura.
Figura 6.4: Espera activa del servicio
56
6 Desarrollo del proyecto
Por otro lado, y debido a la restricción que impide cerrar otras apps, hay una nueva
situación a contemplar que no se da en el diagrama ideal y sı́ en el real. Ésta se produce
durante la comprobación del PIN, ya que es un estado en el cual se espera un input
por parte del usuario y no realiza ninguna otra acción hasta que no se envı́e dicho PIN
a validar. En este punto, un usuario malintencionado puede aprovechar que la aplicación a proteger no ha sido cerrada y retomarla porque todavı́a está en la pila de tareas
recientemente abiertas. En la siguiente figura se muestra dicha situación, en la cual la
aplicación a proteger en este caso es la calculadora.
Figura 6.5: Pila de tareas recientemente abiertas
Esta lista de tareas recientes se obtiene pulsando el botón Home de los dispositivos con
sistema operativo Android y, como se puede ver, resulta bastante sencillo evadir la protección que proporciona Double Lock tan sólo seleccionando la aplicación calculadora en
esta lista.
Para paliar este bypass se ha introducido otra espera activa que consulta constantemente
si el usuario está intentando cambiar de aplicación y en caso afirmativo volverı́a a lanzar
el bloqueo. A continuación, se muestra la parte del diagrama de flujo que representa tal
acción.
57
6 Desarrollo del proyecto
Figura 6.6: Comprobación de cambio de aplicación
En el siguiente diagrama de flujo se puede observar el procedimiento completo que seguirá el servicio, el cual es resultado de la combinación de las distintas partes mostradas
anteriormente.
Figura 6.7: Diagrama de flujo final
6.4.
Funcionalidades
A continuación, se analizará cada funcionalidad desde la perspectiva de un desarrollador,
es decir, se mostrará el código y las decisiones tomadas en cada situación. Debido a que
la aplicación consta de 38 clases Java y 36 ficheros XML, haciendo un total aproximado
de 10.800 lı́neas de código, se seleccionará un extracto representativo de las clases más
relevantes.
58
6 Desarrollo del proyecto
6.4.1.
Estado de la protección
Tal y como se ha mencionado anteriormente, la aplicación Double Lock cuenta con una
funcionalidad que permite el inicio y la detención del servicio que corre en segundo plano.
El acceso a ésta se ha ubicado en la primera entrada del menú Configuración a fin de
proporcionar comodidad y rapidez al usuario. Por otra parte, se permite deshabilitar
la protección temporalmente haciendo que el usuario no necesite volver a acceder para
habilitarla de nuevo.
Para ello se proporciona la siguiente interfaz gráfica al usuario, la cual le permite realizar
este proceso con tan sólo dos taps.
Figura 6.9: Protección deshabilitada
Figura 6.8: Opciones disponibles
El código necesario para implementar dicha funcionalidad se muestra en el código 6.1.
Solamente requiere consultar el estado actual (101-102) guardado en el espacio de memoria que dispone cada aplicación, conocido como SharedPreferences, y hacer uso del
widget AlertDialog para mostrar las opciones preestablecidas.
Una vez el usuario elige la opción que quiere, la función pararServicioTemporalmente
(113) es llamada con los parámetros deseados (30 minutos, 1 hora, 4 horas, 8 horas o
hasta reinicio).
59
6 Desarrollo del proyecto
Código 6.1: Opciones para deshabilitar la protección
Cuando dicha función se ejecuta, lo primero que hace es establecer una alarma (199-201)
que levantará de nuevo la protección cuando haya pasado el tiempo elegido (205,209).
Código 6.2: Configuración de la alarma
Finalmente, se para el servicio que está en ejecución haciendo uso del método stopService. Como se observa en el código 6.3, en función de la versión de Android del dispositivo
se ejecutará una función u otra. Esta decisión técnica se explicará más adelante.
Código 6.3: Parada del servicio
60
6 Desarrollo del proyecto
La configuración de la alarma, con la elección correcta de sus parámetros, permite reducir el consumo de baterı́a debido a que el sistema avisará a la aplicación una vez haya
transcurrido el tiempo, mediante los broadcast receivers explicados en secciones anteriores, en lugar de ser la aplicación quien pregunte si es el momento indicado o no. La
siguiente figura muestra el código para levantar el servicio (23-24) cuando salte la alarma.
Código 6.4: Ejecución de la alarma
6.4.2.
Establecer PIN
El primer factor de protección que aparece cuando se lanza una aplicación protegida
es el bloqueo mediante PIN. Éste se configura en la Activity de la figura 6.10, y los
parámetros que requiere son: el PIN actual, el nuevo PIN, la repetición de éste, y un
número de contacto para restablecer el PIN en caso de olvido.
Figura 6.11: Ventana de bloqueo
Figura 6.10: Establecer PIN
61
6 Desarrollo del proyecto
En un primer diseño de esta sección se optó por restablecer el PIN mediante el envı́o
de un email a la cuenta del usuario. No obstante, esta solución requiere del permiso
Internet que ofrece Android, y tal y como se ha explicado anteriormente, existen técnicas maliciosas que combinan este permiso junto con otros para llevar a cabo acciones
que pueden tener un impacto totalmente negativo en la confidencialidad de los usuarios.
Por tanto, a fin de proporcionar mayor confianza a éstos del uso de Double Lock se ha
descartado usar Internet.
En base a este hecho, la aplicación enviará en su lugar un SMS al número de teléfono que
se haya introducido. Serı́a preferible que éste fuera el de una persona de total confianza.
Si se optara por poner el mismo número del dispositivo actual, el SMS se previsualizarı́a
en el mismo y no aportarı́a ningún tipo de protección. También se puede elegir la opción
de no introducir ninguno si el usuario cree estar convencido de no olvidar el PIN.
En las siguientes figuras se muestra la ventana de bloqueo de la aplicación principal
(Double Lock) junto con la funcionalidad que restablece el PIN. A diferencia de la ventana de bloqueo anterior, ésta incorpora un texto clickable por si el usuario olvida su
código. La decisión de ponerlo sólo en la aplicación principal tiene como objetivo dificultar el envı́o involuntario de SMS.
Figura 6.12: Bloqueo principal
Figura 6.13: Restablecer PIN
62
6 Desarrollo del proyecto
Mediante el siguiente código se recogen los parámetros introducidos por el usuario, se
validan (72) y se procede a almacenarlos en SharedPreferences (75,79). No obstante, en
esta ocasión se hace uso de una librerı́a externa (SecurePreferences) para almacenar el
PIN cifrado con AES (Advanced Encryption Standard) y reforzar ası́ la protección.
Código 6.5: Configuración del PIN
La función comprueba() es la encargada de revisar los parámetros introducidos y devolver error en caso de una mala configuración. La parte relevante a destacar es el uso de
la ya mencionada librerı́a SecurePreferences (97,98), la cual permite trabajar de forma
cómoda y segura con los datos de SharedPreferences.
Código 6.6: Uso de SecurePreferences
6.4.3.
Establecer taps invisibles
En este apartado el usuario tendrá la opción de fortalecer su protección mediante la
activación de los taps invisibles. Una vez lo haga se activará la otra opción que aparece
en la figura 6.14, deshabilitada en un principio, y que proporciona una solución para
evitar la previsualización del contenido durante la introducción de los taps.
63
6 Desarrollo del proyecto
Para ello permite elegir una imagen de la galerı́a y establecerla como la Activity que
recogerá dichos taps. De este modo, una vez se introduce correctamente el PIN, en lugar
de previsualizar el contenido de la aplicación protegida se mostrará dicha imagen. Es
decir, no habrá ninguna transparencia y por tanto un observador podrá identificar que
existe otro factor de protección. Sin embargo, se gana en privacidad.
Figura 6.14: Taps con transparencia
Figura 6.15: Taps sin transparencia
Cuando el usuario ha elegido sus preferencias, el siguiente paso es empezar a registrar
las posiciones en pantalla donde pulsa. Esta acción se representa mediante un cı́rculo
verde por cada pulsación.
Paralelamente se muestra un cronómetro que indica el tiempo que tarda el usuario en
introducir los taps. Este tiempo será el que esperará la Activity transparente antes de
comprobar los inputs recibidos. Transcurrido ese tiempo y en caso de haber un acierto
inferior al 100 % aparecerá de nuevo la ventana de bloqueo impidiendo el acceso a la
aplicación protegida.
64
6 Desarrollo del proyecto
Para finalizar el proceso, el usuario deberá pulsar el botón Stop y elegir entre repetirlo
de nuevo o bien avanzar y guardar los taps en la memoria de la aplicación.
Figura 6.16: Introducción de taps I
Figura 6.17: Introducción de taps II
Tal y como se muestra en las siguientes figuras, el diámetro puede ser ajustado dependiendo de la precisión de acierto que quiera el usuario.
Figura 6.19: Modificación del radio II
Figura 6.18: Modificación del radio I
65
6 Desarrollo del proyecto
Al pulsar el botón Siguiente se mostrará un mensaje informando del establecimiento
correcto de los taps y preguntando al usuario si desea practicarlos o bien volver al menú
principal. La primera opción se detallará en la siguiente sección.
Figura 6.20: Taps establecidos
El código de todo este proceso involucra diversas clases Java. Por tanto, para no hacer
tan ardua la lectura al lector, se mostrará la implementación de un número reducido
de funciones; las cuales harán de hilo conductor para explicar técnicamente las figuras
anteriores.
La primera de ellas, como se observa en el código 6.7, es la encargada de detectar las
coordenadas de los diferentes taps. Para ello se hace uso del método onTouch que proporciona Android, el cual permite de forma cómoda recoger dichos valores (89,90). Esta
información se almacena en una clase Punto, creada con anterioridad, junto con el tiempo transcurrido hasta ese momento (98,99).
Por otro lado, la representación gráfica de estos puntos se hace mediante el método onDraw y la declaración de un objeto Canvas. A este último se le aplica un conjunto de
propiedades que darán formato a los puntos (48-51) y posteriormente se usa su método
drawCircle (54,58,63) para mostrarlos por pantalla.
66
6 Desarrollo del proyecto
Código 6.7: Recogida de taps del usuario
Código 6.8: Representación gráfica de los taps
Una vez haya introducido los taps que desea y quiera seguir adelante deberá pulsar el
botón Siguiente. En él se implementa el código necesario para recopilar dichos taps (148),
el tiempo total transcurrido (149) y el radio (150) elegido para determinar la zona de
acierto válida. Estos valores se almacenan en SharedPreferences (153-157) y acto seguido
se invoca a la Activity Finalizar (159,160).
67
6 Desarrollo del proyecto
Código 6.9: Almacenamiento de los taps
6.4.4.
Entrenamiento
Con la finalidad de proporcionar al usuario un mejor recuerdo sobre los taps que ha configurado, la funcionalidad Entrenamiento le permite introducirlos y evaluar su precisión.
Como se muestra en las siguientes figuras, primero aparece una pantalla con un temporizador iniciado en tres segundos que le indica cuando debe empezar a introducir los
taps. Esto permite al usuario estar preparado e introducirlos dentro del tiempo correcto.
Figura 6.22: Taps de entrenamiento
Figura 6.21: Pantalla introductoria
68
6 Desarrollo del proyecto
A diferencia de la sección anterior, esta vez no se muestra el botón Stop sino que automáticamente se cierra la pantalla transparente después del tiempo ya establecido. Acto
seguido, se muestra gráficamente las zonas consideradas válidas y los resultados numéricos: número de taps correctos y tiempo total.
Figura 6.23: Visualización gráfica I
Figura 6.24: Resultados I
Figura 6.25: Visualización gráfica II
Figura 6.26: Resultados II
69
6 Desarrollo del proyecto
El código para implementar esta funcionalidad es bastante parecido al mostrado en la
sección anterior. No obstante, en esta ocasión se debe determinar si los taps marcados
en rojo se encuentran dentro de las circunferencias verdes y con su correcto orden de
introducción.
Para tal finalidad se ha implementado el método evalua que se aprecia en la siguiente
figura. Su primera comprobación es que el número de taps introducidos sea el mismo que
el almacenado (86-89). En caso de ser el mismo se pasa a verificar si cada uno de ellos
es correcto o no mediante las coordenadas cartesianas (92-94). Finalmente, la función
devuelve True si ha habido un acierto absoluto y el tiempo del último tap se encuentra
dentro del tiempo establecido.
Código 6.10: Evaluación de los taps introducidos
6.4.5.
Historial
La entrada Historial del menú Configuración es la encargada de recopilar la información
de uso de la aplicación Double Lock en el sistema. Proporciona un registro para que el
usuario tenga los datos concretos sobre el acceso a una aplicación protegida. Éste incluye
el número de accesos correctos, fallidos y fecha del último acceso.
De este modo, si el usuario tiene a alguien en su entorno que conoce el PIN e intenta
espiar sin ser detectado, la aplicación lo reflejará en el historial; dejando al descubierto
dicha vulneración de la intimidad.
Tal y como se observará a continuación, en el historial aparecen las aplicaciones que
actualmente están protegidas. Si el usuario desprotege alguna de éstas, su entrada en el
historial desaparecerá pero seguirá conservando sus contadores.
70
6 Desarrollo del proyecto
Por otro lado, si decide reiniciar dichos contadores podrá hacerlo de forma individual
pulsando encima de cada aplicación, o bien pulsar el icono de la papelera para reiniciarlos todos.
Figura 6.27: Historial de accesos
Figura 6.28: Reinicio de contadores
Para implementar dicha funcionalidad se ha usado un ListView para mostrar las aplicaciones y una base de datos para recoger los valores de cada una de ellas.
En el siguiente código se puede observar cómo se selecciona la plantilla gráfica (fichero
layout asociado) (273) que contiene el aspecto genérico que tendrá cada entrada.
Código 6.11: Gestión de cada entrada del historial
71
6 Desarrollo del proyecto
Seguidamente, se trata de manera individual cada ı́tem recogiendo su nombre e icono
(277-280) y asignándolos a la posición de la interfaz que les corresponde. Finalmente,
se instancian los campos que mostrarán los valores almacenados (283-285) y se llama a
la función openHistId (287) pasándole el nombre de la aplicación a buscar en la base de
datos.
Como se aprecia en el código 6.12, esta función inicia una conexión con la base de datos
(336), la cual ha sido creada en otra clase Java, y consulta el método creado getHistId
para obtener y asignar la información de los accesos a su posición concreta dentro la
interfaz.
Código 6.12: Obtención de valores de la base de datos
6.4.6.
Protección de aplicaciones
Una vez analizadas las funcionalidades del panel Configuración, a continuación se explicarán las del panel Protección. Para empezar se detallará la funcionalidad principal de
la aplicación: la protección de otras aplicaciones.
Tal y como se muestra en la siguiente imagen, las aplicaciones instaladas en el sistema
se muestran ordenadas alfabéticamente junto con su icono asociado. Para proteger cualesquiera de ellas, el usuario deberá pulsar encima de la que desee y podrá observar un
candado verde indicando que esa aplicación se ha marcado a proteger. Para cancelar la
protección bastará con que vuelva a pulsar sobre la misma.
72
6 Desarrollo del proyecto
Figura 6.29: Aplicaciones a proteger
Para obtener el listado de las aplicaciones instaladas se ha creado la clase LoadApplications que se observa a continuación. En ella, el proceso de búsqueda de las aplicaciones
(130) se ha implementado dentro del método doInBackground de la clase AsyncTask.
Éste permite realizar tareas en un segundo plano a la vez que muestra por pantalla,
por ejemplo, un mensaje (139), acompañado de una rueda de progreso, para informar al
usuario que se todavı́a continua el proceso.
La decisión de hacerlo en segundo plano se ha tomado debido a que el tiempo que tardaba la aplicación en listar los resultados de su búsqueda oscilaba entre los tres y seis
segundos, lo cual daba una primera sensación de no haber encontrado nada o de estar a
punto de bloquearse. Esta sensación desaparece al mostrar el mensaje informativo sobre
el estado actual dentro del método onPreExecute.
Código 6.13: Realización de la búsqueda en segundo plano
73
6 Desarrollo del proyecto
El código anterior realiza una llamada al método buscaLauncher que se muestra en el
código 6.14, el cual consulta todas las aplicaciones que en su AndroidManifest.xml hay
declarada la propiedad Launcher; que permite a una aplicación poder ser lanzada por el
usuario.
Código 6.14: Búsqueda de aplicaciones en el sistema
Cuando se ha pulsado encima de una aplicación con la finalidad de protegerla, esta información debe almacenarse en la memoria reservada de Double Lock para que el servicio
que se encarga de lanzar el bloqueo pueda acceder a consultarla en cualquier momento.
Este sencillo proceso puede verse en la siguiente imagen, donde primero se intenta cargar
el listado de aplicaciones protegidas (261,262), en caso de existir, luego se añade la nueva
aplicación a proteger (264-268) y acto seguido se almacena de nuevo esta información
(270-272).
Código 6.15: Guardar aplicaciones protegidas
74
6 Desarrollo del proyecto
6.4.7.
Protección de contenido privado
Complementariamente a la protección de aplicaciones se ha decidido ofrecer la capacidad al usuario de proteger su contenido privado, entendiendo por éste imágenes, vı́deos
y archivos.
La utilización del método de protección que se ha empleado para las aplicaciones es
ineficaz en el caso de este contenido. Esto es ası́ debido a que es posible acceder a éste
evitando el factor de protección. Por ejemplo, un usuario malintencionado que tuviera
acceso momentáneo al dispositivo de otro podrı́a usar el explorador de archivos para
acceder a dicho contenido y enviarlo por correo. Por otro lado, otras aplicaciones instaladas con el permiso de lectura del almacenamiento interno y/o externo serı́an capaces
de conseguir dicho material sin ningún inconveniente.
Por tanto, para proteger el contenido del usuario se deben buscar otros métodos. Uno
de ellos podrı́a consistir en renombrar los archivos poniéndoles un punto delante para ocultarlos a otras aplicaciones y prevenir que puedan ser abiertos. Sin embargo, el
contenido sigue estando en el mismo lugar y visible a través de un explorador de archivos.
Otro método consiste en mover los archivos que se quieren proteger a la memoria interna
de la aplicación de protección. No obstante, esto sólo previene el acceso de otras aplicaciones a dicho contenido pero no lo protege del acceso manual mediante un explorador
de archivos. Además, tiene como problema añadido que la memoria interna suele ser de
menor capacidad que la externa y por tanto no tendrı́a capacidad suficiente de proteger
una gran cantidad archivos.
Debido a las vulnerabilidades que presentan estos métodos se ha optado por cifrar directamente el archivo en el mismo lugar donde está almacenado en memoria y sólo poder
visualizar el contenido mediante la aplicación Double Lock. De este modo, a pesar de
que a través de un explorador se pudiera acceder al material protegido y enviarlo por
Internet o Bluetooth, éste seguirı́a estando inaccesible.
Para cada uno de los tres tipos de contenido se ha creado una interfaz gráfica y se ha
dotado de funcionalidades diferentes aunque comparten gran parte del proceso de cifrado. Tal y como se muestra en las siguientes capturas, la interfaz para proteger imágenes
presenta tres opciones: descifrar, cifrar y añadir imágenes.
75
6 Desarrollo del proyecto
Figura 6.31: Selección de imágenes de
la galerı́a
Figura 6.30: Interfaz para proteger
imágenes
Una vez se pulsa el botón verde para cifrarlas ya no podrán ser mostradas en la pantalla
de protección debido a que no se guarda ninguna miniatura para ofrecer mayor protección. Por este motivo se muestra un candado amarillo en el centro de la pantalla.
Figura 6.32: Imágenes cifradas
Figura 6.33: Desproteger imagen
76
6 Desarrollo del proyecto
Cuando el usuario descifra las imágenes pulsando el botón rojo aparecerán de nuevo las
miniaturas de éstas. Si entonces decide pulsar sobre alguna de ellas se le mostrará una
ventana emergente que le preguntará si la quiere quitar de la lista de imágenes a proteger.
El segundo tipo de contenido que permite cifrar la aplicación son los vı́deos. La interfaz
gráfica es la misma que la mostrada en las capturas anteriores, tan sólo cambia el hecho
de que la galerı́a permitirá elegir únicamente vı́deos.
Finalmente, si el usuario quiere cifrar cualquier tipo de archivo en su dispositivo (documentos de texto, archivos comprimidos, etc.), podrá hacerlo mediante el ı́tem Archivos
del menú Protección. Para ello se le proporciona la misma vista de un explorador de
archivos, la cual muestra todas las carpetas y ficheros existentes.
En estas capturas de ejemplo aparece un listado de ficheros de texto que pueden ser
cifrados si el usuario pulsa sobre ellos.
Figura 6.34: Lista de archivos
Figura 6.35: Archivo cifrado
Y el resultado de cifrar el archivo anterior mediante AES256 es el siguiente:
Figura 6.36: Contenido del archivo cifrado
77
6 Desarrollo del proyecto
En cuanto a la implementación que hay detrás de estas funcionalidades se mostrará a
continuación la parte más representativa del proceso de selección del contenido, cifrado
y descifrado.
Para la selección del contenido de la galerı́a tanto para imágenes como vı́deos es necesario declarar un elemento especı́fico en Android al cual se le asocia una acción que debe
llevarse a cabo. Este elemento se conoce como Intent (464) y necesita en este caso dos
parámetros. El primero es la acción requerida (465) y el segundo es el destino donde se
realizará tal acción (466). Finalmente, se manda a ejecutar este Intent (467).
Código 6.16: Selección de contenido de la galerı́a
La respuesta obtenida de la acción anterior se recoge en el siguiente código, donde se
observa que se comprueba que el resultado sea correcto y el código recibido sea el especificado anteriormente (473).
Acto seguido, se recoge el contenido seleccionado (474), en este caso una imagen, y se
obtiene la ruta para almacenarla y tener la imagen localizada para el proceso de cifrado
y descifrado (475-477).
Código 6.17: Contenido guardado para cifrar
Una vez se ha seleccionado el contenido ya puede ser cifrado. Para ello se llama a la
función encryptFile donde se tratará una a una las imágenes a cifrar. El primer paso
es pasar a Bitmap la imagen a partir de su ruta (75). A continuación, se detecta la
extensión (77,78) y en función de un formato u otro se decide la compresión a aplicar
(82,87).
78
6 Desarrollo del proyecto
Debido a que esta compresión de la clase Bitmap sólo puede aplicarse a imágenes con
extensiones .jpeg y .png se ha añadido un caso base en el switch para tratar otro tipo de
extensiones que pueda mostrar la galerı́a. En este caso base (91) no se usa compresión
y directamente se llama a la función cifrar (96).
Código 6.18: Cifrado del contenido I
En cuanto a la función cifrar, Google proporciona la clase Cipher para que el desarrollador pueda crear fácilmente una instancia de ésta (129) especificando el algoritmo de
cifrado, el modo de operación y el tipo de padding. A partir de aquı́ se inicializa el cifrado
(131) y se aplica a la imagen (133).
Código 6.19: Cifrado del contenido II
79
6 Desarrollo del proyecto
El proceso de descifrado hace uso de la misma clase Cipher pero en la inicialización esta
vez se habilita la opción DECRYPT MODE (151), se descifra el contenido (152) y se
crea un buffer de bytes para ir leyendo la imagen descifrada.
Código 6.20: Descifrado del contenido
Finalmente, se llama a otra función que no figura en las capturas y se guarda la imagen
en el mismo sitio donde estaba.
Tanto para las imágenes como vı́deos y archivos la clase usada es la ya mencionada
Cipher y las implementaciones sólo se diferencian en pequeñas funcionalidades.
6.4.8.
Servicio
Por último, se describirá en esta sección el componente que lleva a cabo la protección
con un segundo factor de autenticación. Se trata del servicio que está en segundo plano
escuchando los eventos que suceden en el dispositivo.
Su funcionamiento consiste en consultar constantemente si debe proteger o no la aplicación que hay en primer plano. Para ello primero comprueba si la protección está
habilitada (80-82), consulta cuál es la aplicación que acaba de abrir el usuario (83) y si
es una de las marcadas a proteger (85) se hace una llamada a las funciones lanzarBloqueoPin y compruebaPin.
80
6 Desarrollo del proyecto
Código 6.21: Consulta de la aplicación en primer plano
La primera de ellas simplemente se encarga de preparar el entorno para lanzar la interfaz gráfica que muestra la pantalla de bloqueo. Por otro lado, la segunda se encarga
de estar a la espera de la introducción del PIN por parte del usuario con la finalidad
de concederle o denegarle el acceso. El código de esta última se muestra en la siguiente
figura.
Código 6.22: Comprobación del número PIN
Como se puede observar, la función compruebaPin se espera hasta que el PIN introducido por el usuario sea correcto (197). Para prevenir realizar miles de acciones innecesarias
se ha aplicado un tiempo de un segundo en el cual no se hace literalmente nada (190).
Acto seguido, se consulta en SharedPreferences si el usuario ya ha hecho tal acción y
cuál es el resultado de ésta. Por otro lado, también se comprueba si ha decidido cambiar
de aplicación para evitar que esta función se quede en un bucle infinito (196-199).
Finalmente, en caso de que el PIN sea correcto, se llama a un conjunto de funciones
para recoger y validar los taps (en caso de estar habilitados) y se actualiza la base de
datos que lleva el control de accesos.
81
6 Desarrollo del proyecto
6.4.9.
Tutorial
Con la finalidad de proporcionar la información necesaria al usuario para hacer un uso
correcto de la aplicación se ha elaborado un videotutorial que cubra todas las funcionalidades. De este modo el usuario sabrá de una forma rápida y cómoda cómo funciona cada
una de las partes de la aplicación y el orden lógico que debe seguir para configurarla
correctamente.
Como se aprecia en las siguientes figuras, el videotutorial está alamacenado en Youtube
y se proporciona la URL para acceder a él. Esto se debe a que la aplicación no tiene
el permiso de Internet a fin de proporcionar más confianza al usuario, tal y como ya
se ha mencionado anteriormente. Por otro lado, la posibilidad de incluirlo dentro de la
aplicación se ha descartado por el tamaño de almacenaje que requerirı́a.
Figura 6.37: Tutorial
Figura 6.38: Link del tutorial
82
7. Gestión económica
7.1.
Consideraciones iniciales
En las siguientes secciones se analizarán los costes derivados del desarrollo del proyecto.
Debido a que se trata de un proyecto universitario, las estimaciones se han realizado teniendo en cuenta que los costes asociados a cada tarea y rol están sujetos a la condición
de becario del autor del trabajo.
No obstante, con la finalidad de dotar los cálculos de realismo profesional, se ha añadido
la estimación de costes contemplando el desarrollo del proyecto en un entorno laboral.
Por tanto, se considerarán dos escenarios: el primero, en adelante Escenario A, contemplará el contexto estudiantil, mientras que el segundo, Escenario B, considerará un
entorno profesional.
7.2.
Identificación y estimación de costes
El presupuesto necesario para la realización del proyecto viene determinado por los factores que tienen un impacto económico directo o indirecto en él. En consecuencia, el
primer paso para la elaboración de un presupuesto es identificar dichos factores y estimar sus costes.
En este proyecto se distinguen tres factores: humano, hardware y software, los cuales
serán analizados y clasificados según su intervención. Por otro lado, también se detallará
la partida de contingencia y los imprevistos que se han tenido en cuenta.
83
7 Gestión económica
7.2.1.
Costes directos
En esta sección se muestran los costes correspondientes a las tareas del diagrama de
Gantt ası́ como los asociados al material imprescindible para realizar el proyecto.
El factor con impacto económico que interviene en la realización de las tareas es el
humano. Por tanto, como puede observarse en la siguiente tabla, el coste total viene
determinado por el salario/hora correspondiente a la categorı́a profesional de cada rol.
Tabla 7.1: Costes recursos humanos
A continuación, se muestran los costes asociados a cada actividad teniendo en cuenta
los datos de la tabla anterior.
Tabla 7.2: Costes directos por actividad
84
7 Gestión económica
Por otro lado, los costes asociados al material usado son los siguientes:
Amortización hardware: el portátil Fujitsu LifeBook usado durante todo el
proyecto se adquirió en 2011 y el dispositivo móvil Samsung Galaxy S3 es de 2012,
por tanto, se consideran recursos amortizados.
Software: el software usado, tanto el especı́fico para programar como el propio
sistema, es libre y no se ha pagado por él.
Tabla 7.3: Costes directos de material
7.2.2.
Costes indirectos
Los costes indirectos asociados al proyecto pueden ser parcialmente calculados debido a
que la información sobre el alquiler, consumo de agua, electricidad, etc., no es de fácil
acceso para un becario. Por tanto, los principales costes que se tendrán en cuenta son:
Transporte: los desplazamientos se han realizado haciendo uso del transporte
público. El coste asociado es el de dos tarjetas trimestrales de metro.
Impresiones en papel: el proyecto se imprimirá para proporcionar una copia del
mismo a cada miembro del tribunal. Si se estima una extensión de 90 hojas por
copia serán necesarias 270 impresiones.
Tabla 7.4: Costes indirectos
85
7 Gestión económica
7.2.3.
Contingencia
Otro aspecto a tener en cuenta en el presupuesto es la partida de contingencia. En este
proyecto se destinará a ésta un 15 % de la suma de costes directos e indirectos.
Tabla 7.5: Costes contingencia
7.2.4.
Imprevistos
Tal y como se ha mencionado en secciones anteriores, la planificación temporal se realizó
teniendo en cuenta una serie de imprevistos, los cuales tienen sus costes asociados:
Retraso de 7 dı́as: debido a que la parte más sensible de sufrir una desviación
temporal es la de programación, el salario necesario para dichas labores se tendrá
en cuenta suponiendo una jornada de 15h diarias de un programador durante siete
dı́as.
Averı́a del hardware: debido a que la empresa donde se realiza el proyecto está
totalmente ligada al mundo informático hay una gran disposición de equipos de
repuesto en caso de averı́a, tanto móviles como portátiles.
Tabla 7.6: Costes imprevistos
7.2.5.
Presupuesto
En este proyecto no se han tenido en cuenta los beneficios que se podrı́an generar mediante la incorporación de módulos de publicidad en la aplicación, ya que se entiende
que es de carácter universitario. Por otro lado, no se contempla una subida de salario a
lo largo del desarrollo del proyecto.
86
7 Gestión económica
En la siguiente figura se muestra el presupuesto final para cada uno de los escenarios.
Tabla 7.7: Presupuesto
7.3.
Control de gestión
Con la finalidad de controlar la evolución del proyecto se realizará una imputación de
horas al final de la semana. De este modo, cada rol registrará la dedicación realizada y
sabrá las horas que dispone para realizar las tareas que tiene asociadas.
Mediante este control será posible detectar si las horas dedicadas a cada tarea sobrepasan el presupuesto estimado o no. En caso afirmativo se identificarán las causas que han
producido el desajuste presupuestario y se tendrán en cuenta en las tareas siguientes
para reducir la diferencia de costes.
Si finalmente el coste real supera al presupuestado se aplicará la partida de imprevistos
y contingencia para cubrir la diferencia.
Los indicadores utilizados para controlar la gestión de desviaciones son los siguientes:
Desvı́o de mano de obra en precio = (coste std – coste real) * consumo de
horas real
Desvı́o en la realización de una tarea en precio = (coste std – coste real) *
consumo horas real
Desvı́o total en la realización de tareas = coste total std tarea – coste total
real tarea
Desvı́o total costes fijos = coste total fijo presupuestado – coste total fijo real
87
8. Sostenibilidad y compromiso social
8.1.
Valoración de la sostenibilidad
El estudio realizado sobre la sostenibilidad de este proyecto se muestra resumido en la
siguiente tabla y se detalla en las siguientes secciones.
Tabla 8.1: Valoración sostenibilidad
La alta puntuación total obtenida, 25 puntos, hace que este proyecto sea viable para ser
desarrollado y tenga en general un impacto positivo en los tres ámbitos que se detallarán
a continuación: económico, social y ambiental.
8.2.
Económica
Para determinar la viabilidad económica de un proyecto es preciso conocer todos los
factores que pueden suponer costes en él. Esto se ha tenido en cuenta en secciones anteriores y en consecuencia se ha elaborado un presupuesto.
Observando los resultados obtenidos en éste se puede ver que los costes principales hacen
referencia al factor humano. Por otro lado, el hecho de usar dispositivos relativamente
antiguos pero funcionales ha servido para reducir el presupuesto. Del mismo modo, el
uso de software libre ha permitido el ahorro de licencias comerciales.
A parte de ahorrar con estas medidas se debe tener en cuenta que el producto desarrollado, aún y ser distribuido de forma gratuita en el mercado de Google, podrı́a contar
con módulos de publicidad para generar ingresos. Este hecho harı́a que el coste presupuestado del proyecto fuera viable en caso de querer hacerlo competitivo.
88
8 Sostenibilidad y compromiso social
No obstante, el principal punto negativo de este proceso es la competencia existente en
el mercado, la cual ocupa altas posiciones en las listas oficiales de descargas.
Debido a que el tiempo dedicado a cada tarea es proporcional a su importancia no se
considera que se podrı́a reducir la duración de cierta tarea para desarrollar el proyecto
en un menor tiempo. No obstante, la contratación de un programador con experiencia
en Android reducirı́a los tiempos de auto-aprendizaje y programación, pero en el ámbito
universitario del proyecto esto no aplica. También, la colaboración con otro proyecto
relacionado agilizarı́a todo el desarrollo pero este escenario tampoco se contempla.
En consecuencia, la viabilidad económica para este proyecto se considera que tiene una
valoración de 9.
8.3.
Social
La expansión del sistema Android en los últimos años ha sido de una enorme magnitud,
tal y como ya se ha comentado. Tanto es ası́ que se ha convertido en el sistema más
usado en la actualidad.
Este hecho ha propiciado que los usuarios encuentren en este sistema un lugar en el cual
almacenar información privada y confidencial. A causa del uso diario y constante que
se hace de los dispositivos móviles, una gran cantidad de situaciones adversas pueden
tener un impacto en la confidencialidad de los usuarios. Por ejemplo, la contraseña de
bloqueo de un documento protegido de un ejecutivo podrı́a ser vista por otra persona en
el transporte público, lugar de trabajo, etc. En consecuencia, existe una necesidad real
de mejorar la protección ante ciertas situaciones y este es el aspecto que intenta cubrir
este proyecto.
Sin embargo, como punto negativo se encuentra el hecho de que la aplicación desarrollada contempla proteger eficazmente un escenario concreto. Éste es el que se produce
cuando una persona pierde de vista su dispositivo durante un intervalo de tiempo relativamente corto. Si un atacante roba el dispositivo cuenta con un amplio arsenal de
técnicas en Internet para acabar consiguiendo los datos que desea.
Debido a que esta aplicación está destinada a ofrecer una protección adicional a usuarios
de Android, un gran colectivo que requiera mejorar su seguridad puede beneficiarse de
ella.
89
8 Sostenibilidad y compromiso social
Los usuarios de otros sistemas operativos que hay en el mercado no se verán afectados
ni positiva ni negativamente por la aparición de esta aplicación.
Teniendo en cuenta estos hechos se valora la sostenibilidad social con un 7.
8.4.
Ambiental
De los recursos mencionados anteriormente, el principal que puede generar un impacto
ambiental es el hardware, pero al tratarse únicamente de un portátil y un móvil su consumo no aumenta la huella ecológica pero tampoco se puede considerar que contribuya
a reducirla. Del uso de la aplicación tampoco se espera que tenga ningún impacto en
dicha huella ecológica.
Por otro lado, estos dispositivos seguirán siendo usados en la empresa una vez concluya
este proyecto, con lo cual su vida útil se exprimirá al máximo. Por estos motivos se
puntúa la sostenibilidad ambiental con un 9.
90
9. Conclusiones
Android es un potente sistema operativo con multitud de funcionalidades que son de
gran utilidad en el dı́a a dı́a de los usuarios. Está dotado de la última tecnologı́a y su
evolución es notable con el paso de las versiones.
No obstante, y a pesar de estar respaldado por una de las compañı́as más potentes de
hoy en dı́a, Google, este sistema está lejos de rozar la perfección. Como se ha podido ver
en la parte teórica, el modelo de seguridad sobre el cual se basa Android requiere de un
refuerzo considerable para proporcionar mayor protección al usuario, ya que las medidas
implantadas actualmente no ponen freno a bastantes situaciones destinadas a comprometer su privacidad. Es cierto que cada nueva versión da un paso hacia adelante y cubre
vulnerabilidades existentes pero los cibercriminales también actualizan sus métodos.
Por este motivo, es necesario que investigaciones externas contribuyan a mejorarlo paliando situaciones que éste no contempla. Como se ha podido ver, existen potentes
extensiones de seguridad que están disponibles y algunas otras ya han sido incorporadas
de forma nativa en las nuevas versiones.
Aún y ası́ siempre existen vulnerabilidades que pueden ser aprovechadas para sustraer
información confidencial de un usuario, el cual es el principal punto de entrada para
tomar el control de un sistema. De nada sirve disponer de aplicaciones de protección con
una algoritmia perfecta si al final la seguridad radica en el uso que haga un usuario de
su dispositivo. Por lo tanto, hay que crear tecnologı́a que facilite su protección.
En relación a este último aspecto, se ha demostrado que la aplicación desarrollada en este
proyecto proporciona un nivel más de protección que pasa desapercibido ante terceras
personas y permite al usuario autenticarse de forma cómoda y sin necesidad de focalizar
toda su atención en el momento de la autenticación. En consecuencia, se ha cumplido el
objetivo de reforzar la privacidad de un usuario dificultando la sustracción de información
mediante Shoulder Surfing.
91
Bibliografı́a
[1] Smartphone-Os-Market-Share @ Www.Idc.Com.
URL http://www.idc.com/
prodserv/smartphone-os-market-share.jsp.
[2] Hadeel Tariq Al-Rayes. Studying Main Differences between Android & Linux Operating Systems. International Journal of Electrical and Computer Sciences, 12(5):
46–49, 2012.
[3] Dave MacLean Sayed Hashimi, Satya Komatineni. Pro Android 3. URL https:
//books.google.es/books?id=RuN0jb4YASwC{&}pg=PA6.
[4] Android API levels.
URL http://developer.android.com/intl/es/guide/
topics/manifest/uses-sdk-element.html{#}ApiLevels.
[5] Activity life cycle. URL http://developer.android.com/intl/es/reference/
android/app/Activity.html.
[6] Sebastian Neuner, Victor Van Der Veen, and Martina Lindorfer. Enter Sandbox:
Android Sandbox Comparison. 3rd IEEE Mobile Security Technologies Workshop,
2014.
[7] P. Wijesekera, A. Baokar, A. Hosseini, S. Egelman, D. Wagner, and K. Beznosov.
Android permissions remystified: A field study on contextual integrity. PrivacyCon,
14 January 2016, 2016. URL https://www.ftc.gov/system/files/documents/
public{_}comments/2015/09/00013-97595.pdf.
[8] Asim S. Yuksel, Abdul H. Zaim, and Muhammed A. Aydin. A Comprehensive Analysis of Android Security and Proposed Solutions.
International Jour-
nal of Computer Network and Information Security, 6(12):9–20, 2014.
20749090.
doi: 10.5815/ijcnis.2014.12.02.
ISSN
URL http://www.mecs-press.org/
ijcnis/ijcnis-v6-n12/v6n12-2.html.
[9] Nikolay Elenkov. Android Security Internals. 2014. ISBN 9781593275815. doi:
10.1016/S1353-4858(15)30046-5.
92
Bibliography
9 Bibliografı́a
[10] Jim Huang.
Android IPC Mechanism.
pages 1–82, 2012.
URL papers3:
//publication/uuid/0426FD04-B1DA-49CF-941B-BE85092B6322.
[11] forum.xda-developers.com.
URL
http://forum.xda-developers.com/
showthread.php?t=2620456.
[12] Joshua J. Drake, Pau Oliva Fora, Zach Lanier, Collin Mulliner, Stephen a. Ridley,
and Georg Wicherski. Android Hacker’s handbook. 2014. ISBN 9781118608647.
[13] Parvez Faruki, Ammar Bharmal, Vijay Laxmi, Vijay Ganmoor, Manoj Singh Gaur,
Mauro Conti, and Muttukrishnan Rajarajan. Android Security: A Survey of Issues,
Malware Penetration, and Defenses. IEEE Communications Surveys & Tutorials,
(2):998–1022. ISSN 1553-877X. doi: 10.1109/COMST.2014.2386139.
[14] Bahman Rashidi and Carol Fung. A Survey of Android Security Threats and Defenses. (Enero):3–35, 2015. ISSN 20935382.
[15] Asim S. Yuksel, Abdul H. Zaim, and Muhammed A. Aydin. A Comprehensive Analysis of Android Security and Proposed Solutions.
International Jour-
nal of Computer Network and Information Security, 6(12):9–20, 2014.
20749090.
doi: 10.5815/ijcnis.2014.12.02.
ISSN
URL http://www.mecs-press.org/
ijcnis/ijcnis-v6-n12/v6n12-2.html.
[16] Daniel W K Tse, X Liu, Hong Kong, Christopher Nusaputra, Hong Kong, B Hu,
Hong Kong, Y Wang, Hong Kong, M W Xing, and Hong Kong. Strategies in
improving android security. 26, 2013.
[17] John Viega and Bret Michael. Mobile Device Security. IEEE Security & Privacy
Magazine, 8(2):99–101, 2010. ISSN 1540-7993. doi: 10.1109/MSP.2010.76.
[18] Michael Backes, Sven Bugiel, Sebastian Gerling, and Philipp von Styp-Rekowsky.
Android Security Framework: Extensible Multi-Layered Access Control on Android.
Acsac 2014, 2014. doi: 10.1145/2664243.2664265. URL https://www.infsec.
cs.uni-saarland.de/{~}bugiel/publications/pdfs/bugiel14-acsac1.pdf$\
delimiter"026E30F$npapers3://publication/doi/10.1145/2664243.2664265.
[19] William Enck, Landon P Cox, Peter Gilbert, and Patrick Mcdaniel. TaintDroid :
An Information-Flow Tracking System for Realtime Privacy Monitoring on Smartphones.
[20] Android history. URL http://www.androidcentral.com/android-history.
93