Aplicación De Bloqueo Para La Prevención De Shoulder Surfing

Transcript

Seguridad en Android: Aplicaci´ on de bloqueo para la prevenci´ on de Shoulder Surfing Cristian Torres Barrantes Trabajo de Fin de Grado dirigido por Manel Medina Llin`as Departamento de Arquitectura de Computadores Facultat d’Inform`atica de Barcelona Universitat Polit`ecnica de Catalunya Junio 2016 Resumen Desde que a finales de 2008 sali´ o al mercado la primera versi´on oficial del sistema operativo Android ha ido aumentando el n´ umero de usuarios de smartphones hasta que, en la actualidad, el 82.8 % de ´estos 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´ on 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´etodos usados para comprometer la privacidad de los usuarios. Por otro lado, se desarrolla una aplicaci´on para proteger la sustracci´on de informaci´ on sensible de dichos usuarios ante un tipo concreto de ataque de ingenier´ıa social: Shoulder Surfing. ´Indice Resumen I ´ Indice de figuras V ´ Indice de c´ odigos VIII ´ Indice de tablas X 1. Introducci´ on 1.1. Formulaci´ on del problema . . 1.2. Contextualizaci´ on . . . . . . . 1.2.1. Definici´ on 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´ on del alcance . . . . . . . . 2.2. Riesgos y obst´ aculos . . . . . . . . . 2.3. Metodolog´ıa y rigor . . . . . . . . . 2.3.1. M´etodos de trabajo . . . . . 2.3.2. Herramientas de seguimiento 2.3.3. M´etodos de validaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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´ on y motivaci´on . . . . . . . . 3.2. Entorno . . . . . . . . . . . . . . . . . . 3.3. Estado actual . . . . . . . . . . . . . . . 3.4. Dise˜ no arquitect´ onico e Implementaci´on 3.5. Gesti´ on de riesgos . . . . . . . . . . . . 3.6. Competencias t´ecnicas de la especialidad . . . . . . . . . . . . 4. Planificaci´ on temporal 4.1. Planificaci´ on estimada del proyecto . . . . . 4.2. Descripci´ on de las tareas . . . . . . . . . . . 4.3. Diagrama de Gantt . . . . . . . . . . . . . . 4.4. Recursos . . . . . . . . . . . . . . . . . . . . 4.5. Valoraci´ on de alternativas y plan de acci´on ii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ´ Indice iii 5. Fundamentos te´ oricos 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´on 5.1.1.5. Aplicaciones . . . . . . . . 5.1.2. Arquitectura de una aplicaci´on . . . 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´ on de permisos . . . . 5.2.1.3. Acceso a memoria . . . . . 5.2.1.4. Protecci´on de datos . . . . 5.2.1.5. Signatura de c´odigo . . . . 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´on . . . . . . . . 5.3.1. Ingenier´ıa social . . . . . . . . . . . 5.3.1.1. Shoulder Surfing . . . . . . 5.3.1.2. Tapjacking . . . . . . . . . 6. Desarrollo del proyecto 6.1. Descripci´ on de la aplicaci´on . . . . . . . 6.2. Procedimiento . . . . . . . . . . . . . . . 6.3. Diagrama de flujo . . . . . . . . . . . . . 6.4. Funcionalidades . . . . . . . . . . . . . . 6.4.1. Estado de la protecci´on . . . . . 6.4.2. Establecer PIN . . . . . . . . . . 6.4.3. Establecer taps invisibles . . . . 6.4.4. Entrenamiento . . . . . . . . . . 6.4.5. Historial . . . . . . . . . . . . . . 6.4.6. Protecci´ on de aplicaciones . . . . 6.4.7. Protecci´ on 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 ´ Indice iv 6.4.9. Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 7. Gesti´ on econ´ omica 7.1. Consideraciones iniciales . 7.2. Identificaci´ on y estimaci´on 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´ on . . . . . . . . . . de costes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8. Sostenibilidad y compromiso social 8.1. Valoraci´ on de la sostenibilidad . . 8.2. Econ´ omica . . . . . . . . . . . . . . 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 ´Indice 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´on . . . . . . . . . . . . . . . . . . . . . . . . 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´ on entre procesos mediante Binder . . . . . . . . . . . . . . . . 35 5.7. Extensiones de seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.8. Comunicaci´ on entre librer´ıas de publicidad y Android . . . . . . . . . . . 39 5.9. Comunicaci´ on 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´ on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.2. Panel Protecci´ on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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´ on de cambio de aplicaci´on . . . . . . . . . . . . . . . . . . . . 58 6.7. Diagrama de flujo final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 6.8. Opciones disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 6.9. Protecci´ on 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´ on de taps I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6.17. Introducci´ on de taps II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6.18. Modificaci´ on del radio I . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6.19. Modificaci´ on del radio II . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6.20. Taps establecidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6.21. Pantalla introductoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 6.22. Taps de entrenamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 6.23. Visualizaci´ on gr´ afica I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 6.24. Resultados I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 6.25. Visualizaci´ on gr´ afica 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´agenes . . . . . . . . . . . . . . . . . . . . . . . . 76 6.31. Selecci´ on de im´ agenes de la galer´ıa . . . . . . . . . . . . . . . . . . . . . . 76 6.32. Im´ agenes 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 ´Indice de c´ odigos 5.1. C´ odigo principal para implementar tapjacking . . . . . . . . . . . . . . . . 50 6.1. Opciones para deshabilitar la protecci´on . . . . . . . . . . . . . . . . . . . 60 6.2. Configuraci´ on de la alarma . . . . . . . . . . . . . . . . . . . . . . . . . . 60 6.3. Parada del servicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 6.4. Ejecuci´ on de la alarma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6.5. Configuraci´ on del PIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 6.6. Uso de SecurePreferences . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 6.7. Recogida de taps del usuario . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.8. Representaci´ on gr´ afica de los taps . . . . . . . . . . . . . . . . . . . . . . . 67 6.9. Almacenamiento de los taps . . . . . . . . . . . . . . . . . . . . . . . . . . 68 6.10. Evaluaci´ on de los taps introducidos . . . . . . . . . . . . . . . . . . . . . . 70 6.11. Gesti´ on de cada entrada del historial . . . . . . . . . . . . . . . . . . . . . 71 6.12. Obtenci´ on de valores de la base de datos . . . . . . . . . . . . . . . . . . . 72 6.13. Realizaci´ on de la b´ usqueda en segundo plano . . . . . . . . . . . . . . . . 73 6.14. B´ usqueda de aplicaciones en el sistema . . . . . . . . . . . . . . . . . . . . 74 6.15. Guardar aplicaciones protegidas . . . . . . . . . . . . . . . . . . . . . . . . 74 6.16. Selecci´ on 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´on en primer plano . . . . . . . . . . . . . . . . . . 81 6.22. Comprobaci´ on del n´ umero PIN . . . . . . . . . . . . . . . . . . . . . . . . 81 ´Indice 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´ on sostenibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 x 1. Introducci´ on 1.1. Formulaci´ on del problema Desde que a finales de 2008 sali´o al mercado la primera versi´on oficial del sistema operativo Android ha ido aumentando el n´ umero de usuarios de smartphones hasta que, en la actualidad, el 82.8 % [1] de ´estos utilizan este sistema. Este hecho ha propiciado el aumento del inter´es en atacar dicha plataforma con el fin de sustraer informaci´ on privada a los usuarios. En este contexto, se pretende realizar una comprensi´on del funcionamiento de la seguridad en Android y de las t´ecnicas m´as utilizadas para lograr evadir la protecci´on que ofrece este sistema operativo. Centrando el foco de atenci´ on en un tipo concreto de estas t´ecnicas se lleva a cabo el desarrollo de una aplicaci´ on, alternativa a las ya existentes en el mercado, que proporciona una protecci´ on adicional en el momento de introducir un patr´on 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´a el problema actual de las aplicaciones que ofrecen la funcionalidad de bloquear en base a un patr´on o PIN: la efectividad se ve anulada cuando un tercero descubre la combinaci´on correcta. La situaci´ on a la cual se pretende dar soluci´on con el dise˜ no de esta aplicaci´on es el ´ denominado Shoulder Surfing. Este se basa en t´ecnicas de observaci´on directa de un dispositivo con la finalidad de sustraer informaci´on sensible del usuario. Esto sucede frecuentemente debido a la cantidad de situaciones en las cuales los usuarios utilizan sus dispositivos m´ oviles en p´ ublico. Se puede ejemplificar con el siguiente caso: un compa˜ nero de clase observa el patr´ on de desbloqueo de la galer´ıa de fotograf´ıas de otro y en un posible descuido de ´este u ´ltimo podr´ıa ganar acceso a dicho contenido. 1 1 Introducci´ on Aunque se diera esta situaci´ on, o similares, el hecho de tener un segundo nivel de protecci´ on ignoto para el atacante dificultar´ıa el acceso de ´este a los recursos protegidos. Con este fin se desarrolla la aplicaci´on que se expone en este proyecto. 1.2. 1.2.1. Contextualizaci´ on Definici´ on del contexto Este proyecto se enmarca en el ´ambito de la seguridad en sistemas Android. En concre´ to, la aplicaci´ on creada ata˜ ne al concepto de ataque de ingenier´ıa social. Este se define como un conjunto de t´ecnicas de manipulaci´on que se realizan sobre los usuarios con la finalidad de conseguir informaci´on confidencial. Existe un amplio abanico de t´ecnicas que se engloban dentro de este tipo de ataque, las cuales suelen implicar el uso de correo electr´onico, tel´efono u otro tipo de comunicaci´ on que pretende provocar situaciones de urgencia, miedo u otras, con el fin de enga˜ nar al usuario para que revele informaci´on sin ser consciente de estar siendo v´ıctima de un fraude. No obstante, algunas de estas t´ecnicas no requieren de un interacci´on directa entre el atacante y su v´ıctima, como es el caso de Shoulder Surfing. Shoulder Surfing es una de las pr´acticas m´as utilizadas para obtener informaci´on 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´on de esta t´ecnica 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˜ nas u otros datos. En este tipo de ataque el usuario es el factor vulnerable por lo que no se puede conseguir una total erradicaci´ on del problema. Es aqu´ı donde surge la idea de la aplicaci´on 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´ on Desarrollador: es el principal actor del proyecto. Es el responsable de recopilar, estructurar y redactar la informaci´on adem´as de desarrollar la aplicaci´on. Director: Manel Medina Llin` as, Catedr´atico de Arquitectura de Computadores en la Universitat Polit`ecnica de Catalunya, es el encargado de guiar y asistir este proyecto. Usuarios beneficiados: esta aplicaci´on va dirigida a los usuarios que requieren mejorar la protecci´ on de la privacidad de sus dispositivos mediante un segundo nivel de autenticaci´ on que pase desapercibido ante posibles observadores. Estos usuarios podr´ an 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˜ nado originalmente para dispositivos m´ oviles con pantalla t´actil. El uso de este sistema ha experimentado un gran crecimiento y aceptaci´on entre los usuarios de smartphones hasta el punto de que a finales de 2015 ocho de cada diez dispositivos usaban Android. La r´ apida expansi´ on de Android se debe principalmente a la gran cantidad de aplicaciones que salen al mercado ofreciendo u ´tiles funcionalidades a los usuarios. Este hecho es consecuencia de la f´ acil adaptaci´on que tienen los desarrolladores de software a la arquitectura de este sistema. Dicha arquitectura se compone de distintos m´odulos [2, 3] que se interconectan para compartir informaci´ on y hacer uso de las funcionalidades ofrecidas por el resto de ellos. Esta modularidad permite a programadores y usuarios abstraerse de la compleja implementaci´ on interna y poder realizar sus tareas de una forma m´as c´omoda. Tanto para un usuario est´ andar como para un desarrollador, la piedra angular de este sistema, la cual proporciona atracci´on y utilidad del mismo, son las aplicaciones. Una aplicaci´ on est´ a formada por varios componentes [4, 5] que proporcionan un amplio abanico de funcionalidades para que puedan ser implementadas por el programador. ´ Este es el encargado de interactuar con las interfaces que proporciona Android a fin de facilitar el desarrollo de la aplicaci´on de una forma correcta y segura. 3 1 Introducci´ on 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´ on de ´esta. Es por ello que Android establece un modelo de seguridad, basado en el modelo de Linux, con la intenci´ on 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´ on limitado y pueden ser evadidas [11–14] por atacantes. Esto propulsa la aparici´on 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´ on del alcance El presente proyecto se orienta a la creaci´on de una aplicaci´on m´ovil 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˜ no de esta aplicaci´ on 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´orica s´olida, se ha otorgado un peso considerable a la parte bibliogr´afica de este ´ambito. 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´on interna del mismo. Posteriormente, se profundiza en la seguridad de Android debido a que es el aspecto m´as importante y m´ as estrechamente relacionado con la aplicaci´on desarrollada en este trabajo. Por u ´ltimo, se hace una revisi´ on sobre los m´etodos m´as comunes utilizados por los cibercriminales con la finalidad de sustraer informaci´on . En cuanto a la parte pr´ actica de este proyecto, lo que se pretende es crear una aplicaci´ on que aporte un segundo nivel de protecci´on, invisible para posibles observadores, que proteja a las aplicaciones, evitando as´ı el Shoulder Surfing. 5 2 Alcance del proyecto 2.2. Riesgos y obst´ aculos 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´ a 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´on temporal se realizar´ a de modo que tenga cabida la gesti´on de posibles adversidades sin que interfieran en el flujo de este trabajo. Algunas de ´estas 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. Este influir´a en la rapidez con la cual avanzar´a la implementaci´ on del proyecto. A causa de la gran extensi´on que ha experimentado Android a lo largo de los u ´ltimos a˜ nos, un gran n´ umero de recursos est´an disponibles para que el alumno pueda formarse y alcanzar los conocimientos necesarios para la correcta finalizaci´on de las tareas programadas. Por tanto, a pesar de ser un factor importante no ser´a del todo condicionante. 2.3. Metodolog´ıa y rigor En esta secci´ on se expondr´ a el m´etodo 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´ etodos 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 ´agil 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´on entre cliente y desarrollador (director y alumno) para seguir de cerca cada avance. Este hecho aporta flexibilidad ante cambios, ya que ´estos, al formar parte del proceso de desarrollo, no se entienden como un problema sino como algo necesario para que el producto sea mejor. Adem´ as, 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´ on sea adaptable al trascurso del proyecto. Esto proporciona una mejor predicci´ on de los tiempos necesarios para realizar cada tarea. Estas caracter´ısticas m´ as significativas de SCRUM hacen que se ajuste a las necesidades requeridas en este trabajo y en consecuencia se pondr´an en pr´actica. 2.3.2. Herramientas de seguimiento A lo largo del desarrollo del proyecto se utilizar´an distintas herramientas para asegurar un correcto procedimiento y garantizar que la integridad del trabajo est´a protegida ante circunstancias disruptivas. La principal herramienta de trabajo ser´a Android Studio, la cual proporciona todo un entorno adaptado al desarrollo de aplicaciones para Android. Adem´as, permite la conexi´on con un gestor de repositorios en red como Git, GitHub, Mercurial, etc., para tener un control de versiones sobre el c´odigo 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´on constante con la nube. De este modo, cualquier cambio realizado en un fichero queda registrado tanto en la m´ aquina f´ısica como en un medio de almacenamiento en l´ınea, el cual cuenta con una capacidad de 50GB. Adem´ as, Mega permite exportar un enlace que especifica la ruta de acceso a la carpeta respaldada. Esta caracter´ıstica ser´a aprovechada para permitirle al director del proyecto poder consultar los avances realizados de una forma c´omoda y remota. 7 2 Alcance del proyecto 2.3.3. M´ etodos de validaci´ on Debido a las caracter´ısticas definidas anteriormente sobre el modelo de trabajo a seguir, SCRUM, los m´etodos de evaluaci´on se ajustar´an a las pautas que establece dicho modelo. Es decir, el trabajo ser´a 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´ on entre el director y el alumno se realizar´a semanalmente v´ıa correo electr´ onico. En ella, el alumno detallar´a los avances realizados a lo largo de la semana y esperar´ a el feedback del director para modificar el estado actual del trabajo, en caso de haber tareas desarrolladas de forma err´onea, y consolidar el rumbo a seguir; evitando as´ı desviaciones. Con este fin se establece un per´ıodo m´aximo de dos semanas en el cual puede permanecer el proyecto sin ser evaluado. 8 3. Pliegue de condiciones 3.1. Descripci´ on y motivaci´ on El conjunto de funcionalidades que proporciona Android, en combinaci´on con la evoluci´on tecnol´ ogica de los dispositivos m´oviles, 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 ´estas se encuentra una que es pr´acticamente inherente al usuario: la gesti´on de informaci´ on 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 alma´ cenan datos sensibles. Estos pueden ser documentos, contenido multimedia, registros de mensajer´ıa instant´ anea, etc., o bien informaci´on que permita identificar y ubicar a un usuario; historial de navegaci´ on, posicionamiento GPS, registro de llamadas, etc. Ante este hecho, el mundo del cibercrimen se ha volcado en la exploraci´on intensa de este sistema para encontrar vectores de ataque que permitan obtener datos privados de los usuarios; principalmente con ´animo de lucro. El objetivo sobre el cual recae el foco de atenci´ on de un ataque es una vulnerabilidad persistente en todos los sistemas inform´ aticos: el usuario. El usuario de hoy d´ıa hace un uso constante de los dispositivos m´oviles 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´ orica de este proyecto se combinar´a con una parte pr´actica que consistir´ a en una aplicaci´ on destinada a proporcionar seguridad a los usuarios de Android. Dicha aplicaci´ on se trata de un software que permitir´a aplicar un control de acceso sobre otras aplicaciones con un factor de protecci´on adicional respecto a otras aplicaciones similares en el mercado. El funcionamiento consistir´ a en sobreponer una aplicaci´on, la cual pide un PIN de desbloqueo, encima de la aplicaci´ on a proteger. Cuando el usuario introduzca correctamente el PIN solicitado, tendr´ a un acceso aparente a la aplicaci´on protegida. Es decir, creer´ a que est´ a interactuando con dicha aplicaci´on pero en realidad lo estar´a haciendo con una aplicaci´ on transparente que est´ a a la escucha de los taps que hace el usuario en la pantalla. Dichos taps han sido establecidos inicialmente por el usuario y act´ uan como segundo factor de autenticaci´ on. A modo de ejemplo clarificador se expone la siguiente situaci´on: Un usuario A decide proteger la aplicaci´on 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´ a observando el momento en el que se introduce el PIN. El usuario A, una vez ha desbloqueado aparentemente Whatsapp, realizar´a un conjunto de taps en las posiciones de la pantalla que s´olo ´el sabe teniendo como imagen est´ atica de fondo la interfaz gr´afica de Whatsapp. El usuario B (considerando la situaci´on 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´on y le muestra de nuevo la pantalla de bloqueo. El objetivo de esta aplicaci´ on es paliar el efecto de una conocida t´ecnica de ingenier´ıa social llamada Shoulder Surfing, la cual, tal y como se ha comentado anteriormente, consiste en t´ecnicas de observaci´on directa de un dispositivo con la finalidad de sustraer informaci´ on 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´on en la pantalla en el momento de introducir el PIN. Su visi´ on debe centrarse en las teclas que tiene que pulsar y en consecuencia no puede prestar atenci´ on a posibles observadores que est´an a su alrededor. La aplicaci´ on que se expone en este proyecto permite que un usuario introduzca los taps invisibles sin necesidad de mirar el dispositivo m´ovil. Por tanto, puede girar el tel´efono hacia abajo o levantar la cabeza y observar si hay alguien pendiente cerca suyo. La precisi´ on no es un elemento que juegue en contra del usuario, ya que ´este puede graduar el margen de error aceptable para considerar que el tap est´a 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´acticas en una empresa relacionada con la tem´atica 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´ on de los activos digitales de mayor valor y cr´ıticos en las organizaciones: la informaci´ on, las operaciones y la imagen de la compa˜ n´ıa. Cuenta con m´ as de 16 a˜ nos 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´ on de empresas e instituciones. 3.3. Estado actual Este trabajo no forma parte de ning´ un otro proyecto, parte desde cero y cuenta con la personalizaci´ on 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´ametros de configuraci´ on como la ubicaci´on GPS, el uso de datos, etc., y otras se limitan a proteger s´ olo aplicaciones. 1 http:www.s21sec.com 11 3 Pliegue de condiciones La idea de la aplicaci´ on surge debido al factor com´ un que comparte un gran n´ umero 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´as eficiencia algor´ıtmica que haya sido programada finalmente depender´a en u ´ltima instancia de la discreci´on del usuario. Por este motivo, se decide mejorar este tipo de aplicaciones, para que el usuario pueda prevenirse de aquellas personas que est´an ojo avizor cuando se expone p´ ublicamente. 3.4. Dise˜ no arquitect´ onico e Implementaci´ on La arquitectura de la parte pr´actica del proyecto constar´a de un conjunto de clases, programadas en Java y XML, que ser´an las que conformen la aplicaci´on que funcionar´ a sobre el sistema operativo Android. La principal herramienta software que servir´a para llevar a cabo todas las tareas de pro´ gramaci´ on es Android Studio. Esta consiste en un entorno adaptado para proporcionar facilidades a los programadores de aplicaciones Android. Por otro lado, el hardware sobre el cual se realizar´a la implementaci´on del proyecto consiste en un port´ atil y un dispositivo m´ovil. 3.5. Gesti´ on 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´on del mismo. Al tratarse de una aplicaci´ on para Android no existen riesgos derivados del uso de licencias debido a que la programaci´on para dicha plataforma es de libre acceso. Por otro lado, el uso de est´ andares por parte de Android erradica cualquier situaci´on de incompatibilidad con los protocolos existentes. No obstante, al tratarse de un sistema muy fraccionado, es decir, existen m´ ultiples versiones de ´este, 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´ on que se proporciona desde fuentes oficiales as´ı como la ayuda que se puede encontrar en comunidades tecnol´ogicas. 3.6. Competencias t´ ecnicas de la especialidad Este proyecto pertenece a la especialidad de Tecnolog´ıas de la Informaci´on y las competencias t´ecnicas elegidas en el momento de la inscripci´on del TFG fueron las siguientes: CTI2.2: Administrar y mantener aplicaciones, sistemas inform´aticos y redes de computadores. CTI2.3: Demostrar comprensi´on, aplicar y gestionar la garant´ıa y la seguridad de los sistemas inform´ aticos. CTI3.1: Concebir sistemas, aplicaciones y servicios basados en tecnolog´ıas de red, teniendo en cuenta Internet, web, multimedia, servicios interactivos y computaci´ on ubicua. CTI4: Utilizar metodolog´ıas centradas en el usuario i la organizaci´on para el desarrollo, la evaluaci´ on y la gesti´on de aplicaciones y sistemas basados en tecnolog´ıas de la informaci´ on que aseguren la accesibilidad, ergonom´ıa y la usabilidad de los sistemas. La descripci´ on 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´on 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´on 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´on, 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´en pueden considerarse sensibles, hace que en combinaci´ on con el de Internet supongan un escenario que muy posiblemente no ser´ıa aceptado por un usuario. Por tanto, para facilitar la aceptaci´on y distribuci´on de esta aplicaci´ on se ha optado por prescindir de conexi´on con el exterior. 13 4. Planificaci´ on temporal 4.1. Planificaci´ on estimada del proyecto La realizaci´ on de este proyecto tiene una duraci´on estimada de cinco meses, con fecha de inicio el d´ıa 11 de enero de 2016 y de finalizaci´on el 10 de junio de 2016. A lo largo de estos cinco meses, las horas de dedicaci´on diarias fluctuar´an en funci´on 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´ on de las tareas A continuaci´ on, se detallar´ an cronol´ogicamente las tareas realizadas en este proyecto: 1. Primeros pasos: la primera tarea a realizar es la b´ usqueda de informaci´on, la cual se lleva a cabo mediante la lectura y comprensi´on 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´ on. Todo este proceso requiere una dedicaci´on aproximada de 3 semanas y media. 2. Gesti´ on del proyecto: las tareas que se desarrollan en la asignatura de Gesti´ on de Proyectos est´ an acotadas temporalmente por unos plazos preestablecidos. Mediante dichas tareas se define el alcance y contexto del proyecto, se realiza una estimaci´ on temporal de su duraci´on y se estudia el impacto econ´omico y su sostenibilidad. La duraci´ on total de estas tareas es de 6 semanas. 3. Recopilaci´ on y redacci´ on: se lleva a cabo una selecci´on e integraci´on de la informaci´ on m´ as pertinente para una posterior redacci´on personalizada del contenido. Debido a la cantidad de fuentes que se han consultado y contrastado se necesitan m´ as de 7 semanas para poder concluir esta tarea. 14 4 Planificaci´on temporal 4. Desarrollo de la aplicaci´ on: para ello es necesario un proceso de aprendizaje aut´ onomo sobre la programaci´on en Android. Paralelamente se trabaja sobre el dise˜ no que tendr´ a la aplicaci´on y se empiezan a implementar algunas funcionalidades. Este proceso de implementaci´on junto con su posterior redacci´on es el m´ as extenso y se realiza a lo largo de m´as de 11 semanas. 5. Etapa final: para concluir el trabajo es necesaria una u ´ltima revisi´on del contenido del mismo. Adem´ as, se realiza la preparaci´on 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´ on se muestra una tabla que especifica cada tarea junto con su tiempo requerido. Posteriormente, dicha tabla se presenta gr´aficamente en el diagrama de Gantt. Figura 4.1: Datos del diagrama de Gantt 15 4 Planificaci´on temporal Figura 4.2: Diagrama de Gantt 16 4 Planificaci´on temporal 4.4. Recursos A continuaci´ on, se enumeran los recursos utilizados a lo largo del proyecto: Hardware: − Ordenador port´ atil 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´on Android Studio. 4.5. Valoraci´ on de alternativas y plan de acci´ on La planificaci´ on temporal mostrada anteriormente ha sido dise˜ nada teniendo en cuenta la carga lectiva y laboral que acompa˜ na en paralelo al trabajo final de grado. Por este motivo se han solapado algunas tareas y se ha alargado la duraci´on de alguna de ellas. No obstante, a´ un y habiendo adoptado estas medidas preventivas, es necesario identificar los principales obst´ aculos que podr´ıan causar una desviaci´on en la ruta fijada por ´ el diagrama de Gantt. Estos son mi grado de desconocimiento en ciertos ´ambitos de los sistemas Android y la correcta compaginaci´on 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´ a suficiente para solventar los imprevistos m´as susceptibles de ocurrir; ya que la jornada puede aumentarse a 15 horas diarias o las necesarias. Estos imprevistos est´ an vinculados con la parte pr´actica de la aplicaci´on. 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´on del mismo se descartar´ a la implementaci´ on 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´ a el target para que la aplicaci´on funcione a la perfecci´on en un n´ umero determinado de versiones. 17 5. Fundamentos te´ oricos 5.1. Sistemas Android Android fue fundado por Android Inc. en 2003 y adquirido por Google en 2005 [20]. Tres a˜ nos despu´es, a finales de 2008, ver´ıa la luz la primera versi´on oficial de este sistema, el cual tuvo una gran acogida por parte de usuarios y desarrolladores. Su r´apida expansi´ on provoc´ o que sus competidores m´as cercanos, iOS y Windows Phone, se repartieran una menor parte del mercado y que sistemas operativos como BlackBerry y Symbian pr´ acticamente dejasen de ser utilizados. Esta superioridad tambi´en es notable en la tienda de aplicaciones Google Play Store, la cual cuenta con m´as 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´ as popular para smartphones y tablets con m´as 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´as importantes en el sector m´ ovil. Gran parte de este ´exito se debe al car´acter open source de ´este, 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´ as favorables destaca el uso de lenguajes de programaci´on ampliamente extendidos como son Java y XML. Adem´as, la gu´ıa para los desarrolladores y la documentaci´ on sobre las funcionalidades disponibles es extensa, detallada y dispone de diversos ejemplos de implementaci´on. No obstante, a la par que proporciona ventajas tambi´en genera inconvenientes que afectan a desarrolladores y fabricantes de dispositivos. El m´as significativo hace referencia 18 5 Fundamentos te´oricos a la fragmentaci´ on 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˜ no y desarrollo a la hora de crear un aplicaci´on. Sin embargo, hoy en d´ıa en este sistema son m´as los puntos fuertes que d´ebiles 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´odulo consiste en una agrupaci´on de funcionalidades y servicios afines. Esta organizaci´on permite a desarrolladores y a usuarios trabajar en un nivel de abstracci´ on que no requiere profundos conocimientos del funcionamiento interno y proporciona comodidad para interactuar con el sistema. La interconexi´ on de los distintos m´odulos se produce en forma de servicios que ofrece un m´odulo a otros de niveles superiores y al uso que hace ´este de los de m´odulos inferiores, tal y como se ilustra en la siguiente figura. Figura 5.1: Arquitectura del sistema operativo Android 19 5 Fundamentos te´oricos A continuaci´ on, se analizar´ a cada uno de los cinco m´odulos as´ı como la relaci´on que establecen con sus adyacentes. 5.1.1.1. Kernel El kernel de Linux es el m´ odulo base sobre el cual se asenta todo el software de Android. La versi´ on usada del kernel en los inicios de Android pertenece a la serie 2.6 y ´esta evolucion´ o 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´as, provee acceso al sistema de ficheros, funcionalidades de red, gesti´on de energ´ıa, memoria y procesos. A pesar de que Android est´e basado en Linux, no se considera que sea una distribuci´ on de este u ´ltimo. De hecho, existen diferentes funcionalidades [2] que se han a˜ nadido 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´ ultiples 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´andar para la comunicaci´ on entre procesos (signals, pipes, sockets, memoria compartida, etc.) no eran lo suficientemente flexibles para Android, implement´o su propio m´etodo llamado Binder, el cual se analizar´a en pr´oximas secciones. Gesti´ on de energ´ıa: Google dise˜ n´o un nuevo sistema de gesti´on de energ´ıa para poder dilatar la duraci´ on de la bater´ıa de los dispositivos m´oviles. Para ello, se crearon drivers espec´ıficos que controlan el consumo de componentes hardware, como es el caso de la iluminaci´on de pantalla. 20 5 Fundamentos te´oricos 5.1.1.2. Librer´ıas Este m´ odulo centraliza las librer´ıas que proporcionan servicios al m´odulo Framework de la aplicaci´ on. Estas librer´ıas est´an 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´on de pantalla as´ı como tambi´en gestionar las ventanas de las aplicaciones. Entre las librer´ıas m´ as representativas de Android se encuentran: Libc: incluye todas las cabeceras y funciones del lenguaje C. SQLite: permite la creaci´on y gesti´on de bases de datos. WebKit: proporciona soporte para aplicaciones de tipo navegador. OpenGL y SGL: sustentan la capacidad gr´afica 2D y 3D de Android. 5.1.1.3. Runtime El tiempo de ejecuci´ on de Android, m´as conocido como Runtime, se divide en dos diferenciadas secciones: las librer´ıas del n´ ucleo (Core Libraries) y la m´aquina virtual Dalvik (Dalvik VM). En cuanto a las librer´ıas del n´ ucleo, proporcionan una interacci´on directa con una instancia de la Dalvik VM. Est´ an escritas, normalmente, en Java y son las encargadas de proporcionar soporte en la manipulaci´on de ficheros, gesti´on de estructuras de datos, etc. Por otro lado, Dalvik es el nombre de la m´aquina virtual que utiliza Android para llevar a cabo la ejecuci´ on de sus aplicaciones. En lugar de hacer uso de la Java Virtual Machine (JVM), Google decidi´ o crear su propia m´aquina virtual optimizada para entornos significativamente m´ as reducidos en cuanto a recursos f´ısicos, es decir, dispositivos m´oviles. Esta optimizaci´ on radica en la forma que tiene Dalvik de generar c´odigo 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´ on de instrucciones necesarias [3]. 21 5 Fundamentos te´oricos En la versi´ on 4.4 de Android se introdujo una nueva m´aquina virtual, ART, para sustituir a la Dalvik. La principal diferencia entre ambas es el orden que establecen para compilar una aplicaci´ on. Mientras que en la Dalvik se realiza la compilaci´on cuando una aplicaci´ on es lanzada por primera vez, en ART este proceso se realiza directamente en el momento de la instalaci´ on de la aplicaci´on y tiene como consecuencia una mayor rapidez de ejecuci´ on. Puesto que la finalidad de esta secci´on es tener una visi´on panor´amica de la arquitectura de Android, con un sondeo t´ecnico, no se entrar´a en detalle en caracter´ısticas internas de estas m´ aquinas virtuales. 5.1.1.4. Framework de la aplicaci´ on El Framework de la aplicaci´ on 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 ´este u ´ltimo pueda utilizar los recursos de Android sin necesidad de integrar complejas funcionalidades por su cuenta. Esta agrupaci´ on de tareas ya programadas que ofrece simples llamadas como medio de interacci´ on, escondiendo la complejidad de trasfondo, se conoce como Application Programming Interface (API). Google, a lo largo de la evoluci´on de Android, ha ido incorporando nuevas APIs a su sistema. A fin de mantener un hist´orico y tener organizadas las APIs seg´ un su aparici´ on se agruparon por niveles, los cuales a principios de 2016 forman un total de 23. El primer nivel de API apareci´o en 2008 con la versi´on 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´etodos que permiten la gesti´ on del ciclo de vida de las aplicaciones, as´ı como conocer el estado de los recursos del sistema. Adem´ as, permite consultar la memoria usada por un proceso, los servicios del sistema, entre otros. 22 5 Fundamentos te´oricos Content Providers: gestionan la compartici´on 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´as de ser un potente sistema operativo, con complejas funciones, Android incorpora clases vinculadas a la finalidad esencial de un dispositivo m´ ovil; la telefon´ıa (llamadas, mensajes, etc.) View Manager : proporciona un gran n´ umero de elementos para poder construir las interfaces de usuario (GUI) de las aplicaciones. Window Manager : sus funcionalidades permiten la gesti´on de las ventanas, determinar cu´ ales son visibles y c´omo se posicionan en la pantalla. Por otro lado, realiza autom´ aticamente las transiciones y las animaciones de apertura y cierre de una aplicaci´ on, as´ı como tambi´en la rotaci´on de ´estas. Tal y como se ver´ a m´ as adelante, el hecho de tener conocimiento de c´omo y mediante qu´e 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´a vital para poder realizar un ataque y/o una buena defensa. 5.1.1.5. Aplicaciones El m´ odulo superior del software de Android est´a destinado a las aplicaciones, las cuales proporcionan una interfaz gr´ afica a los usuarios para que interact´ uen. Todas tienen la misma estructura y utilizan las APIs y librer´ıas de m´odulos inferiores, permitiendo al programador desconocer los detalles de implementaciones internas. En funci´ on de su origen se distinguen dos tipos de agrupaci´on: 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´oricos Por otro lado, las aplicaciones ajenas al sistema se ejecutan en una Sandbox (Secci´ on 5.2.1.1) individual para aislarlas de otras aplicaciones o de informaci´on sobre la cual el acceso no deber´ıa estar permitido. La peligrosidad de ´estas, aunque hayan sido descargadas de la tienda de Google, es que pueden incorporar c´odigo malicioso que se salte todo tipo de control y pueda comprometer el dispositivo, tal y como se ver´a en pr´oximas secciones. 5.1.2. Arquitectura de una aplicaci´ on Las aplicaciones son la pieza clave del sistema operativo Android y las que lo dotan de todo su potencial. El desarrollo de ´estas se realiza principalmente mediante dos lenguajes; Java para gestionar la parte funcional (aunque tambi´en podr´ıan emplearse otros lenguajes como C/C++) y XML para tratar la parte visual, es decir, los componentes de la interfaz gr´ afica. Toda aplicaci´ on 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´on segura de una aplicaci´ on. Ambos conceptos se ven ilustrados en la siguiente figura. Figura 5.2: Arquitectura de una aplicaci´on Como puede observarse, Android crea un proceso donde ejecutar´a una instancia de la m´aquina virtual Dalvik, la cual ser´a el entorno real en el que correr´a una aplicaci´on. 24 5 Fundamentos te´oricos ´ Esta, a su vez crear´ a hilos de ejecuci´on (Threads) para gestionar cada uno de los principales componentes: Actividades, Servicios, Content Providers y Broadcast Receivers. El an´ alisis de los componentes que conforman la estructura de una aplicaci´on se muestra en las siguientes secciones. 5.1.2.1. Android Manifest A pesar de no considerarse un componente como tal, toda aplicaci´on necesita tener un documento XML en el directorio ra´ız llamado AndroidManifest.xml. Este fichero proporciona informaci´ on precisa de los componentes que usar´a la aplicaci´on. Se podr´ıa entender como una declaraci´ on 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´ on es lo que dice ser. Por ejemplo, si se requiere del permiso para acceder a Internet, ´este ser´ a mostrado al usuario en el momento de la instalaci´on para que d´e su conformidad. Si la aplicaci´ on a parte de Internet necesita enviar un mensaje de texto no podr´ a 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´on es llevar a cabo una actividad concreta y normalmente va acompa˜ nada de una interfaz gr´afica mediante la cual el usuario interact´ ua con la aplicaci´on. 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´on 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˜ nadir un adjunto, etc. Un factor que tienen en com´ un 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´ on en todo momento, tal y como se puede observar en la siguiente figura. 25 5 Fundamentos te´oricos 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´on 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´a al estado onStart() pasando previamente por onRestart(). 26 5 Fundamentos te´oricos 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´ omo se comportar´a la aplicaci´on en todo momento. Esto se experimentar´ a m´ as adelante. 5.1.2.3. Servicios Un servicio es un componente dise˜ nado para realizar tareas en un segundo plano sin la necesidad de proporcionar una interfaz gr´afica al usuario. Los servicios son usados con frecuencia para gestionar operaciones que requieren de un largo tiempo de ejecuci´on, como por ejemplo la descarga de un fichero, sin cortar la interacci´on del usuario con la aplicaci´ on. A diferencia de los servicios del sistema, los cuales siempre est´an ejecut´andose, los servicios de las aplicaciones se inician y se paran bajo demanda de la aplicaci´on o bien por ´ la intervenci´ on del usuario. Estos 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´on del servicio, ya que la desconexi´ on de todos y cada uno de ellos provocar´a la destrucci´on del servicio. Por otro lado, los servicios desenlazados (Unbounded services) se crean mediante la funci´on startService() y se ejecutan indefinidamente hasta que se auto-destruyen o bien son parados por los usuarios. Su ejecuci´on es independiente de la del componente que los ha iniciado debido a que la destrucci´on de este u ´ltimo no implicar´ıa una parada del servicio. En la siguiente figura se muestra gr´aficamente el ciclo de vida de un servicio enlazado (derecha) y uno desenlazado (izquierda). 27 5 Fundamentos te´oricos 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´ on de una aplicaci´ on. En concreto, permiten almacenar, recuperar, actualizar y compartir los datos de una aplicaci´ on mediante el uso de un conjunto de m´etodos. 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´on o a un subconjunto de ´esta. Dicho acceso puede realizarse tanto desde actividades como servicios. 28 5 Fundamentos te´oricos Figura 5.5: Funcionamiento de los Content Providers 5.1.2.5. Broadcast recievers Un aspecto caracter´ıstico del dise˜ no del sistema operativo Android es que cualquier aplicaci´on puede lanzar un componente perteneciente a otra aplicaci´on. Por ejemplo, si un usuario quiere hacer uso de la c´amara del dispositivo m´ovil dentro de una aplicaci´on, en lugar de que ´esta incorpore una Activity con todo el c´odigo necesario para hacer una fotograf´ıa, lo que se hace es invocar a una aplicaci´on 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´on en un proceso diferente, no existe una comunicaci´ on directa con las otras aplicaciones. Por ello, para hacer uso de la c´amara, la aplicaci´ on deber´ a comunic´ arselo al sistema y ´este se encargar´a de escoger la aplicaci´on disponible para dicha tarea. Concretamente, el sistema difundir´a este evento y la aplicaci´ on que est´e a la espera de tal evento responder´a ofreciendo sus funcionalidades. Esta predisposici´ on de las aplicaciones a reaccionar ante eventos se implementa mediante el uso de Broadcast Receivers. Este componente principal de una aplicaci´on Android no precisa de interfaz gr´ afica 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´oricos 5.2. Seguridad en Android En esta secci´ on se analizar´ an los principales mecanismos que implementa Google para ´ securizar Android. Estos conforman el llamado modelo de seguridad de Android, en el cual se establece el conjunto de medidas necesarias para proteger las zonas m´as 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´an 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´as 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´ on implementadas de serie en cada versi´on de este sistema. A continuaci´on, se detallar´ an los aspectos m´ as 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´ aquina virtual Dalvik con el fin de ejecutar una aplicaci´on. Este entorno creado para cada aplicaci´on, conocido como Sandbox [6], tiene como finalidad proporcionar aislamiento entre aplicaciones. Como resultado, una aplicaci´on no puede acceder a datos ni c´ odigo de otras. Este aislamiento se complementa con el sistema de seguridad que Android adopt´o de Linux; los identificadores u ´nicos. Cada aplicaci´on, en el momento de su instalaci´on recibe un identificador u ´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˜ no es proporcionar un entorno estable, seguro y reducido para que el impacto de la ejecuci´ on de una aplicaci´on 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´on a otras aplicaciones. 30 5 Fundamentos te´oricos 5.2.1.2. Gesti´ on de permisos Debido a que las aplicaciones se ejecutan en una Sandbox, y por tanto s´olo 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´ as avanzadas. De esta necesidad surgieron los derechos de acceso, conocidos como permisos. El pilar sobre el cual se sustenta la seguridad de una aplicaci´on 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´amara, etc. Por defecto, una aplicaci´on no tiene ning´ un permiso asociado que permita realizar acciones perjudiciales al usuario o a los datos del sistema. Es por eso que, para dotar a una aplicaci´on de funcionalidades m´as complejas, los desarrolladores necesitan declarar los permisos m´ınimamente necesarios en el fichero AndroidManifest.xml. En el momento de la instalaci´ on, Android consulta este fichero y muestra por pantalla todos y cada uno de los permisos que ser´an concedidos a la aplicaci´on. En cuanto el usuario da su aprobaci´ on, la instalaci´on sigue su curso y se asignan los permisos de manera irrevocable y sin la necesidad de una confirmaci´on adicional en el momento de la ejecuci´ on. 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´on expl´ıcita, aunque el usuario siempre tiene la posibilidad de ver cu´ales 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´olo se concede si la aplicaci´on solicitada est´a firmada con el mismo certificado que la aplicaci´on que declara el permiso. SignatureOrSystem: la otorgaci´on de este tipo de permiso sigue la misma norma que el tipo Signature y adem´as se atribuye a aplicaciones del sistema. 31 5 Fundamentos te´oricos 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´ogica [7] debido a que ´estos, en u ´ltima instancia, requieren de la intervenci´on 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´as de cada permiso, o bien requerir el consentimiento del usuario en el momento de la ejecuci´on en lugar de hacerlo u ´nicamente durante la instalaci´ on; permitiendo as´ı una mejor asociaci´on e interpretaci´on 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´es a atacar. Esto es debido a que las t´ecnicas 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´ on de memoria ocurre cuando el contenido de la memoria de una aplicaci´ on es modificado debido a errores de programaci´on. Cuando la aplicaci´on accede a este contenido deja de funcionar. Este hecho puede ser aprovechado por atacantes para inyectar c´odigo en esa regi´ on 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´on existen m´ ultiples t´ecnicas que permiten el desbordamiento del buffer de la memoria (Buffer Overflow). En cada versi´ on de Android se han ido a˜ nadiendo diferentes mecanismos de protecci´ on para mitigar los efectos que estas t´ecnicas iban produciendo. Las incorporaciones m´ as destacadas que han tenido lugar desde las primeras versiones de Android son: ProPolice, NX, ASLR [8]. ProPolice se incorpor´ o a partir de la versi´on 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´oricos NX (No eXecute) es un mecanismo incluido a partir de la versi´on 2.3 con el objetivo de prevenir la ejecuci´ on de c´ odigo en memoria (heap y pila). Consiste en un bit que permite marcar ciertas ´ areas de la memoria para que en caso de ser accedidas se impida su ejecuci´ on. ASLR (Address Space Layout Randomization) fue creado en la versi´on 4.0 para paliar los nuevos vectores de ataque de corrupci´on de memoria. Debido a que el ´exito de esta corrupci´ on radica en el conocimiento que tiene el atacante sobre la localizaci´on del ejecutable en la memoria, el ASLR asigna posiciones de memoria de manera aleatoria; impidiendo que el atacante conozca la ubicaci´on 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´on de NX se aplicaron otras t´ecnicas de ataque, como por ejemplo Return-Oriented Programming, que eluden la protecci´ on de NX o heap spraying que evitan el efecto de ASLR. En consecuencia, para garantizar una buena protecci´on de la memoria es necesario usar una combinaci´ on de ambas (NX y ASLR), ya que se complementan mutuamente. 5.2.1.4. Protecci´ on de datos El contenido privado de un usario es el bien m´as preciado y por tanto deben aplicarse medidas de protecci´ on que eviten tener que depositar toda confianza u ´nicamente en el aislamiento que proporciona una Sandbox, ya que ´este no es suficiente, y garanticen la confidencialidad e integridad de los datos. Android proporciona mecanismos para proteger la informaci´on 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´erico, patrones e incluso en los dispositivos m´ as actuales reconocimiento de huella dactilar. No obstante, cuando un atacante tiene acceso f´ısico a un dispositivo, estos m´etodos 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´aficos que pueden aplicarse de una forma c´ omoda y sin requerir altos conocimientos de criptograf´ıa. Este cifrado, aplicado con una configuraci´on correcta, securiza los datos almacenados y las comunicaciones que se realicen con un servidor externo. 33 5 Fundamentos te´oricos Sin embargo, en este u ´ltimo caso, Android facilita a´ un m´as esta tarea debido a que aconseja utilizar el protocolo HTTPS, sin tener que hacer configuraciones extras. Adem´as, en caso de querer establecer un t´ unel, Android recomienda usar la clase HttpsURLConnection o SSLSocket; desalentando al desarrollador a implementar su propio protocolo. No obstante, si ´este se viera forzado a hacerlo, al menos deber´ıa asegurarse de usar un algoritmo criptogr´ afico 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´omoda, tal y como se ver´a m´as adelante. 5.2.1.5. Signatura de c´ odigo Toda aplicaci´ on en Android est´a contenida en un archivo .apk, el cual incluye tanto los ficheros de c´ odigo como otros recursos (im´agenes, audio, etc.). Este .apk debe contener una firma digital en el momento de la instalaci´on, de lo contrario Android denegar´a este proceso impidiendo la ejecuci´ on de la aplicaci´on en el dispositivo. Este rechazo a aplicaciones que no incluyen dicha firma tambi´en se aplica en la pol´ıtica que tiene Google Play (tienda oficial de aplicaciones) a la hora de permitir la publicaci´on de la aplicaci´on. Mediante la signatura de c´ odigo (firma digital) se consigue identificar el autor de una aplicaci´ on as´ı como tambi´en facilitar las actualizaciones que ´esta requiera. Adem´as, permite que dos o m´ as aplicaciones de un mismo desarrollador puedan interactuar con mayor facilidad. Las aplicaciones pueden estar firmadas por una entidad externa o auto-firmadas. En este u ´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´ afico 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´ on entre ellos (Inter-Process Communication). Tal y como se ha mencionado anteriormente, Binder [10] es el mecanismo que usa Android para permitir dicha comunicaci´ on. 34 5 Fundamentos te´oricos Binder surge como una alternativa a otros mecanismos de comunicaci´on empleados en sistemas basados en el kernel de Linux, como son signals, sem´aforos, pipes, etc., aportando funcionalidades adaptadas al sistema Android. La manera en la que Binder gestiona la comunicaci´on entre procesos se observa en la siguiente figura. Figura 5.6: Comunicaci´on 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´etodo transact(), el cual contendr´a 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´on se transmite ´ al driver de Binder en el kernel de Linux. Este a˜ nade informaci´on que permite identificar al proceso A y la env´ıa al B para que ´este 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 ´este 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. Este, a su vez, se cre´ o como alternativa al modelo de seguridad que incorporaban los sistemas Unix. 35 5 Fundamentos te´oricos En Unix, y por extensi´ on en sistemas basados en el kernel de Linux, la pol´ıtica de segu´ ridad se reg´ıa por el Discretionary Access Control (DAC). Este 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´en 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´ on a este problema, se cre´o una nueva extensi´on de seguridad: SELinux (SecurityEnhanced Linux). SELinux incorpora un mecanismo de control de acceso diferente a DAC. En concreto, su pol´ıtica de seguridad est´ a 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´o en el kernel de Linux y Android est´a basado en dicho kernel, ser´ıa l´ ogico pensar que podr´ıa funcionar en este u ´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´o SEAndroid (SecurityEnhanced Android). Una de las principales adaptaciones que se tuvieron que realizar sobre SELinux fue el soporte a la comunicaci´ on entre procesos mediante Binder. Adem´as, se tuvieron que a˜ nadir librer´ıas necesarias como la libselinux para conseguir una completa interacci´on. Por otro lado, un factor interesante de seguridad que se a˜ nadi´o a SEAndroid fue Midd´ leware MAC. Este consiste en un control de acceso a nivel de Framework y, por tanto, separado de la implementaci´ on 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´oricos 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´odigo 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 u ´ltimo responsable de permitir la instalaci´ on de una aplicaci´ on. A parte del impacto que puedan tener la decisiones err´oneas 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 ´estos 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´on para evitar dicha toma de control. Para llevar a cabo una escalada de privilegios existen dos t´ecnicas diferentes: Confused deputy y Colluding. La primera, menos usada, hace referencia a situaciones en las cuales una aplicaci´ on maliciosa emplea m´etodos de enga˜ no, aprovechando vulnerabilidades en funciones que se encargan de importar archivos, para confundir a otras aplicaciones con mayores privilegios. Por otro lado, la segunda t´ecnica consiste en aprovechar la transitividad de permisos entre aplicaciones. Por ejemplo, un desarrollador puede implementar una aplicaci´on 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´on podr´ıa resultar sospechosa y ser detectada, mediante extensiones de seguridad, como potencialmente peligrosa. Por este motivo, aprovechando la facilidad de comunicaci´on 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. Estas pueden esconder sus verdaderas intencionalidades detr´ as de permisos que parecen necesarios para la aplicaci´on y estar obteniendo informaci´ on privada sin el conocimiento del usuario. Este hecho se conoce como fuga de informaci´ on. 37 5 Fundamentos te´oricos Por los motivos anteriormente mencionados, entre otros, se han realizado investigaciones para incorporar nuevos mecanismos de protecci´on 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´on de las extensiones de seguridad m´as populares separadas por la tem´ atica a la que ata˜ nen. Algunas de ellas ser´an analizadas en los siguientes apartados. Figura 5.7: Extensiones de seguridad 5.2.2.1. Kirin Kirin [13] es una extensi´ on de seguridad que tiene como finalidad impedir la instalaci´ on 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´ uen a su libre albedr´ıo. Es aqu´ı donde interviene Kirin, no permitiendo la instalaci´on de aplicaciones con algunos permisos que considera da˜ ninos. Kirin utiliza reglas de seguridad predefinidas para detectar posibles combinaciones peligrosas de permisos en una misma aplicaci´on. 38 5 Fundamentos te´oricos No obstante, s´ olo lleva a cabo este proceso de forma individual, es decir, analiza una aplicaci´ on pero no es capaz de detectar una posible fuga de informaci´on a causa de la combinaci´ on de permisos entre aplicaciones. Algunos ejemplos de reglas representativas son: 1. Una aplicaci´ on no puede tener el permiso SET DEBUG APP 2. Una aplicaci´ on no puede tener el permiso RECORD AUDIO y INTERNET 3. Una aplicaci´ on no puede tener el permiso SEND SMS y WRITE SMS Existe una extensi´ on opcional que, una vez se ha analizado una aplicaci´on, 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´on o no. 5.2.2.2. AdDroid Otra herramienta de protecci´ on de software malicioso (malware) es AdDroid [14]. A diferencia de Kirin, AdDroid se focaliza en un ´ambito concreto: las librer´ıas de publicidad. Cuando una agencia de publicidad quiere dar a conocer su producto a un amplio p´ ublico, la forma m´ as f´ acil de hacerlo es contactar con los desarrolladores de las aplicaciones m´ as ´ descargadas. Estos incorporar´ an en su c´odigo las librer´ıas de publicidad que les ser´ an otorgadas, las cuales proporcionan APIs que permiten la ubicaci´on de dicha publicidad dentro de la aplicaci´ on y gestionan la interacci´on con el usuario cuando pulsa sobre ´esta. El proceso de comunicaci´ on de estas librer´ıas con el exterior queda ilustrado en la siguiente figura: Figura 5.8: Comunicaci´on entre librer´ıas de publicidad y Android 39 5 Fundamentos te´oricos Tal y como puede observarse, las librer´ıas de publicidad se comunican con la aplicaci´ on y ´esta 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´an de los mismos privilegios que tenga la aplicaci´on. Esto se produce debido a que Android es incapaz de diferenciar qu´e componente de la aplicaci´on es el que realiza la petici´on, 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´ on de librer´ıas de publicidad, se crearon diversas herramientas, entre las cuales destaca AdDroid. Esta extensi´ on de seguridad establece los permisos necesarios m´ınimos para que una aplicaci´ on 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´ on con la publicidad y aportar abstracci´on a este proceso entre la aplicaci´ on y la agencia, como se muestra en la figura 5.9. Figura 5.9: Comunicaci´ on entre librer´ıas de publicidad y Android usando AdDroid 40 5 Fundamentos te´oricos 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´ a XManDroid [15], el cual protege ante situaciones que conducen a una escalada de privilegios, ya sea mediante la t´ecnica de Colluding o Confused deputy. XManDroid (eXtended Monitoring on Android) es una extensi´on de seguridad que se encarga de monitorizar y analizar, en tiempo de ejecuci´on, 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´ on 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´ on de aplicaciones maliciosas, pero en lugar de hacerlo de forma individual act´ ua sobre la interacci´on 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´ on que tiene permiso para leer SMS del usuario no puede comunicarse con otra aplicaci´ on que pueda conectarse a Internet. 2. Una aplicaci´ on que reaccione ante una llamada entrante y tenga el permiso de grabar audio no puede comunicarse con una aplicaci´on que pueda conectarse a Internet. 3. Una aplicaci´ on que puede obtener la informaci´on de localizaci´on no puede comunicarse con una aplicaci´ on que pueda conectarse a Internet. 41 5 Fundamentos te´oricos 5.2.2.4. ASF Debido a que la escalada de privilegios puede darse en los diferentes m´odulos (niveles) que componen el sistema operativo Android, diversas extensiones de seguridad se crearon para ofrecer una protecci´ on multinivel. Una de ellas es la ya mencionada SEAndroid, la cual fue incorporada posteriormente como protecci´on nativa del sistema. A parte de SEAndroid, una importante contribuci´on en la securizaci´on de Android es la extensi´ on ASF [18] (Android Security Framework). Actualmente, las soluciones de seguridad creadas para reforzar la insuficiente protecci´ on 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´odulo 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´on de las extensiones, la dificultad que supone un correcto mantenimiento y actualizaci´on, etc. Debido a este contexto se cre´ o ASF, el cual se propone como la soluci´on que permite integrar, tanto a nivel de kernel como de aplicaci´on, cualquier extensi´on de seguridad ofreciendo, por un lado, una completa adaptaci´on y compatibilidad con el sistema y dem´as 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´ on. 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´on puede realizar llamadas a sistema para comunicarse con el kernel a fin de poder acceder, por ejemplo, a la SDCard. Para ello, har´ a uso de un conjunto de APIs que, despu´es de pasar los controles de acceso DAC y MAC, tramitar´ a la petici´ on del usuario. Por otro lado, una aplicaci´on puede hacer uso del mecanismo de comunicaci´ on entre procesos (Binder) para acceder a los servicios del sistema que est´en dentro de su alcance. 42 5 Fundamentos te´oricos 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´ odulos, 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´ odulo sobre el cual act´ uan. Dichas funciones tienen comunicaci´on entre ellas para garantizar un flujo de seguridad ininterrumpido. Por otro lado, los m´odulos 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´oricos 5.2.2.5. TaintDroid Las extensiones de seguridad descritas hasta el momento est´an 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´ on. Por este motivo se desarrollaron herramientas como TaintDroid [15]. TaintDroid se propone como soluci´on 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´ alisis que realiza TaintDroid de m´ ultiples recursos, potencialmente sensibles, simult´ aneamente es en tiempo real para proporcionar un feedback instant´aneo al usuario. De este modo, ´este u ´ltimo ser´ a consciente del uso concreto, y posiblemente malicioso o poco l´ıcito, que est´ a haciendo una aplicaci´on sobre un recurso determinado. Esto es posible gracias al sistema de etiquetado de recursos de TaintDroid, el cual permite hacer un seguimiento a trav´es de los distintos m´odulos 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´olo rastrea y registra movimientos de ficheros sino que tambi´en permite etiquetar m´etodos que hacen uso de librer´ıas, variables de programaci´on (int, float, etc.) y mensajes transmitidos a trav´es de Binder. Un estudio [19] realizado con TaintDroid sobre las aplicaciones m´as descargadas de Google Play revel´ o que dos terceras partes de ´estas hacen un uso inapropiado de recursos del usuario y sistema mediante el uso de permisos aparentemente inofensivos. 44 5 Fundamentos te´oricos Por ejemplo, se detect´ o que en m´ ultiples aplicaciones se enviaba el identificador u ´nico del dispositivo y n´ umero de tel´efono a un servidor externo. 5.3. Inseguridad de la informaci´ on Hoy en d´ıa, el avance tecnol´ ogico ha conseguido facilitar de tal modo la vida de las personas que pr´ acticamente no se contempla seguir usando m´etodos rudimentarios del pasado. Las potentes funcionalidades de los nuevos dispositivos que han salido al salido al mercado en esta u ´ltima d´ecada han cambiado la forma en la cual las personas organizan su tiempo, sus actividades y su informaci´on. Estos dispositivos, a diferencia de los ordenadores convencionales, tienen la caracter´ıstica de ser ligeros y ofrecer c´ omodas prestaciones para un uso diario y continuado. Cada vez m´as disponen de mayor capacidad para almacenar gran cantidad de contenido multimedia, documentos de texto y en general cualquier informaci´on que se pueda representar en bytes. Los cibercriminales son conscientes de este auge tecnol´ogico y en consecuencia se han modernizado adaptando su forma de actuar. Mediante el uso de las nuevas tecnolog´ıas es posible obtener informaci´ on de los usuarios de un sistema sin que apenas lleguen a saberlo. Dicha informaci´ on engloba todo tipo de contenido sensible que puede ser almacenado en un smartphone, tablet, port´atil, etc. Android se ha convertido en un extendido sistema operativo m´ovil y este hecho no ha pasado desapercibido para los cibercriminales, los cuales han invertido en conocimiento para poder actuar con ´exito sobre dicha plataforma. Utilizan multitud de m´etodos distintos que de forma gen´erica pueden agruparse en ataques a la tecnolog´ıa y ataques a los usuarios. A menudo es necesario una combinaci´on 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´etodo puede ser bastante efectivo contra aquellos usuarios que dispongan de una versi´on 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´ebiles, lo cual le permitir´ıa interceptar el tr´afico (Man in the middle). 45 5 Fundamentos te´oricos Esta tarea ser´ıa m´ as exitosa a´ un si el usuario interact´ ua con aplicaciones que env´ıen las credenciales en texto plano, es decir, sin cifrar. Otros ataques m´ as 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´ecnicos para desarrollarlo. Si los m´etodos anteriores, entre otros posibles no mencionados, no permitieran la substracci´ on de la informaci´ on deseada se deber´ıan buscar opciones alternativas que requieran la colaboraci´ on (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´ecnicas para llevarlos a cabo se conoce como ingenier´ıa social, la cual se detalla en la siguiente secci´on debido a su alta implicaci´ on con la finalidad del proyecto. Una vez aplicada con ´exito sobre el usuario, los atacantes ya han conseguido evadir la restricci´on de acceso que les imped´ıa absoluta libertad y pueden hacer uso de malware que permita robar informaci´on, espiar comunicaciones, mantener conexi´on constante entre v´ıctima y atacante, propagarse a fin de infectar otros contactos, cifrar los datos del usuario para una posterior extorsi´on, destruir el sistema de ficheros, etc. Debido a la inmensidad de t´ecnicas existentes contra sistemas y usuarios, as´ı como tambi´en el amplio abanico de software malicioso que puede ser usado, el foco de este proyecto se ha fijado en proporcionar una implementaci´on pr´actica que proporcione protecci´ on 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´ecnicas que se basan, de forma gen´erica, en la manipulaci´ on y enga˜ no de las personas con la finalidad de evadir los sistemas de seguridad y obtener informaci´ on sensible y confidencial. 46 5 Fundamentos te´oricos 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´on en la cual trabajen. Por otro lado, la ingenier´ıa social tambi´en incluye m´etodos en los cuales no se requiere de la interacci´ on con el usuario para obtener la informaci´on deseada, lo cual hace que la substracci´ on de datos sea sigilosa e inadvertida ante ´este. El ´exito de todas estas t´ecnicas no radica en los avanzados conocimientos t´ecnicos del atacante sino en sus habilidades sociales para ganarse la confianza de los usuarios de un sistema sin que ´estos sospechen de sus verdaderos prop´ositos. A menudo se recurre a la ingenier´ıa social cuando otros tipos de ataques, de car´acter t´ecnico, no consiguen vulnerar el sistema atacado o bien obtener la informaci´on necesaria para hacerlo. Por m´ as que los desarrolladores de software optimicen sus sistemas y solucionen las vulnerabilidades que tienen sus productos, la confidencialidad e integraci´on de los datos sensibles almacenados en ellos depender´a de la administraci´on y gesti´on de los usuarios sobre dicho software. Por este motivo es por el cual las t´ecnicas de ingenier´ıa social cobran gran importancia y fijan su objetivo en el usuario; el eslab´on m´as d´ebil de la cadena. Dos de ´estas t´ecnicas han afectado a un alto porcentaje de usuarios en Android: Drive by download : este m´etodo se basa en la descarga de apps maliciosas de forma autom´ atica cuando el usuario visita una web, la cual puede estar dise˜ nada para tal finalidad o simplemente haber sido v´ıctima de la intrusi´on de un cibercriminal. Estas aplicaciones presentan un nombre inofensivo para enga˜ nar al usuario e incitarlo a abrirlas sin preocupaci´on. 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´ecnica es un cl´asico para enga˜ nar a un usuario independientemente del sistema operativo que est´e usando. No obstante, desde la aparici´on de los nuevos dispositivos m´ oviles se ha incrementado el uso de Phishing. Esta t´ecnica 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 ´exito de enga˜ nar al usuario se incrementa si ´este 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´ on es posible incrustar una web maliciosa sin ni siquiera presentar la URL al usuario, con lo cual ´este puede llegar a confiar en el sitio web simplemente por ver una interfaz gr´ afica id´entica a la de su entidad bancaria. 47 5 Fundamentos te´oricos ´ Estas dos t´ecnicas tan s´ olo son una peque˜ na representaci´on de los distintos vectores de ataque destinados a comprometer la seguridad de Android. A continuaci´on, se comentar´ an con m´ as profundidad dos t´ecnicas incluidas dentro de la ingenier´ıa social que est´an m´ as estrechamente relacionadas con la aplicaci´on que se ha desarrollado en este proyecto. La primera, Shoulder Surfing, es la t´ecnica a la que se quiere neutralizar con la implementaci´ on pr´ actica 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´ecnicas m´as f´aciles de llevar a cabo ya que no requiere tener conocimiento t´ecnico alguno. Como se ha mencionado con anterioridad, este m´etodo consiste en observar, con el mayor grado de disimulo posible, las acciones que est´ a realizando otro usuario con su dispositivo. Hay situaciones en las cuales es inevitable usar un smartphone sin que las personas que est´ an alrededor se percaten de cu´al es el PIN del usuario, patr´on, qu´e comenta por Whatsapp, qu´e imagen abre, etc. Esta proximidad hace que sea mucho m´as f´acil la substracci´ on de informaci´ on, no obstante, desde una cierta lejan´ıa tambi´en es posible predecir d´ onde est´ a 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´omodo decirle a un amigo, compa˜ nero de trabajo, jefe, etc´etera, que desv´ıe moment´aneamente la vista del dispositivo para que no vean la introducci´on de una contrase˜ na o PIN. Entonces suele darse un momento de confianza forzada que conlleva a mostrar informaci´on sensible. Sea cual sea la situaci´ on, el resultado acaba siendo la perdida de privacidad por parte del usuario. A fin de solucionar dicho suceso, el desarrollo pr´actico de este proyecto aportar´ a una medida de protecci´ on adicional que permitir´a mantener la privacidad del usuario e impedir´ a que el simple hecho de mirar disimuladamente el dispositivo de otro usuario sea una tarea totalmente exitosa. 48 5 Fundamentos te´oricos 5.3.1.2. Tapjacking Otra t´ecnica usada para enga˜ nar al usuario y obtener informaci´on de ´este es Tapjacking. A diferencia del Shoulder Surfing, esta t´ecnica requiere de la interacci´on del usuario para que se realice correctamente. Su funcionamiento consiste en mostrar al usuario una interfaz que parezca una aplicaci´ on interactiva pero en realidad no es m´as que una ventana que deja pasar los taps a trav´es de ella permitiendo que el usuario est´e 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´ on sobre el supuesto globo, el usuario inconscientemente puede estar seleccionando opciones de configuraci´on que puedan comprometer su seguridad, como por ejemplo habilitar la instalaci´on de aplicaciones procedentes de fuentes no seguras. Figura 5.13: Tapjacking Una variante de esta t´ecnica consiste en sobreponer una pantalla y asignarle la propiedad de invisibilidad. De este modo el usuario ver´a a trav´es de ella pensando que la aplicaci´ on en primer plano con la que est´a interactuando es la que puede ver en pantalla. No obstante, todos los taps que introduzca ser´an recogidos en primer lugar por la pantalla transparente y luego se transferir´an a la pantalla que se encuentra justo detr´as de ´esta. 49 5 Fundamentos te´oricos Este caso se muestra gr´ aficamente en la siguiente figura, donde se observa como las credenciales introducidas en una aplicaci´on 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´ olo es necesario implementar un servicio que est´e 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´odigo, 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). ´ digo 5.1: C´ Co odigo principal para implementar tapjacking 50 5 Fundamentos te´oricos 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 u ´ltimo le atribuye la propiedad de ser transparente al usuario (40). No obstante, Google se percat´ o 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´ on se sobrepone. De este modo el usuario podr´a percatarse de que algo fuera de lo normal est´a ocurriendo. 51 6. Desarrollo del proyecto 6.1. Descripci´ on de la aplicaci´ on Tal y como se ha descrito anteriormente, ´esta aplicaci´on tiene como objetivo aportar un grado m´ as de seguridad a los usuarios que requieran de proteger datos sensibles en su dispositivo m´ ovil. Para ello, la aplicaci´ on cuenta con una interfaz que proporciona al usuario un conjunto de funcionalidades para personalizar la protecci´on 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´on Figura 6.2: Panel Protecci´on Como puede observarse, el dise˜ no ha sido implementado de tal forma que el usuario tenga una visi´ on r´ apida y concisa de qu´e puede hacer con esta aplicaci´on. 52 6 Desarrollo del proyecto Es por eso que se ha optado por dividirla en s´olo dos paneles; el de Configuraci´on, el cual permite gestionar el comportamiento de la aplicaci´on, y el de Protecci´on, que muestra los recursos que pueden ser protegidos. Entrando un poco m´ as en detalle, el panel Configuraci´on proporciona los siguientes cinco ´ıtems: Estado de la protecci´ on: esta entrada permite iniciar y detener la protecci´ on que ofrece la aplicaci´ on. De este modo, cuando el usuario se encuentre en un lugar en el cual crea que est´ a lo suficientemente seguro como para no necesitar ning´ un bloqueo podr´ a desactivar dicha protecci´on con tan s´olo dos taps; sin necesidad de navegar a trav´es de m´ ultiples men´ us. Adem´as, tendr´a la opci´on de hacerlo durante un tiempo determinado (30min, 1h, 4h, 8h o hasta pr´oximo reinicio), lo cual har´ a que se reactive la protecci´on pasado ese tiempo sin necesidad de volver al panel Configuraci´ on. Establecer PIN: este ´ıtem permite configurar el PIN que proteger´a a las aplicaciones que haya elegido el usuario cuando ´estas sean lanzadas. El bloqueo con PIN es el primer factor que debe afrontar el usuario para entrar a una aplicaci´ on restringida. Establecer taps invisibles: esta opci´on es la pieza angular de la aplicaci´on. Proporciona al usuario la posibilidad de a˜ nadir un segundo factor de autenticaci´ on una vez ha introducido correctamente el PIN. Para ello le permite establecer el n´ umero de taps y la posici´on de ´estos en la pantalla. Este segundo factor tambi´en se puede deshabilitar y dejar s´olo el bloqueo con PIN por defecto. Entrenamiento: esta entrada proporciona al usuario un lugar en el cual practicar su precisi´ on para acertar sus taps. Esta funcionalidad se ha implementado porque una vez se configura el patr´on con dichos taps; los cuales son mostrados por pantalla al usuario, ya no los volver´a a ver debido a que la pantalla transparente que los recoge no muestra informaci´on sobre la posici´on pulsada. Historial: en esta opci´ on se mostrar´a al usuario el listado de aplicaciones protegidas junto con el n´ umero de aciertos y fallos que se han realizado para cada una de ellas. Adem´ as, la fecha y hora del u ´ltimo acceso tambi´en quedar´an reflejadas. De este modo el usuario podr´a saber si se ha realizado alg´ un intento de espionaje sobre su dispositivo durante el tiempo que se ha ausentado de ´este. 53 6 Desarrollo del proyecto En cuanto al panel Protecci´ on, como puede observarse en la figura anterior, hay cuatro tipos de recursos que pueden ser protegidos con la aplicaci´on. El recurso principal, para el cual ha sido dise˜ nada esta app, es el conjunto de aplicaciones que hay en sistema. Complementariamente se han a˜ nadido el conjunto de im´agenes, v´ıdeos y archivos del usuario en el dispositivo. La protecci´ on de ´estos tres u ´ltimos funciona diferente a la protecci´on de aplicaciones debido a razones t´ecnicas que se explicar´an m´as adelante. 6.2. Procedimiento El funcionamiento principal de la aplicaci´on se realiza en un segundo plano, es decir, sin necesidad de interactuar con la interfaz gr´afica. Esto se consigue mediante el uso de un servicio que est´ a 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´on se despertara para actuar. Sin embargo, cuando una aplicaci´on se lanza, el sistema no env´ıa informaci´on 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´etodo de espera activa. Este consiste en consultar repetidamente si ha ocurrido tal evento en lugar de esperar un aviso por parte de ´este. La contrapartida de este m´etodo es el consumo de bater´ıa, pero actualmente es la u ´nica opci´ on que ofrece Android. Una vez detectada la aplicaci´ on, el siguiente paso ser´ıa guardar el nombre de ´esta, impedir que se abra, lanzar la aplicaci´on de bloqueo y en caso de que se introdujese correctamente el PIN volver a lanzar la aplicaci´on protegida sin pedir esta vez el PIN. No obstante, una aplicaci´ on no puede detener a otra a no ser que tenga el permiso de root y el dispositivo est´e rooteado. S´olo est´a permitido detener activities que compartan el mismo UID, es decir, dentro de una misma aplicaci´on. 54 6 Desarrollo del proyecto Esto obliga a aceptar que dicha aplicaci´on se abrir´a 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´on dif´ıcil de controlar. Esta se produce entre el lanzamiento de la aplicaci´on a proteger y la espera activa del servicio que consulta si debe o no activar la protecci´on. Por ejemplo, si el servicio comprueba cada dos segundos cu´ al es la aplicaci´ on que est´a en primer plano y justo despu´es el usuario lanza la que se tiene que proteger, el tiempo hasta que el servicio vuelva a hacer la consulta ser´a tiempo en el cual se previsualizar´a 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´on con bloqueo, el siguiente paso es recoger el PIN introducido y validar el acceso. En caso de que sea correcto, el servicio comprobar´a si el usuario habilit´ o el segundo factor de autenticaci´on y en caso afirmativo lanzar´a una ´ pantalla transparente. Esta se encargar´a de recoger los taps que introduzca el usuario y comprobar que lo haya hecho en la posici´on correcta (con un margen de error tambi´en elegido por el usuario). Si este proceso lo realiza satisfactoriamente, la pantalla transparente desaparecer´a como si nada hubiera pasado, es decir, no mostrar´a ning´ un mensaje de acierto al usuario y le permitir´ a interactuar con la aplicaci´on protegida. En caso contrario, el servicio volver´ a a lanzar la pantalla de bloqueo con PIN simulando un comportamiento inesperado de la aplicaci´ on pero sin informar de la existencia de un segundo factor invisible que ha sido fallido. Todo este procedimiento tiene como finalidad proteger con discreci´on, de tal modo que un observador no reciba ning´ un tipo de informaci´on sobre lo que realmente est´a ocurriendo. 6.3. Diagrama de flujo En esta secci´ on se detallar´ a gr´ aficamente, mediante un diagrama de flujo, todo el procedimiento explicado en la secci´ on anterior. Pero antes se mostrar´a 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´ecnicas 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´ on que se quiere proteger ha recibido una petici´on de lanzamiento (A). Entonces, el servicio cierra la aplicaci´on (B) antes de que llegue a mostrarse por pantalla y en su lugar abre la aplicaci´ on de bloqueo (C). El resto del procedimiento (D, E, F, G) corresponde a la validaci´ on 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. Esta 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´on que impide cerrar otras apps, hay una nueva ´ situaci´ on a contemplar que no se da en el diagrama ideal y s´ı en el real. Esta se produce durante la comprobaci´ on del PIN, ya que es un estado en el cual se espera un input por parte del usuario y no realiza ninguna otra acci´on hasta que no se env´ıe dicho PIN a validar. En este punto, un usuario malintencionado puede aprovechar que la aplicaci´on a proteger no ha sido cerrada y retomarla porque todav´ıa est´a en la pila de tareas recientemente abiertas. En la siguiente figura se muestra dicha situaci´on, en la cual la aplicaci´ on 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´on Home de los dispositivos con sistema operativo Android y, como se puede ver, resulta bastante sencillo evadir la protecci´ on que proporciona Double Lock tan s´olo seleccionando la aplicaci´on calculadora en esta lista. Para paliar este bypass se ha introducido otra espera activa que consulta constantemente si el usuario est´ a intentando cambiar de aplicaci´on y en caso afirmativo volver´ıa a lanzar el bloqueo. A continuaci´ on, se muestra la parte del diagrama de flujo que representa tal acci´on. 57 6 Desarrollo del proyecto Figura 6.6: Comprobaci´on de cambio de aplicaci´on En el siguiente diagrama de flujo se puede observar el procedimiento completo que seguir´a el servicio, el cual es resultado de la combinaci´on de las distintas partes mostradas anteriormente. Figura 6.7: Diagrama de flujo final 6.4. Funcionalidades A continuaci´ on, se analizar´ a cada funcionalidad desde la perspectiva de un desarrollador, es decir, se mostrar´ a el c´ odigo y las decisiones tomadas en cada situaci´on. Debido a que la aplicaci´ on consta de 38 clases Java y 36 ficheros XML, haciendo un total aproximado de 10.800 l´ıneas de c´ odigo, se seleccionar´a un extracto representativo de las clases m´ as relevantes. 58 6 Desarrollo del proyecto 6.4.1. Estado de la protecci´ on Tal y como se ha mencionado anteriormente, la aplicaci´on Double Lock cuenta con una funcionalidad que permite el inicio y la detenci´on del servicio que corre en segundo plano. El acceso a ´esta se ha ubicado en la primera entrada del men´ u Configuraci´on a fin de proporcionar comodidad y rapidez al usuario. Por otra parte, se permite deshabilitar la protecci´ on temporalmente haciendo que el usuario no necesite volver a acceder para habilitarla de nuevo. Para ello se proporciona la siguiente interfaz gr´afica al usuario, la cual le permite realizar este proceso con tan s´ olo dos taps. Figura 6.9: Protecci´on deshabilitada Figura 6.8: Opciones disponibles El c´odigo necesario para implementar dicha funcionalidad se muestra en el c´odigo 6.1. Solamente requiere consultar el estado actual (101-102) guardado en el espacio de memoria que dispone cada aplicaci´on, conocido como SharedPreferences, y hacer uso del widget AlertDialog para mostrar las opciones preestablecidas. Una vez el usuario elige la opci´on que quiere, la funci´on pararServicioTemporalmente (113) es llamada con los par´ ametros deseados (30 minutos, 1 hora, 4 horas, 8 horas o hasta reinicio). 59 6 Desarrollo del proyecto ´ digo 6.1: Opciones para deshabilitar la protecci´on Co Cuando dicha funci´ on se ejecuta, lo primero que hace es establecer una alarma (199-201) que levantar´ a de nuevo la protecci´on cuando haya pasado el tiempo elegido (205,209). ´ digo 6.2: Configuraci´on de la alarma Co Finalmente, se para el servicio que est´a en ejecuci´on haciendo uso del m´etodo stopService. Como se observa en el c´ odigo 6.3, en funci´on de la versi´on de Android del dispositivo se ejecutar´ a una funci´ on u otra. Esta decisi´on t´ecnica se explicar´a m´as adelante. ´ digo 6.3: Parada del servicio Co 60 6 Desarrollo del proyecto La configuraci´ on de la alarma, con la elecci´on correcta de sus par´ametros, permite reducir el consumo de bater´ıa debido a que el sistema avisar´a a la aplicaci´on una vez haya transcurrido el tiempo, mediante los broadcast receivers explicados en secciones anteriores, en lugar de ser la aplicaci´on quien pregunte si es el momento indicado o no. La siguiente figura muestra el c´ odigo para levantar el servicio (23-24) cuando salte la alarma. ´ digo 6.4: Ejecuci´on de la alarma Co 6.4.2. Establecer PIN El primer factor de protecci´ on que aparece cuando se lanza una aplicaci´on protegida ´ es el bloqueo mediante PIN. Este se configura en la Activity de la figura 6.10, y los par´ametros que requiere son: el PIN actual, el nuevo PIN, la repetici´on de ´este, y un n´ umero 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˜ no de esta secci´on se opt´o por restablecer el PIN mediante el env´ıo de un email a la cuenta del usuario. No obstante, esta soluci´on requiere del permiso Internet que ofrece Android, y tal y como se ha explicado anteriormente, existen t´ecnicas 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 ´estos del uso de Double Lock se ha descartado usar Internet. En base a este hecho, la aplicaci´on enviar´a en su lugar un SMS al n´ umero de tel´efono que se haya introducido. Ser´ıa preferible que ´este fuera el de una persona de total confianza. Si se optara por poner el mismo n´ umero del dispositivo actual, el SMS se previsualizar´ıa en el mismo y no aportar´ıa ning´ un tipo de protecci´on. Tambi´en se puede elegir la opci´ on 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´on principal (Double Lock) junto con la funcionalidad que restablece el PIN. A diferencia de la ventana de bloqueo anterior, ´esta incorpora un texto clickable por si el usuario olvida su c´odigo. La decisi´ on de ponerlo s´olo en la aplicaci´on 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´ odigo se recogen los par´ametros introducidos por el usuario, se validan (72) y se procede a almacenarlos en SharedPreferences (75,79). No obstante, en esta ocasi´ on se hace uso de una librer´ıa externa (SecurePreferences) para almacenar el PIN cifrado con AES (Advanced Encryption Standard) y reforzar as´ı la protecci´on. ´ digo 6.5: Configuraci´on del PIN Co La funci´ on comprueba() es la encargada de revisar los par´ametros introducidos y devolver error en caso de una mala configuraci´on. La parte relevante a destacar es el uso de la ya mencionada librer´ıa SecurePreferences (97,98), la cual permite trabajar de forma c´omoda y segura con los datos de SharedPreferences. ´ digo 6.6: Uso de SecurePreferences Co 6.4.3. Establecer taps invisibles En este apartado el usuario tendr´a la opci´on de fortalecer su protecci´on mediante la activaci´ on de los taps invisibles. Una vez lo haga se activar´a la otra opci´on que aparece en la figura 6.14, deshabilitada en un principio, y que proporciona una soluci´on para evitar la previsualizaci´ on del contenido durante la introducci´on 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´ a dichos taps. De este modo, una vez se introduce correctamente el PIN, en lugar de previsualizar el contenido de la aplicaci´on protegida se mostrar´a dicha imagen. Es decir, no habr´ a ninguna transparencia y por tanto un observador podr´a identificar que existe otro factor de protecci´ on. 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´on se representa mediante un c´ırculo verde por cada pulsaci´ on. Paralelamente se muestra un cron´ometro que indica el tiempo que tarda el usuario en introducir los taps. Este tiempo ser´a el que esperar´a la Activity transparente antes de comprobar los inputs recibidos. Transcurrido ese tiempo y en caso de haber un acierto inferior al 100 % aparecer´ a de nuevo la ventana de bloqueo impidiendo el acceso a la aplicaci´ on protegida. 64 6 Desarrollo del proyecto Para finalizar el proceso, el usuario deber´a pulsar el bot´on Stop y elegir entre repetirlo de nuevo o bien avanzar y guardar los taps en la memoria de la aplicaci´on. Figura 6.16: Introducci´ on de taps I Figura 6.17: Introducci´on de taps II Tal y como se muestra en las siguientes figuras, el di´ametro puede ser ajustado dependiendo de la precisi´ on de acierto que quiera el usuario. Figura 6.19: Modificaci´on del radio II Figura 6.18: Modificaci´ on del radio I 65 6 Desarrollo del proyecto Al pulsar el bot´ on Siguiente se mostrar´a un mensaje informando del establecimiento correcto de los taps y preguntando al usuario si desea practicarlos o bien volver al men´ u principal. La primera opci´ on se detallar´a en la siguiente secci´on. Figura 6.20: Taps establecidos El c´odigo de todo este proceso involucra diversas clases Java. Por tanto, para no hacer tan ardua la lectura al lector, se mostrar´a la implementaci´on de un n´ umero reducido de funciones; las cuales har´ an de hilo conductor para explicar t´ecnicamente las figuras anteriores. La primera de ellas, como se observa en el c´odigo 6.7, es la encargada de detectar las coordenadas de los diferentes taps. Para ello se hace uso del m´etodo onTouch que proporciona Android, el cual permite de forma c´omoda recoger dichos valores (89,90). Esta informaci´ on se almacena en una clase Punto, creada con anterioridad, junto con el tiempo transcurrido hasta ese momento (98,99). Por otro lado, la representaci´ on gr´afica de estos puntos se hace mediante el m´etodo onDraw y la declaraci´ on de un objeto Canvas. A este u ´ltimo se le aplica un conjunto de propiedades que dar´ an formato a los puntos (48-51) y posteriormente se usa su m´etodo drawCircle (54,58,63) para mostrarlos por pantalla. 66 6 Desarrollo del proyecto ´ digo 6.7: Recogida de taps del usuario Co ´ digo 6.8: Representaci´on gr´afica de los taps Co Una vez haya introducido los taps que desea y quiera seguir adelante deber´a pulsar el bot´on Siguiente. En ´el se implementa el c´odigo necesario para recopilar dichos taps (148), el tiempo total transcurrido (149) y el radio (150) elegido para determinar la zona de acierto v´ alida. Estos valores se almacenan en SharedPreferences (153-157) y acto seguido se invoca a la Activity Finalizar (159,160). 67 6 Desarrollo del proyecto ´ digo 6.9: Almacenamiento de los taps Co 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´on. 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´ on anterior, esta vez no se muestra el bot´on Stop sino que autom´aticamente se cierra la pantalla transparente despu´es del tiempo ya establecido. Acto seguido, se muestra gr´ aficamente las zonas consideradas v´alidas y los resultados num´ericos: n´ umero de taps correctos y tiempo total. Figura 6.23: Visualizaci´ on gr´afica I Figura 6.24: Resultados I Figura 6.25: Visualizaci´ on gr´afica II Figura 6.26: Resultados II 69 6 Desarrollo del proyecto El c´odigo para implementar esta funcionalidad es bastante parecido al mostrado en la secci´ on anterior. No obstante, en esta ocasi´on se debe determinar si los taps marcados en rojo se encuentran dentro de las circunferencias verdes y con su correcto orden de introducci´ on. Para tal finalidad se ha implementado el m´etodo evalua que se aprecia en la siguiente figura. Su primera comprobaci´ on es que el n´ umero 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´ on devuelve True si ha habido un acierto absoluto y el tiempo del u ´ltimo tap se encuentra dentro del tiempo establecido. ´ digo 6.10: Evaluaci´on de los taps introducidos Co 6.4.5. Historial La entrada Historial del men´ u Configuraci´on es la encargada de recopilar la informaci´ on de uso de la aplicaci´ on Double Lock en el sistema. Proporciona un registro para que el ´ usuario tenga los datos concretos sobre el acceso a una aplicaci´on protegida. Este incluye el n´ umero de accesos correctos, fallidos y fecha del u ´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´on lo reflejar´a en el historial; dejando al descubierto dicha vulneraci´ on de la intimidad. Tal y como se observar´ a a continuaci´on, en el historial aparecen las aplicaciones que actualmente est´ an protegidas. Si el usuario desprotege alguna de ´estas, su entrada en el historial desaparecer´ a pero seguir´a conservando sus contadores. 70 6 Desarrollo del proyecto Por otro lado, si decide reiniciar dichos contadores podr´a hacerlo de forma individual pulsando encima de cada aplicaci´on, 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´ odigo se puede observar c´omo se selecciona la plantilla gr´afica (fichero layout asociado) (273) que contiene el aspecto gen´erico que tendr´a cada entrada. ´ digo 6.11: Gesti´on de cada entrada del historial Co 71 6 Desarrollo del proyecto Seguidamente, se trata de manera individual cada ´ıtem recogiendo su nombre e icono (277-280) y asign´ andolos a la posici´on de la interfaz que les corresponde. Finalmente, se instancian los campos que mostrar´an los valores almacenados (283-285) y se llama a la funci´ on openHistId (287) pas´andole el nombre de la aplicaci´on a buscar en la base de datos. Como se aprecia en el c´ odigo 6.12, esta funci´on inicia una conexi´on con la base de datos (336), la cual ha sido creada en otra clase Java, y consulta el m´etodo creado getHistId para obtener y asignar la informaci´on de los accesos a su posici´on concreta dentro la interfaz. ´ digo 6.12: Obtenci´on de valores de la base de datos Co 6.4.6. Protecci´ on de aplicaciones Una vez analizadas las funcionalidades del panel Configuraci´on, a continuaci´on se explicar´an las del panel Protecci´ on. Para empezar se detallar´a la funcionalidad principal de la aplicaci´ on: la protecci´ on de otras aplicaciones. Tal y como se muestra en la siguiente imagen, las aplicaciones instaladas en el sistema se muestran ordenadas alfab´eticamente junto con su icono asociado. Para proteger cualesquiera de ellas, el usuario deber´a pulsar encima de la que desee y podr´a observar un candado verde indicando que esa aplicaci´on se ha marcado a proteger. Para cancelar la protecci´ on bastar´ a 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´on. En ella, el proceso de b´ usqueda de las aplicaciones (130) se ha implementado dentro del m´etodo doInBackground de la clase AsyncTask. ´ Este permite realizar tareas en un segundo plano a la vez que muestra por pantalla, por ejemplo, un mensaje (139), acompa˜ nado de una rueda de progreso, para informar al usuario que se todav´ıa continua el proceso. La decisi´ on de hacerlo en segundo plano se ha tomado debido a que el tiempo que tardaba la aplicaci´ on en listar los resultados de su b´ usqueda oscilaba entre los tres y seis segundos, lo cual daba una primera sensaci´on de no haber encontrado nada o de estar a punto de bloquearse. Esta sensaci´on desaparece al mostrar el mensaje informativo sobre el estado actual dentro del m´etodo onPreExecute. ´ digo 6.13: Realizaci´on de la b´ Co usqueda en segundo plano 73 6 Desarrollo del proyecto El c´odigo anterior realiza una llamada al m´etodo buscaLauncher que se muestra en el c´odigo 6.14, el cual consulta todas las aplicaciones que en su AndroidManifest.xml hay declarada la propiedad Launcher; que permite a una aplicaci´on poder ser lanzada por el usuario. ´ digo 6.14: B´ Co usqueda de aplicaciones en el sistema Cuando se ha pulsado encima de una aplicaci´on con la finalidad de protegerla, esta informaci´ on 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˜ nade la nueva aplicaci´ on a proteger (264-268) y acto seguido se almacena de nuevo esta informaci´ on (270-272). ´ digo 6.15: Guardar aplicaciones protegidas Co 74 6 Desarrollo del proyecto 6.4.7. Protecci´ on de contenido privado Complementariamente a la protecci´on de aplicaciones se ha decidido ofrecer la capacidad al usuario de proteger su contenido privado, entendiendo por ´este im´agenes, v´ıdeos y archivos. La utilizaci´ on del m´etodo de protecci´on 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 ´este evitando el factor de protecci´ on. Por ejemplo, un usuario malintencionado que tuviera acceso moment´ aneo 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´ un inconveniente. Por tanto, para proteger el contenido del usuario se deben buscar otros m´etodos. Uno de ellos podr´ıa consistir en renombrar los archivos poni´endoles 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´es de un explorador de archivos. Otro m´etodo consiste en mover los archivos que se quieren proteger a la memoria interna de la aplicaci´ on de protecci´ on. No obstante, esto s´olo previene el acceso de otras aplicaciones a dicho contenido pero no lo protege del acceso manual mediante un explorador de archivos. Adem´ as, tiene como problema a˜ nadido 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´etodos se ha optado por cifrar directamente el archivo en el mismo lugar donde est´a almacenado en memoria y s´olo poder visualizar el contenido mediante la aplicaci´on Double Lock. De este modo, a pesar de que a trav´es de un explorador se pudiera acceder al material protegido y enviarlo por Internet o Bluetooth, ´este seguir´ıa estando inaccesible. Para cada uno de los tres tipos de contenido se ha creado una interfaz gr´afica 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´agenes presenta tres opciones: descifrar, cifrar y a˜ nadir im´agenes. 75 6 Desarrollo del proyecto Figura 6.31: Selecci´on de im´agenes de la galer´ıa Figura 6.30: Interfaz para proteger im´ agenes Una vez se pulsa el bot´ on verde para cifrarlas ya no podr´an ser mostradas en la pantalla de protecci´ on debido a que no se guarda ninguna miniatura para ofrecer mayor protecci´on. Por este motivo se muestra un candado amarillo en el centro de la pantalla. Figura 6.32: Im´ agenes cifradas Figura 6.33: Desproteger imagen 76 6 Desarrollo del proyecto Cuando el usuario descifra las im´agenes pulsando el bot´on rojo aparecer´an de nuevo las miniaturas de ´estas. Si entonces decide pulsar sobre alguna de ellas se le mostrar´a una ventana emergente que le preguntar´a si la quiere quitar de la lista de im´agenes a proteger. El segundo tipo de contenido que permite cifrar la aplicaci´on son los v´ıdeos. La interfaz gr´afica es la misma que la mostrada en las capturas anteriores, tan s´olo cambia el hecho de que la galer´ıa permitir´ a elegir u ´nicamente v´ıdeos. Finalmente, si el usuario quiere cifrar cualquier tipo de archivo en su dispositivo (documentos de texto, archivos comprimidos, etc.), podr´a hacerlo mediante el ´ıtem Archivos del men´ u Protecci´ on. 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´ on que hay detr´as de estas funcionalidades se mostrar´a a continuaci´ on la parte m´ as representativa del proceso de selecci´on del contenido, cifrado y descifrado. Para la selecci´ on del contenido de la galer´ıa tanto para im´agenes como v´ıdeos es necesario declarar un elemento espec´ıfico en Android al cual se le asocia una acci´on que debe llevarse a cabo. Este elemento se conoce como Intent (464) y necesita en este caso dos par´ametros. El primero es la acci´on requerida (465) y el segundo es el destino donde se realizar´ a tal acci´ on (466). Finalmente, se manda a ejecutar este Intent (467). ´ digo 6.16: Selecci´on de contenido de la galer´ıa Co La respuesta obtenida de la acci´on anterior se recoge en el siguiente c´odigo, donde se observa que se comprueba que el resultado sea correcto y el c´odigo 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). ´ digo 6.17: Contenido guardado para cifrar Co Una vez se ha seleccionado el contenido ya puede ser cifrado. Para ello se llama a la funci´ on encryptFile donde se tratar´a una a una las im´agenes a cifrar. El primer paso es pasar a Bitmap la imagen a partir de su ruta (75). A continuaci´on, se detecta la extensi´ on (77,78) y en funci´ on de un formato u otro se decide la compresi´on a aplicar (82,87). 78 6 Desarrollo del proyecto Debido a que esta compresi´ on de la clase Bitmap s´olo puede aplicarse a im´agenes con extensiones .jpeg y .png se ha a˜ nadido 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´ on y directamente se llama a la funci´on cifrar (96). ´ digo 6.18: Cifrado del contenido I Co En cuanto a la funci´ on cifrar, Google proporciona la clase Cipher para que el desarrollador pueda crear f´ acilmente una instancia de ´esta (129) especificando el algoritmo de cifrado, el modo de operaci´ on y el tipo de padding. A partir de aqu´ı se inicializa el cifrado (131) y se aplica a la imagen (133). ´ digo 6.19: Cifrado del contenido II Co 79 6 Desarrollo del proyecto El proceso de descifrado hace uso de la misma clase Cipher pero en la inicializaci´on esta vez se habilita la opci´ on DECRYPT MODE (151), se descifra el contenido (152) y se crea un buffer de bytes para ir leyendo la imagen descifrada. ´ digo 6.20: Descifrado del contenido Co Finalmente, se llama a otra funci´on que no figura en las capturas y se guarda la imagen en el mismo sitio donde estaba. Tanto para las im´ agenes como v´ıdeos y archivos la clase usada es la ya mencionada Cipher y las implementaciones s´olo se diferencian en peque˜ nas funcionalidades. 6.4.8. Servicio Por u ´ltimo, se describir´ a en esta secci´on el componente que lleva a cabo la protecci´ on con un segundo factor de autenticaci´on. Se trata del servicio que est´a en segundo plano escuchando los eventos que suceden en el dispositivo. Su funcionamiento consiste en consultar constantemente si debe proteger o no la aplicaci´on que hay en primer plano. Para ello primero comprueba si la protecci´on est´ a habilitada (80-82), consulta cu´ al es la aplicaci´on 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 ´ digo 6.21: Consulta de la aplicaci´on en primer plano Co La primera de ellas simplemente se encarga de preparar el entorno para lanzar la interfaz gr´ afica que muestra la pantalla de bloqueo. Por otro lado, la segunda se encarga de estar a la espera de la introducci´on del PIN por parte del usuario con la finalidad de concederle o denegarle el acceso. El c´odigo de esta u ´ltima se muestra en la siguiente figura. ´ digo 6.22: Comprobaci´on del n´ Co umero PIN Como se puede observar, la funci´on 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´on y cu´al es el resultado de ´esta. Por otro lado, tambi´en se comprueba si ha decidido cambiar de aplicaci´ on para evitar que esta funci´on 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´on necesaria al usuario para hacer un uso correcto de la aplicaci´ on se ha elaborado un videotutorial que cubra todas las funcionalidades. De este modo el usuario sabr´a de una forma r´apida y c´omoda c´omo funciona cada una de las partes de la aplicaci´on y el orden l´ogico que debe seguir para configurarla correctamente. Como se aprecia en las siguientes figuras, el videotutorial est´a alamacenado en Youtube y se proporciona la URL para acceder a ´el. Esto se debe a que la aplicaci´on no tiene el permiso de Internet a fin de proporcionar m´as confianza al usuario, tal y como ya se ha mencionado anteriormente. Por otro lado, la posibilidad de incluirlo dentro de la aplicaci´ on se ha descartado por el tama˜ no de almacenaje que requerir´ıa. Figura 6.37: Tutorial Figura 6.38: Link del tutorial 82 7. Gesti´ on econ´ omica 7.1. Consideraciones iniciales En las siguientes secciones se analizar´an 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´an sujetos a la condici´ on de becario del autor del trabajo. No obstante, con la finalidad de dotar los c´alculos de realismo profesional, se ha a˜ nadido la estimaci´ on de costes contemplando el desarrollo del proyecto en un entorno laboral. Por tanto, se considerar´ an dos escenarios: el primero, en adelante Escenario A, contemplar´ a el contexto estudiantil, mientras que el segundo, Escenario B, considerar´a un entorno profesional. 7.2. Identificaci´ on y estimaci´ on de costes El presupuesto necesario para la realizaci´on del proyecto viene determinado por los factores que tienen un impacto econ´omico directo o indirecto en ´el. En consecuencia, el primer paso para la elaboraci´ on 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´an analizados y clasificados seg´ un su intervenci´on. Por otro lado, tambi´en se detallar´ a la partida de contingencia y los imprevistos que se han tenido en cuenta. 83 7 Gesti´on econ´omica 7.2.1. Costes directos En esta secci´ on 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´ omico que interviene en la realizaci´on 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´ on, 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´on econ´omica Por otro lado, los costes asociados al material usado son los siguientes: Amortizaci´ on hardware: el port´atil Fujitsu LifeBook usado durante todo el proyecto se adquiri´ o en 2011 y el dispositivo m´ovil 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 ´el. 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´ on sobre el alquiler, consumo de agua, electricidad, etc., no es de f´acil acceso para un becario. Por tanto, los principales costes que se tendr´an en cuenta son: Transporte: los desplazamientos se han realizado haciendo uso del transporte p´ ublico. El coste asociado es el de dos tarjetas trimestrales de metro. Impresiones en papel: el proyecto se imprimir´a para proporcionar una copia del mismo a cada miembro del tribunal. Si se estima una extensi´on de 90 hojas por copia ser´ an necesarias 270 impresiones. Tabla 7.4: Costes indirectos 85 7 Gesti´on econ´omica 7.2.3. Contingencia Otro aspecto a tener en cuenta en el presupuesto es la partida de contingencia. En este proyecto se destinar´ a a ´esta 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´on temporal se realiz´ o teniendo en cuenta una serie de imprevistos, los cuales tienen sus costes asociados: Retraso de 7 d´ıas: debido a que la parte m´as sensible de sufrir una desviaci´ on temporal es la de programaci´on, el salario necesario para dichas labores se tendr´ a 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´ a totalmente ligada al mundo inform´atico hay una gran disposici´on de equipos de repuesto en caso de aver´ıa, tanto m´oviles como port´atiles. 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´ on de m´ odulos de publicidad en la aplicaci´on, ya que se entiende que es de car´ acter universitario. Por otro lado, no se contempla una subida de salario a lo largo del desarrollo del proyecto. 86 7 Gesti´on econ´omica En la siguiente figura se muestra el presupuesto final para cada uno de los escenarios. Tabla 7.7: Presupuesto 7.3. Control de gesti´ on Con la finalidad de controlar la evoluci´on del proyecto se realizar´a una imputaci´on de horas al final de la semana. De este modo, cada rol registrar´a la dedicaci´on realizada y sabr´ a las horas que dispone para realizar las tareas que tiene asociadas. Mediante este control ser´ a posible detectar si las horas dedicadas a cada tarea sobrepasan el presupuesto estimado o no. En caso afirmativo se identificar´an las causas que han producido el desajuste presupuestario y se tendr´an en cuenta en las tareas siguientes para reducir la diferencia de costes. Si finalmente el coste real supera al presupuestado se aplicar´a la partida de imprevistos y contingencia para cubrir la diferencia. Los indicadores utilizados para controlar la gesti´on 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´ on de una tarea en precio = (coste std – coste real) * consumo horas real Desv´ıo total en la realizaci´ on 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´ on 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´on sostenibilidad La alta puntuaci´ on total obtenida, 25 puntos, hace que este proyecto sea viable para ser desarrollado y tenga en general un impacto positivo en los tres ´ambitos que se detallar´ an a continuaci´ on: econ´ omico, social y ambiental. 8.2. Econ´ omica Para determinar la viabilidad econ´omica de un proyecto es preciso conocer todos los factores que pueden suponer costes en ´el. Esto se ha tenido en cuenta en secciones anteriores y en consecuencia se ha elaborado un presupuesto. Observando los resultados obtenidos en ´este 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´ un y ser distribuido de forma gratuita en el mercado de Google, podr´ıa contar con m´ odulos 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´on de cierta tarea para desarrollar el proyecto en un menor tiempo. No obstante, la contrataci´on de un programador con experiencia en Android reducir´ıa los tiempos de auto-aprendizaje y programaci´on, pero en el ´ambito universitario del proyecto esto no aplica. Tambi´en, la colaboraci´on con otro proyecto relacionado agilizar´ıa todo el desarrollo pero este escenario tampoco se contempla. En consecuencia, la viabilidad econ´omica para este proyecto se considera que tiene una valoraci´ on de 9. 8.3. Social La expansi´ on del sistema Android en los u ´ltimos a˜ nos ha sido de una enorme magnitud, tal y como ya se ha comentado. Tanto es as´ı que se ha convertido en el sistema m´ as usado en la actualidad. Este hecho ha propiciado que los usuarios encuentren en este sistema un lugar en el cual almacenar informaci´ on privada y confidencial. A causa del uso diario y constante que se hace de los dispositivos m´ oviles, una gran cantidad de situaciones adversas pueden tener un impacto en la confidencialidad de los usuarios. Por ejemplo, la contrase˜ na de bloqueo de un documento protegido de un ejecutivo podr´ıa ser vista por otra persona en el transporte p´ ublico, lugar de trabajo, etc. En consecuencia, existe una necesidad real de mejorar la protecci´ on 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´on desarro´ llada contempla proteger eficazmente un escenario concreto. Este 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´ecnicas en Internet para acabar consiguiendo los datos que desea. Debido a que esta aplicaci´ on est´a destinada a ofrecer una protecci´on 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´an afectados ni positiva ni negativamente por la aparici´on de esta aplicaci´on. 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 u ´nicamente de un port´atil y un m´ovil su consumo no aumenta la huella ecol´ogica pero tampoco se puede considerar que contribuya a reducirla. Del uso de la aplicaci´on tampoco se espera que tenga ning´ un impacto en dicha huella ecol´ ogica. Por otro lado, estos dispositivos seguir´an siendo usados en la empresa una vez concluya este proyecto, con lo cual su vida u ´til se exprimir´a al m´aximo. Por estos motivos se punt´ ua 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´a dotado de la u ´ltima tecnolog´ıa y su evoluci´ on es notable con el paso de las versiones. No obstante, y a pesar de estar respaldado por una de las compa˜ n´ıas m´as potentes de hoy en d´ıa, Google, este sistema est´a lejos de rozar la perfecci´on. Como se ha podido ver en la parte te´ orica, el modelo de seguridad sobre el cual se basa Android requiere de un refuerzo considerable para proporcionar mayor protecci´on 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´on da un paso hacia adelante y cubre vulnerabilidades existentes pero los cibercriminales tambi´en actualizan sus m´etodos. Por este motivo, es necesario que investigaciones externas contribuyan a mejorarlo paliando situaciones que ´este no contempla. Como se ha podido ver, existen potentes extensiones de seguridad que est´an disponibles y algunas otras ya han sido incorporadas de forma nativa en las nuevas versiones. A´ un y as´ı siempre existen vulnerabilidades que pueden ser aprovechadas para sustraer informaci´ on 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´on 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´on. En relaci´ on a este u ´ltimo aspecto, se ha demostrado que la aplicaci´on desarrollada en este proyecto proporciona un nivel m´as de protecci´on que pasa desapercibido ante terceras personas y permite al usuario autenticarse de forma c´omoda y sin necesidad de focalizar toda su atenci´ on en el momento de la autenticaci´on. En consecuencia, se ha cumplido el objetivo de reforzar la privacidad de un usuario dificultando la sustracci´on de informaci´ on 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