Confidencialidad de la Información en Dispositivos Android
JORGE LUIS CORCHUELO PEREZ
UNIVERSIDAD DE LOS ANDES
FACULTAD DE INGENERIA
DEPARTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN
Confidencialidad de la Información en Dispositivos Android
JORGE LUIS CORCHUELO PEREZ
Asesor
Sandra Julieta Rueda Rodríguez, Ph. D.
Profesora Asistente
UNIVERSIDAD DE LOS ANDES
FACULTAD DE INGENERIA
DEPRTAMENTO DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN
TABLA DE CONTENIDO
ÍNDICE DE FIGURAS ... 6
RESUMEN ... 8
1 INTRODUCCIÓN ... 9
2 DESCRIPCIÓN DEL PROBLEMA ... 14
2.1 Contexto Específico ... 14
2.2 Arquitectura de Seguridad de Android ... 16
3 PROPUESTA ... 23
3.1 Objetivos ... 23
3.2 Marco Teórico ... 24
3.3 Descripción de alto nivel ... 25
3.3.1 Control de Acceso ... 25
3.3.2 Requerimientos de la Aplicación ... 30
3.4 Arquitectura de la solución ... 35
3.4.1 Diseño del Sistema ... 35
3.4.2 Diseño de Seguridad ... 46
4 IMPLEMENTACIÓN ... 56
4.1 Framework ... 56
4.2 Herramientas ... 58
4.3 Interconexión ... 59
4.4 Instalación y Ejecución ... 60
5 EVALUACIÓN ... 64
5.1 Análisis ... 64
5.1.1 Ventajas y Alcance ... 64
5.1.2 Evaluación de seguridad ... 64
5.2 Desempeño y Facilidad de uso ... 65
5.2.1 Evaluación de tiempos de respuesta ... 65
5.3 Comparación con Otras Soluciones ... 68
6 CONCLUSIONES ... 78
6.1 Discusión ... 78
6.2 Conclusiones ... 79
6.3 Trabajo futuro ... 79
INDICE DE TABLAS
TABLA 1 SMARTPHONE PLATFORM MARKET SHARE PARA 2013 SEGÚN COMSCORE [6]. ... 10
TABLA 2 ÁREAS DE TRABAJO ... 26
TABLA 3 CLASIFICACIÓN DE LA INFORMACIÓN ... 27
TABLA 4 MODELO DE CONTROL ... 28
TABLA 5 “THE STRIDE THREAT MODEL” DE MICROSOFT, TOMADO DE [24] ... 31
TABLA 6 ANÁLISIS DE AMENAZAS ... 32
TABLA 7 FUNCIONALIDADES - MODULO ADMINISTRACIÓN ... 33
TABLA 8 FUNCIONALIDADES - MODULO USUARIO ... 33
TABLA 9 REQUERIMIENTOS FUNCIONALES DE LA APLICACIÓN ... 34
TABLA 10 REQUERIMIENTOS DE SEGURIDAD EN LA APLICACIÓN ... 35
TABLA 11 DEFINICIÓN DE VOLÚMENES ... 46
TABLA 12 ATRIBUTOS PARA CONTROL DE ACCESO ... 47
TABLA 13 IMPLEMENTACIÓN DE BLP CON CATEGORÍAS EN LA APLICACIÓN ... 65
TABLA 14 RESULTADOS PRUEBAS DE EVALUACIÓN DE DESEMPEÑO ... 66
TABLA 15 CUESTIONARIO PARA EVALUACIÓN DE USABILIDAD ... 67
TABLA 16 RESULTADOS DE LA EVALUACIÓN ... 68
TABLA 17 REQUERIMIENTOS FUNCIONALES NO IMPLEMENTADOS... 80
ÍNDICE DE FIGURAS
FIGURA 1. PROYECCIÓN DEL CRECIMIENTO EN SUSCRIPCIONES DE TELÉFONOS INTELIGENTES PARA 2019 SEGÚN ERICSSON, TOMADO
DE [9] ... 9
FIGURA 2. PROYECCIÓN DEL CRECIMIENTO EN EL USO DE DISPOSITIVOS MÓVILES INTELIGENTES SEGÚN IDC, TOMADO DE [17]. .. 10
FIGURA 3. ACTIVACIONES DIARIAS DE DISPOSITIVOS ANDROID ENTRE 2010-2013 SEGÚN EL PORTAL STATISTA.COM [32]. ... 11
FIGURA 4. CRECIMIENTO DE LAS APLICACIONES MALICIOSAS O DE ALTO RIESGO EN EL 2013 SEGÚN TRENDLABS [35]. ... 11
FIGURA 5. TIPOS DE AMENAZAS PARA DISPOSITIVOS MÓVILES EN EL 2013 SEGÚN TRENDLABS [35]. ... 12
FIGURA 6. AUMENTO EN LAS VARIANTES DEL MALWARE “ANDROID GINMASTER” ENTRE EL 2012 Y 2013 SEGÚN SOPHOS [25] 12 FIGURA 7. FORMAS COMUNES EN LAS CUALES SON HURTADOS LOS DISPOSITIVOS MÓVILES SEGÚN LA COMPAÑA LOOKUT, TOMADO DE [19]. ... 14
FIGURA 8. ÍNDICE DE ROBO POR TIPO DE DISPOSITIVO MÓVIL EN LATINOAMÉRICA 2013 SEGÚN ESET, TOMADO DE [10] ... 15
FIGURA 9 PAÍSES EN LOS CUALES LOS USUARIOS TIENEN MÁS APLICACIONES INSTALADAS EN SU DISPOSITIVO MÓVIL, TOMADO DE [11] ... 15
FIGURA 10 TOP 7 EN CHINA DE LAS APLICACIONES MÓVILES CON ALMACENAMIENTO EN LA NUBE, TOMADO DE [5] ... 16
FIGURA 11 ARQUITECTURA DE ARRANQUE DE UN DISPOSITIVO MÓVIL EJECUTANDO ANDROID, TOMADO DE [18] ... 17
FIGURA 12 PROCESO DE VERIFICACIÓN FIRMA DIGITAL DEL BOOTLOADER Y DEL LINUX KERNEL, TOMADO DE [18]... 17
FIGURA 13 VISTA ESQUEMÁTICA DE LOS PROCESOS Y APLICACIONES DURANTE TIEMPO DE EJECUCIÓN EN UN SISTEMA ANDROID, TOMADO DE [18] ... 18
FIGURA 14 EL ACCESO A LA INFORMACIÓN SENSITIVA DEL USUARIO SOLO SE PUEDE REALIZAR MEDIANTE APIS PROTEGIDAS, TOMADO DE [12] ... 19
FIGURA 15 VALIDACIÓN DE PERMISOS REQUERIDOS POR UNA APLICACIÓN, TOMADO DE [12] ... 20
FIGURA 16. EJEMPLO DE MODELO BLP CON TRES NIVELES DE SENSIBILIDAD (PÚBLICO, CONF Y SEC) Y DOS CATEGORÍAS (A,L). .. 25
FIGURA 17. ANDROIDBLP SOPORTA UNA POLÍTICA MÁS RESTRINGIDA QUE LA POLÍTICA BLP CORRESPONDIENTE. ... 29
FIGURA 18 DIAGRAMA CASO DE USO PARA CONFIGURACIÓN INICIAL ... 36
FIGURA 19 DIAGRAMA CASO DE USO PARA INICIO DE SESIÓN... 37
FIGURA 20 DIAGRAMA CASO DE USO PARA CREACIÓN DE USUARIO ... 37
FIGURA 21 DIAGRAMA CASO DE USO PARA CAMBIO DE PASSWORD ... 38
FIGURA 22 DIAGRAMA CASO DE USO PARA CONFIGURACIÓN IMPORTAR ARCHIVO ... 38
FIGURA 23 DIAGRAMA CASO DE USO PARA ABRIR ARCHIVO ... 39
FIGURA 24 DIAGRAMA CASO DE USO PARA ELIMINAR ARCHIVO ... 39
FIGURA 25 DIAGRAMA DE CLASES ... 40
FIGURA 26 DIAGRAMA DE SECUENCIA - CONFIGURACIÓN INICIAL ... 42
FIGURA 27 DIAGRAMA DE SECUENCIA - INICIO DE SESIÓN ... 43
FIGURA 28 DIAGRAMA DE SECUENCIA - CREACIÓN DE USUARIO ... 43
FIGURA 29 DIAGRAMA DE SECUENCIA - CAMBIO DE CONTRASEÑA ... 44
FIGURA 30 DIAGRAMA DE SECUENCIA - IMPORTAR ARCHIVO ... 44
FIGURA 31 DIAGRAMA DE SECUENCIA - ABRIR ARCHIVO ... 45
FIGURA 32 DIAGRAMA DE SECUENCIA - ELIMINAR ARCHIVO ... 45
FIGURA 33 MODELO CONCEPTUAL PARA DERIVACIÓN DE LLAVES ... 49
FIGURA 34 DIAGRAMA DE ACTIVIDAD - CONFIGURACIÓN INICIAL ... 51
FIGURA 35 DIAGRAMA DE ACTIVIDAD - CREACIÓN USUARIOS ... 52
FIGURA 36 DIAGRAMA DE ACTIVIDAD - INICIO DE SESIÓN ... 53
FIGURA 37 DIAGRAMA DE ACTIVIDAD - CAMBIAR DE CONTRASEÑA ... 53
FIGURA 38 DIAGRAMA DE ACTIVIDAD - CIFRAR ARCHIVO ... 54
FIGURA 39 DIAGRAMA DE ACTIVIDAD - DESCIFRAR ARCHIVO ... 55
FIGURA 40 VERSIÓN DE ANDROID STUDIO ... 56
FIGURA 41 VERSIÓN DE GRADLE Y ANDROID PLUGIN ... 56
FIGURA 42 VERSIÓN DEL ANDROID FRAMEWORK API ... 57
FIGURA 43 COMPATIBILIDAD CON VERSIONES ANTERIORES DEL ANDROID FRAMEWORK ... 57
FIGURA 45 OPCIÓN DE INSTALACIÓN “UNKNOW SOURCES” ... 60
FIGURA 46 ANDROIDBLP - PERMISOS REQUERIDOS PARA INSTALACIÓN ... 61
FIGURA 47 ANDROIDBLP - INICIO DE SESIÓN... 61
FIGURA 48 ANDROIDBPL - ÁREAS DE TRABAJO Y ARCHIVOS ... 62
FIGURA 49 ANDROIDBPL - IMPORTAR ARCHIVO ... 62
FIGURA 50 ANDROIDBLP - SELECCIÓN DE ARCHIVO A IMPORTAR ... 63
FIGURA 51 ANDROIDBLP - CREACIÓN DE USUARIO ... 63
FIGURA 52 CARACTERÍSTICAS DISPOSITIVO NEXUS 7 (2013) ... 65
FIGURA 53 ARQUITECTURA DE FLASKDROID, TOMADO DE [27] ... 69
FIGURA 54 FUNCIONALIDADES DE SAMSUNG KNOX, TOMADO DE [29] ... 70
FIGURA 55 DISEÑO DE SEGURIDAD DE SAMSUNG KNOX, TOMADO DE [29] ... 71
FIGURA 56 SEPARACIÓN DE APLICACIONES EN SAMSUNG KNOX, TOMADO DE [29] ... 72
FIGURA 57 ON-DEVICE DATA ENCRYPTION (ODE) EN SAMSUNG KNOX, TOMADO DE [29] ... 72
FIGURA 58 SECRECY EN GOOGLE PLAY, TOMADO DE [23] ... 73
FIGURA 59 CREACIÓN DE UN CONTENEDOR EN SECRECY ... 74
FIGURA 60 ACCESO A UN CONTENEDOR EN SECRECY ... 74
FIGURA 61 IMPORTAR ARCHIVOS A UN CONTENEDOR SECRECY ... 75
FIGURA 62 UBICACIÓN DE LOS CONTENEDORES EN SECRECY ... 75
RESUMEN
El uso diario de dispositivos móviles, tales como tabletas y teléfonos inteligentes, es cada vez más extendido y se espera que siga creciendo en los próximos años. Android es la plataforma más usada en estos dispositivos, y como consecuencia también es la más atacada, aunque no sea la más vulnerable.
En este contexto también ha crecido la preocupación de desarrolladores de Android e investigadores en el área de seguridad, sobre la privacidad y confidencialidad de la información almacenada por los usuarios en los dispositivos móviles.
Por otro lado, las personas no solo almacenan datos personales en sus dispositivos móviles; cada vez es más frecuente que almacenen información de sus compañías, exponiéndola a pérdida, robo, y acceso no autorizado. Las razones son variadas, incluyendo uso de contraseñas débiles, descarga de aplicaciones no confiables, y asignación excesiva de permisos en el momento de instalación de una aplicación. Adicionalmente, los desarrolladores de aplicaciones no incluyen protección para los recursos de sus aplicaciones permitiendo que éstos puedan ser usados por otras aplicaciones que corran en el mismo dispositivo, y construyen respaldos automáticos en la nube sin proteger la información de forma adecuada.
Este trabajo propone la construcción de una herramienta para manejo de la confidencialidad de los datos en dispositivos móviles. Esta herramienta, que llamaremos AndroidBLP, permitirá al usuario establecer explícitamente, de manera sencilla, los requerimientos de seguridad de sus archivos, y con base en estos requerimientos permitirá la implementación de una política de control de acceso acorde con dichos requerimientos.
AndroidBLP se basa en el modelo de confidencialidad Bell-LaPadula que permite el manejo de diferentes niveles de sensibilidad y de categorías, así un usuario puede asociar diferentes niveles de sensibilidad a sus recursos, y asignarlos a diferentes compartimientos para evitar problemas de confidencialidad por descuidos o equivocaciones.
La herramienta propuesta (AndroidBLP) es una aplicación de fácil uso, que puede usarse en cualquier dispositivo con sistema operativo Android, y requiere pocos conocimientos técnicos para su instalación y su operación. Además, combina cifrado con control de acceso. Estos elementos no son ofrecidos por las soluciones disponibles en el mercado.
Lo anterior se confirmó al realizar una pequeña evaluación de usabilidad con un grupo de personas con pocos conocimientos técnicos se concluyó que la aplicación tiene un nivel aceptable de usabilidad que puede ser mejorada en versiones futuras.
1
INTRODUCCIÓN
El uso diario de dispositivos móviles, tales como tabletas y teléfonos inteligentes que ejecutan sistema operativo Android es cada vez más frecuente, así como también que las personas los utilicen para almacenar información personal y en muchas ocasiones información corporativa, lo que genera preocupaciones en cuanto a la privacidad y confidencialidad de dicha información. De acuerdo con la firma Ericsson [9], durante los primeros tres meses de 2014, alrededor del 65% de todos los dispositivos móviles vendidos en el mundo correspondieron a teléfonos inteligentes. Adicionalmente, esta misma firma determinó que en 2013 existían 1900 millones de dispositivos móviles inteligentes activos y proyectó que para el año 2019 existirán 5600 millones de dichos dispositivos activos alrededor del mundo (Figura 1).
Figura 1. Proyección del crecimiento en suscripciones de teléfonos inteligentes para 2019 según Ericsson, tomado de [9]
Tal es el incremento en el uso de dispositivos móviles inteligentes que la firma IDC [17] proyecta que en 2017 el 70.47% de todos los dispositivos conectados a internet corresponderán a teléfonos inteligentes y 16.54% a tabletas (Figura 2).
Figura 2. Proyección del crecimiento en el uso de dispositivos móviles inteligentes según IDC, tomado de [17].
Por otro lado, y de acuerdo a la firma Comscore [6], en el año 2013 cerca del 52% de todos los dispositivos móviles inteligentes utilizaban alguna versión del sistema operativo Android (Figura 3).
Adicionalmente, según el portal statista.com, a marzo del 2013, se activaron diariamente 1.4 millones de dispositivos inteligentes Android [32] (Figura 3).
Figura 3. Activaciones diarias de dispositivos Android entre 2010-2013 según el portal statista.com [32].
A medida que crece la cantidad de dispositivos inteligentes que usan Android, también crece la cantidad de malware diseñado para ejecutase en dicha plataforma. Según el “2013 Annual Security Roundup” de TrendLabs [35], la cantidad de malware y aplicaciones que compromete la experiencia del usuario casi se duplicó entre el año 2012 y 2013 (Figura 4).
En este mismo estudio, TrendLabs establece que el 19 por ciento del malware tiene como objetivo robar información del dispositivo móvil (Figura 5).
Figura 5. Tipos de amenazas para dispositivos móviles en el 2013 según TrendLabs [35].
En esta categoría podemos resaltar el malware troyano polimórfico denominado “Android GinMaster” [25] que es inyectado en aplicaciones legítimas y ampliamente utilizadas, tales como juegos o ring tones, que luego son publicadas en internet para que los usuarios las descarguen. Cuando un usuario instala, en su teléfono inteligente o tableta, una aplicación infectada con GinMaster, en el dispositivo se crea y activa un servicio malicioso que tiene la habilidad de elevarse los privilegios de acceso, robar información y enviarla a sitios web remotos, además de poder instalar otras aplicaciones, sin la interacción del usuario.
Según la firma Sophos [25], actualmente existen en Internet más de 6000 variantes de GinMaster y para finales del 2013 cerca de 10.000 personas habían descargado aplicaciones infectadas con dicho malware (Figura 6).
Figura 6. Aumento en las variantes del malware “Android GinMaster” entre el 2012 y 2013 según Sophos [25]
Un elemento adicional que afecta la seguridad en los dispositivos que ejecutan el sistema operativo Android es la falta de instalación de las actualizaciones de seguridad liberadas por Google. Esta situación es ocasionada porque los fabricantes de los dispositivos no están obligados a proveer a sus usuarios de dichas actualizaciones de manera regular, y por tanto muchos de ellos no lo hacen. Un estudio realizado por el Security Group de la Universidad de Cambridge encontró que cerca del 87% de los dispositivos Android tienen vulnerabilidades de seguridad críticas por falta de la instalación de actualizaciones de seguridad liberadas por Google, lo que facilita que malware como por ejemplo Ginmaster pueda instalarse en dichos dispositivos [2].
2
DESCRIPCIÓN DEL PROBLEMA
2.1 CONTEXTO ESPECÍFICO
Según estadísticas recopiladas por el portal supermonitoring.com [33], para el 50% de las personas que utilizan teléfonos inteligentes o tabletas, estos dispositivos son su principal o única herramienta de trabajo, repositorio de datos personales o medio para conectarse a internet. Adicionalmente, y con la creciente asignación de teléfonos inteligentes o tabletas por parte de las compañías a sus empleados, así como la implementación de estrategias como BYOD (Bring Your Own Device), cada vez se almacena más información confidencial corporativa, mezclada con información personal, en este tipo de dispositivos, exponiéndola a pérdida, robo y acceso no autorizado.
En el año 2013 la firma Huddle [15] realizó un estudio para determinar el tipo de información que las personas almacenaban en sus dispositivos móviles. Dicho estudio involucró a 2000 adultos con edades entre los 18 a 65 años y encontró que aproximadamente el 52% de estas personas modifican, guardan o comparten, en tabletas y teléfonos inteligentes de su propiedad, documentos confidenciales de la compañía para la cual trabajan y datos de su vida personal. Según la Firma Consumer Reports [7], en el año 2013, cerca de 3.1 millones de personas en Estados Unidos reportaron ser víctimas de pérdida o robo de su dispositivo inteligente, duplicando la cantidad de personas afectadas por esta situación en el año 2012. Estas cifras indicarían, según la compaña Lookout [19], que aproximadamente 1 de cada 10 propietarios extravía su dispositivo móvil o este les es hurtado (Figura 7).
Figura 7. Formas comunes en las cuales son hurtados los dispositivos móviles según la compaña Lookut, tomado de [19].
En Colombia, de acuerdo a un artículo de la revista Semana y las estadísticas de Policía Nacional, un dispositivo móvil es hurtado cada dos minutos, sumando más de un millón de dispositivos año,
lo cual convierte este tipo de robos, tanto en Colombia como en el resto del mundo, en uno de los delitos con mayor impacto en las grandes ciudades [26] (Figura 8).
Figura 8. Índice de robo por tipo de dispositivo móvil en Latinoamérica 2013 según ESET, tomado de [10]
Según el estudio “The 2014 Bitglass Healthcare Breach Report” [4], realizado en Estados Unidos por la compañía Bitglass, desde el 2010 y hasta el día de hoy el 68% de los incidentes que involucran pérdida de información en el sector salud, incluyendo historias medias y datos personales de pacientes, se dan cuando elementos como computadores y dispositivos móviles inteligentes son extraviados o son robados.
Adicionalmente, los usuarios de dispositivos móviles usan en promedio 26 aplicaciones diferentes [11] (Figura 9), muchas de las cuales utilizan servicios de nube y envían información del usuario de manera “más o menos autorizada”, partiendo de la premisa: si el usuario instala la aplicación, está dando su aprobación para el envío de su información a un servidor externo. El problema es que ni la aplicación, ni el usuario, consideran la sensibilidad de los datos manejados.
Figura 9 Países en los cuales los usuarios tienen más aplicaciones instaladas en su dispositivo móvil, tomado de [11]
Las personas que de manera consciente o inconsciente utilizan aplicaciones con almacenamiento en la nube lo hace por la conveniencia que este tipo de aplicaciones representa, pero en muchas ocasiones en los servicios de nube la información no se encuentra cifrada, la transferencia de datos entre el dispositivo móvil y el servicio no está protegida, y las compañías que los operan, o incluso otras personas, pueden acceder a la información allí almacenada. Por ejemplo, según el sitio chinainternetwatch.com [5], en China las 7 principales aplicaciones móviles con almacenamiento en la nube son utilizadas mensualmente por cerca de 17 Millones de usuarios (Figura 10).
Figura 10 Top 7 en China de las aplicaciones móviles con almacenamiento en la nube, tomado de [5]
2.2 ARQUITECTURA DE SEGURIDAD DE ANDROID
Android ofrece una arquitectura de seguridad que busca proteger la privacidad de la información almacenada en el dispositivo utilizando varios mecanismos: partición y arranque seguro, sanboxing de aplicaciones, manejo de permisos en el sistema de archivos, instalación controlada de aplicaciones y manejo de los permisos que se les asignan, criptografía, y protección por contraseña.
Partición y Arranque Seguro del Sistema Operativo
El almacenamiento de los dispositivos que utilizan Android se encuentran dividido en varias particiones, una de ella contiene, entre otros elementos, el kernel del sistema operativo, las librerías del sistema y el framework de aplicación. Cuando el sistema operativo inicia, dicha partición es montada en modo Read-Only para evitar modificaciones no autorizadas.
Con el objetivo de garantizar la seguridad del sistema operativo el proceso de arranque de un dispositivo que ejecuta Android tiene los siguientes pasos:
1. Cuando la CPU inicia empieza su ejecución leyendo el “reset vector” que está almacenado en la ROM y contiene el bootloader inicial (IBL). La ROM puede ser
establecida durante el proceso de fabricación en el system-onchip (SoC) o el IBL puede ser adicionado en una ROM programable. La función del IBL es inicializar el controlador de la DRAM y del medio de arranque (MMC, eMMC, NAND flash, USB). (Figura 11)
Figura 11 Arquitectura de Arranque de un dispositivo móvil ejecutando Android, tomado de [18]
2. El IBL realiza la carga en la RAM del bootloader desde el medio de arranque y verifica que la firma digital de la imagen cargada corresponda a la del fabricante del dispositivo con el objetivo de garantizar que solo código autenticado es ejecutado. Si el resultado de esta verificación es correcto el IBL entrega la ejecución al bootloader. El medio de arranque utilizado por el IBL es seleccionado por el “operating mode pin” (OM) que es establecido de manera permanente durante la producción del SoC. La verificación de la firma digital se realiza utilizando la llave pública del fabricante del equipo que es cargada a la RAM. (Figura 12)
3. El bootloader inicializa hardware adicional, como por ejemplo la pantalla, y luego realiza una verificación de la firma digital del Kernel de Linux antes de entregarle el control.
4. El Kernel de Linux inicializa todo el hardware del dispositivo e inicia el proceso “init” en el espacio de ejecución del usuario. Este proceso lee el archivo de configuración init.rc que contiene información sobre los servicios que deben ser iniciados y sus dependencias e inicia dichos servicios. Una vez finalizada la inicialización de los servicios el sistema queda preparado para ser utilizado por el usuario.
SandBox de Aplicación
Cada aplicación instalada tiene asignado un UserID (UID) único y es ejecutada en un proceso separado. Esta división permite al sistema operativo realizar toda la intermediación entre aplicaciones, lo cual le permite determinar si alguna aplicación está intentando realizar operaciones no autorizadas y al mismo tiempo proteger a las demás aplicaciones y al sistema operativo ante esta situación. (Figura 13)
Figura 13 Vista esquemática de los procesos y aplicaciones durante tiempo de ejecución en un sistema Android, tomado de [18]
Permisos del Sistema de Archivos
Android utiliza un modelo de permisos en el sistema de archivos tipo “Unix-like” que define tres alcances: user, group, y others. Este modelo “asegura” que un usuario no puede leer, alterar o eliminar archivos de otro usuario. Teniendo en cuenta que en Android cada aplicación se ejecuta con UserID único (UID), los archivos que sean creados por una aplicación no deberían poder ser accedidos por otra. Hay una excepción: las aplicaciones desarrolladas por el mismo autor y firmadas digitalmente con la misma llave privada, pueden ejecutarse con el mismo UID y por lo tanto una aplicación puede tener acceso a información de otra aplicación. Los archivos creados en tarjetas SD son de Lectura/Escritura para todos los usuarios.
Permisos de Acceso a Información Personal
Complementando los permisos de sistema de archivos, la arquitectura de seguridad de Android identifica un conjunto de datos como datos sensibles y restringe el acceso de
cualquier aplicación a este tipo de datos, que pueden ser almacenados por el sistema operativo y por otras aplicaciones.
La única forma en la cual una aplicación puede acceder a datos sensibles es mediante una serie de APIs protegidas, en las cuales el “Android OS permisión chek” verifica si la aplicación que realiza el llamado tiene los permisos requeridos para acceder a los datos solicitados. Estos permisos son asignados al momento de la instalación tal como se describe en la siguiente sección. (Figura 14)
Figura 14 El acceso a la información sensitiva del usuario solo se puede realizar mediante APIs protegidas, tomado de [12]
Instalación controlada de Aplicaciones y manejo de permisos
Por defecto, Android solo permite la instalación de aplicaciones desde fuentes reconocidas, tales como Google Play Store. Pero el usuario puede, de manera explícita, permitir la instalación desde otras fuentes, como sitios de internet alternos o memorias SD.
El paquete de instalación de una aplicación está compuesto por los siguientes elementos:
o META-INFO/jar: Contiene la firma digital del paquete de instalación.
o res/ , classes.dex, dalvik byte-code: Recursos requeridos por la aplicación
o resources.arsc: Archivo de recursos binarios después de compilación
o AndroidManifest.xml: Archivo que especifica la configuración de la aplicación y los permisos de acceso o recursos requeridos.
Las siguientes actividades son realizadas por Android cuando se ejecuta el proceso de instalación de una aplicación:
1. Verificación de la integridad del paquete de instalación de la aplicación (Archivo .apk). Para que una aplicación puede ser instalada su paquete de instalación debe estar firmado digitalmente con la llave de un desarrollador. Android verifica si la firma digital del paquete de instalación de la aplicación es válida o no.
2. Análisis del archivo AndroidManifest.xml para conocer la configuración de la aplicación, los permisos de accesos o recursos requeridos, y si dicha aplicación ya se encuentra instalada en el dispositivo.
3. Se determina si el UID, dependiendo de la firma digital del desarrollador de la aplicación y la presencia de la opción sharedUserId en el archivo AndroidManifest.xml, deber único o compartido con otras aplicaciones ya instaladas en el dispositivo. Dependiendo del resultado de este análisis se crea un nuevo UID o se asigna uno ya existente.
4. Se informa al usuario, de manera explícita, la lista de permisos requeridos por la aplicación y se solicita su autorización.
-Figura 15 Validación de permisos requeridos por una aplicación, tomado de [12]
5. Si el usuario aprobó los permisos solicitados por la aplicación, esta es instalada en el dispositivo.
El modelo de seguridad de Android define que todos los permisos de las aplicaciones son establecidos al momento de su instalación y no pueden ser cambiados a menos que la aplicación sea desinstalada e instalada nuevamente.
Criptografía
Las aplicaciones que se ejecutan en Android tienen a su disposición una serie de APIs que dan acceso a diversas implementaciones criptográficas tales como AES, RSA, DSA y SHA.
Desde la versión 4.0, Android provee una API para el acceso a funcionalidades de Llavero (“Keychain”) que ofrece a las aplicaciones la posibilidad de almacenar de manera segura credenciales de usuario y certificados digitales. Los archivos (“Key”) que componen el llavero son almacenados de manera individual en “/data/misc/keystore” y son cifrados utilizando AES de 128-bit en modo CBC. Cada archivo (“Key”) tiene un encabezado que
contiene el vector inicial (IV) utilizado para el cifrado, un hash MD5 de la llave utilizada para el cifrado y de los datos cifrados. Los archivos (“Key”) son cifrados utilizando una llave maestra (“masterkey”) que a su vez está cifrada utilizando AES128 y es derivada de la contraseña de acceso al dispositivo definida por el usuario usando PBKDF2 con 8192 iteraciones.
Protección por Contraseña
El acceso al dispositivo puede ser protegido mediante la asignación por parte del usuario de una contraseña. Android permite al usuario establecer políticas de complejidad en la contraseña que una vez definidas son de cumplimiento obligatorio.
Cifrado Sistema de Archivos
Las versiones 3.0 y superiores de Android permiten realizar un cifrado completo del sistema de archivos del dispositivo mediante la implementación a nivel de Kernel de dmcrypt (AES128 con CBC y ESSIV:SHA256) y de las funciones de ioctls requeridas. La llave de cifrado es protegida por AES128 usando una llave maestra derivada de la contraseña de acceso al dispositivo definida por el usuario.
Para activar esta funcionalidad el usuario debe establecer una contraseña de acceso al dispositivo y habilitar manualmente en la configuración la opción de cifrado de sistema de archivo.
Una vez activada esta funcionalidad, de la combinación entre la contraseña de acceso al dispositivo y un valor aleatorio “salt”, tomado desde dev/urandom, se calcula un hash con el cual, mediante el algoritmo AES, se cifra la llave maestra de 128 Bits, también derivada de /dev/urandom, que es utilizada por dmcrypt para cifrar el sistema de archivos.
Cuando Android necesita leer datos cifrados del sistema de archivos, cada sector del dispositivo de almacenamiento que sea requerido es descifrado de manera individual en memoria y entregado para uso. Cuando Android necesita escribir datos en un sistema de archivo cifrado, la información en memoria es divida en porciones del tamaño de sectores y cada porción es cifrada antes de ser escrita, como un sector, en el dispositivo de almacenamiento.
Cuando un usuario cambia la contraseña de acceso al dispositivo no es necesario cifrar nuevamente el sistema de archivo, solamente es cifrada la llave maestra utilizando el proceso descrito anteriormente.
La confidencialidad de la información protegida por los mecanismos anteriormente descritos puede ser comprometida si:
El usuario no utiliza contraseña de acceso al dispositivo o cifrado del sistema de archivo o establece contraseñas débiles. En el caso del cifrado del sistema de archivo, este solo protege la información cuando el dispositivo se encuentra apagado y bloqueado por
contraseña. Una vez el dispositivo se encuentra encendido y se ha pasado la validación de la contraseña, este mecanismo ya no es efectivo.
El usuario ha realizado “rooting” del dispositivo, lo cual le asigna derechos de súper usuario (root) y le permite modificar el sistema operativo, el kernel y cualquier aplicación instalada en el dispositivo, así como también le permite acceder a cualquier aplicación y a cualquier archivo en el dispositivo.
El usuario descarga e instala aplicaciones en su dispositivo Android, desde fuentes no confiables, tales como tiendas de aplicaciones diferentes a Google Play Store.
Al momento de la instalación de una nueva aplicación el usuario no verifica o no entiende los permisos que la aplicación requiere, pudiendo en este caso, permitir que dicha aplicación, una vez completada su instalación, tenga acceso a toda la información almacenada en el dispositivo.
Los desarrolladores de la aplicaciones no realizan desarrollo seguro de software, pudiendo entre otras cosas, establecer de manera no adecuada los derechos de acceso a las carpetas que almacenan la información de la aplicación.
Algunas aplicaciones legítimas automáticamente mantienen respaldos de la información sin considerar la sensibilidad de la información almacenada.
Teniendo en cuenta las situaciones anteriormente descritas se hace necesario el desarrollo de un medio que le permita al usuario de dispositivos Android proteger la información que considere confidencial.
El problema particular en el que este trabajo se concentra es la falta de control de los usuarios sobre la confidencialidad de sus datos. A pesar de los mecanismos que la arquitectura de seguridad de Android ofrece para soportar requerimientos de seguridad, los usuarios pueden perder sus teléfonos, instalar malware con permisos en exceso, e incluso múltiples aplicaciones envían archivos con información de los usuarios a servidores externos, sin la aprobación explícita del usuario, quien es el propietario de dichos archivos.
Las aplicaciones que ofrecen servicio de respaldo/consulta en la nube envían información del usuario de manera “más o menos autorizada”. Los desarrolladores de las aplicaciones suponen que en el momento de la instalación, el usuario da su aprobación para el envío de archivos a un servidor externo. Sin embargo, los usuarios no entienden los riesgos de seguridad del almacenamiento de datos planos en la nube, y en algunos casos preferirían que dichos archivos no fueran enviados a la nube o que fueran almacenados solamente de forma cifrada. Los usuarios deberían poder asignar explícitamente los requerimientos de confidencialidad de los datos almacenados en sus dispositivos.
Esta situación se vuelve más compleja con la incorporación de políticas Bring your own device-BYOD en las organizaciones, porque los usuarios deben manejar requerimientos de confidencialidad no solo para sus propios datos, sino también para los datos de la organización que se encuentren almacenados en sus dispositivos.
3
PROPUESTA
Este trabajo propone el diseño y construcción de un mecanismo para manejo de la confidencialidad de los datos en dispositivos móviles. Este mecanismo devolverá al usuario el control sobre los requerimientos de confidencialidad de sus datos y permitirá definir políticas de manejo con base en dichos requerimientos.
3.1 OBJETIVOS
Objetivo General
Ofrecer a los usuarios de dispositivos móviles un mecanismo que les permita definir las características de confidencialidad de los datos almacenados en dichos dispositivos y controlar el acceso, de tal manera que los datos no puedan ser accedidos por otra persona o proceso del sistema operativo, sin una autorización explícita.
Objetivos Específicos
Desarrollar AndroidBLP, una aplicación multiusuario para el sistema operativo Android. Debido a que existen situaciones, tanto personales como profesionales, en las cuales un dispositivo móvil es utilizado por diferentes usuarios de manera no concurrente, por ejemplo cuando los miembros de una familiar comparte una tableta o diversos trabajadores de una compañía comparten por turnos un dispositivo móvil para sus actividades profesionales, así como también, que una gran cantidad de dichos dispositivos utilizan el sistema operativo Android, el cual es una plataforma abierta y no se encuentra atada a un fabricante especifico.
AndroidBLP permitirá proteger diferentes clases de información confidencial. De manera diaria las personas manejan información que cubre desde temas poco sensibles, como pueden ser una lista de compras o recordatorios, hasta temas altamente sensibles como por ejemplo fotografías personales, estados financieros o información médica. Las clases responderían a los diferentes niveles de sensibilidad asociados con diferentes datos de un usuario.
AndroidBLP permitirá a los usuarios definir los requerimientos de seguridad de sus datos, definición que se verá reflejada en las políticas de protección impuestas por la aplicación. En situaciones en las cuales un mismo dispositivo móvil es utilizado por diferentes personas, por ejemplos los miembros de una familia, al dueño de la información le interesa mantener el control sobre quién puede acceder a sus datos. Los mecanismos de control de acceso garantizaría que los datos podrán ser únicamente consultados por los usuarios a la cuales el dueño de la información les permita hacerlo.
AndroidBLP no solo integrará mecanismos para manejo de la confidencialidad, también integrará mecanismos básicos para manejo de la integridad de los datos. En general, a las personas no solo les interesa que su información esté segura y que pueda ser consultada
cuando sea requerido, sino también, que dicha información no haya sido modificada sin su autorización.
3.2 MARCO TEÓRICO
Bell-LaPadula (abreviado BLP) [8][20] es un modelo de seguridad computacional desarrollado para garantizar la confidencialidad de los datos y el control de acceso a información, desarrollado en los años 70 por David Elliott Bell y Leonard J. LaPadula.
El modelo define un esquema de control de acceso mandatorio, donde un usuario o proceso confiable, como el administrador o el sistema operativo, crea y hace cumplir las reglas de control de acceso. Un control de acceso discrecional, por el contrario, permite al dueño de la información definir y manipular los permisos de acceso sobre la misma cuando lo desee.
BLP establece dos actores en el manejo de la información, un sujeto y un objeto, un sistema para clasificar la sensibilidad de la información y el nivel de acceso de los usuarios denominados clasificación de seguridad o nivel de seguridad. Cada objeto tiene asignada una clasificación de seguridad y cada sujeto también tiene asignado un nivel de seguridad. Adicionalmente establece una política de confidencialidad basada en flujos de información que garantiza que un usuario tiene acceso de lectura a un objeto solo si la clasificación de seguridad del usuario domina la clasificación de seguridad del objeto. Esta política define los permisos de un sujeto sobre un objeto.
El primero objetivo de BLP es evitar que un usuario pueda acceder a información clasificada por encima de su nivel de confidencialidad, por esto establece la propiedad de Seguridad Simple definida así: “Un sujeto con un determinado nivel de seguridad no puede leer un objeto perteneciente a un nivel de seguridad más alto (no read-up)”.
El segundo objetivo de BLP es evitar que el usuario pueda leer información clasificada en su nivel de confidencialidad y guardarla en un nivel de confidencialidad inferior creando una fuga de información, Por esto establece la propiedad Estrella (*-property) definida así: “Un sujeto con un determinado nivel de seguridad no puede escribir un objeto con un nivel de seguridad más bajo”, esta propiedad implica que un usuario solo puede crear información en su nivel de confidencialidad o en uno superior. Aunque esta propiedad permitiría a un usuario escribir a objetos con una clasificación superior, garantizando la confidencialidad del sistema, los sistemas reales deben considerar la integridad de los objetos, y por esto la regla usualmente se implementa con posibilidad de escritura solamente al mismo nivel (no se permite escritura ni a niveles inferiores, ni a niveles superiores).
Debido a las propiedades de Seguridad Simple y Estrella, en BLP la información tiende a ir siempre al nivel más alto de confidencialidad, pero en algunos casos es necesario entregar información a niveles inferiores. Para manejar este caso, algunos usuarios tienen privilegios especiales autorizándolos a disminuir su clasificación de confidencialidad temporalmente, y habilitándolos para crear/escribir objetos con clasificaciones de confidencialidad menor. Esta excepción implica que un usuario clasificado como “confiable” puede tomar información en su clasificación y guardarla en una clasificación inferior.
El modelo de confidencialidad también maneja categorías para soportar la necesidad de crear compartimientos de información o “need-to-know”. La adición de categorías requiere extender las clasificaciones con la adición de dichas categorías y extender las propiedades de seguridad simple
y estrella. Es decir, las clasificaciones tendrán dos elementos en vez de uno: (nivel de confidencialidad, categoría).
La propiedad de seguridad simple con categorías establece que un usuario solo puede leer un objeto si su nivel de confidencialidad es mayor al del objeto, y su conjunto de categorías contiene al conjunto de categorías asociadas al objeto [20].
La propiedad estrella con categorías establece que un usuario solo puede escribir a un objeto si su nivel de confidencialidad es menor o igual al del objeto, y su conjunto de categorías es un subconjunto del conjunto de categorías asociadas al objeto [20].
La Figura 16 muestra la relación de dominio para niveles/clasificaciones de seguridad en un modelo BLP con tres niveles de sensibilidad para la información (Público, Confidencial-Conf, y Secreto-Sec) y dos categorías (A,L). Una flecha desde un elemento E1, hacia un elemento E2, indica que un sujeto con nivel E2 puede leer información de un objeto con su mismo nivel o con nivel E1. La misma flecha también indica que un sujeto con nivel E1 puede escribir a un objeto con su mismo nivel o con nivel E2. Además, la relación es transitiva.
Figura 16. Ejemplo de Modelo BLP con tres niveles de sensibilidad (Público, Conf y Sec) y dos categorías (A,L).
El modelo BLP es de interés porque garantiza la confidencialidad de la información, y el objetivo de este trabajo es implementar un mecanismo que permita a los usuarios recuperar el control de la confidencialidad de su información [20].
3.3 DESCRIPCIÓN DE ALTO NIVEL
Esta sección presenta características generales que la aplicación (AndroidBLP) debe exhibir para resolver el problema planteado.
3.3.1 Control de Acceso
Manejo de Usuarios
Sec, {A,L}
Sec, {A}
Sec, {L} Conf, {A,L}
Conf, {A} Conf, {L}
Existen situaciones en las cuales un dispositivo móvil es utilizado por diferentes personas de manera no concurrente para almacenar información, por ejemplo cuando los miembros de una familia comparten una tableta o diversos trabajadores de una compañía comparten por turnos un dispositivo móvil para sus actividades profesionales , es necesario definir múltiples usuarios, cada uno de ellos asignado a una persona, y con permisos apropiados para proteger y compartir la información de manera controlada.
Cualquier referencia a “usuario” que se encuentre a continuación se refiera a un identificador único para cada persona que utilice la aplicación, y es generado y asignado al interior de la misma.
Áreas de Trabajo
La información que las personas producen o almacena tiene diferentes orígenes o alcances, por ejemplo notas personales, fotos familiares o documentos corporativos. Para controlar y manejar la información de forma efectiva es necesario establecer algún método de separación según su origen o alcance.
AndroidBLP ofrecerá algunas funcionalidades básicas de un administrador de archivos, tales como crear, abrir o eliminar, buscar, copiar, cortar y pegar archivos, así mismo permitirá separar la información según su sensibilidad en 3 áreas de trabajo y en cada una de ellas clasificarla en 3 niveles de confidencialidad, así como definir y controlar qué usuarios tendrán acceso a qué clasificación de información y a que área de trabajo.
Tal como se mencionó anteriormente la información se separa en 3 áreas de trabajo denominadas: Personal, Familiar y Empresarial. Esta separación se crea para permitir que sobre un mismo dispositivo el usuario puedan almacenar y proteger de manera segura su información manteniéndola separada basado en el origen o alcance de la misma. Además, responde a las necesidades generales de los usuarios.
A continuación se puede encontrar una breve descripción de cada una de las áreas de trabajo disponibles en AndroidBLP:
Área Descripción
Personal En esta área se deberá almacenar información relacionada con el ámbito privado del usuario.
Familiar En esta área se deberá almacenar información relacionada con el ámbito familiar del usuario.
Empresarial En esta área se deberá almacenar información relacionada con el ámbito laborar, de negocios o corporativo del usuario.
Tabla 2 Áreas de Trabajo
Como se mencionó anteriormente la información que las personas producen y/o almacenan tiene diferentes orígenes o alcances, pero al mismo tiempo, información con un mismo origen o alcance puede tener diferentes niveles de sensibilidad, lo que hace también necesario agruparla por dicho nivel de sensibilidad para aplicar medidas de protección que permitan protegerla de manera adecuada.
Por lo anterior cada área de trabajo se separa en 3 niveles de confidencialidad denominados Publico, Confidencial y Secreto. Esta separación se crea para permitir que el usuario pueda almacenar y proteger de manera segura información con diferentes niveles de sensibilidad, sobre una misma área de trabajo.
A continuación se puede encontrar una breve descripción de cada uno de los niveles de confidencialidad en los cuales se puede clasificar la información almoneda en las áreas de trabajo disponibles en AndroidBLP:
Clasificación Descripción
Público Esta Información puede estar disponible a cualquier persona y puede ser revelada sin afectar al usuario, su familia, su trabajo o su empleador. El conocimiento de esta información no viola los derechos de un individuo a la intimidad, ni expone al usuario, su familia o su empleador a pérdidas financieras, daño en su imagen o cualquier tipo de vergüenza, así como tampoco coloca en ningún tipo de peligro al usuario, su familia o a su empleador.
Confidencial Incluye información cuya divulgación no autorizada, compromiso o destrucción podría ocasionar, ya sea de manera directa o indirecta, efectos adversos en el usuario, su familia o su empleador tales como pérdidas financieras, daño en su imagen o cualquier tipo de vergüenza, así como también puede colocar en algún tipo de peligro al usuario, su familia o a su empleador.
Secreto Información cuya divulgación a personas no autorizadas permite el acceso a secretos personales, familiares o comerciales, así como coloca en grave peligro los intereses del usuario, su familia o su empleador, y al mismo tiempo puede generar graves perjuicios a nivel personal, legal o financiero.
Tabla 3 Clasificación de la Información
Control de Acceso
El control de acceso a la información se realiza siguiendo el modelo Bell-LaPadula [8] [20] con lo cual se buscara garantizar que:
1. Un usuario de un determinado nivel de seguridad no puede leer un objeto perteneciente a un nivel de seguridad más alto (Propiedad de seguridad simple)
2. Un sujeto de un determinado nivel de seguridad no puede escribir un objeto perteneciente a un nivel de seguridad más bajo (Propiedad estrella o de confinamiento).
Este control de acceso debería garantizar que un usuario pueda escribir información únicamente en su nivel de seguridad, con el objetivo de garantizar cierto nivel de integridad en la información (a diferencia del modelo Bell-LaPadula que solo maneja confidencialidad por lo que permite escribir en niveles superiores), y pueda leer información únicamente en su nivel de seguridad o en niveles inferiores.
La Tabla 4 presenta una vista global de las combinaciones posibles. El Usuario 1 tiene acceso al área Personal con nivel Público, el Usuario 2 tiene acceso al área Familiar con nivel Confidencial, y el Usuario 3 tiene acceso al área Empresarial con nivel Secreto.
Clasificación/Área
de Trabajo Personal Familiar Empresarial
Publico Usuario 1
Confidencial Usuario2
Secreto Usuario 3
Tabla 4 Modelo de control
La combinación de las áreas de trabajo y los niveles de confidencialidad, y el modelo de control de acceso resultante generan las siguientes características de seguridad:
Acceso a las Áreas de Trabajo: Por defecto los usuarios no tendrán acceso a ninguna área de trabajo. El administrador de la aplicación deberá asignar a cada usuario, de manera explícita, el acceso a las áreas de trabajo que considere necesarias, lo que le garantizara que cada usuario solamente podrá tener acceso a las áreas de trabajo que le hayan sido asignadas.
Acceso a la Información: Por defecto, cuando un administrador asigna acceso a un usuario a cualquier área de trabajo, dicho usuario podrá acceder a la información pública del área de trabajo. A continuación se describe las implicaciones de cambiar el nivel de acceso de un usuario a la información :
o Publico: El usuario podrá leer y modificar únicamente los archivos públicos del área de trabajo.
o Confidencial: El usuario podrá leer los archivos públicos, así como también podrá leer y modificar los archivos confidenciales del área de trabajo.
o Secreto: El usuario podrá leer los archivos públicos y confidenciales del área de trabajo, así como también podrá leer y modificar los archivos secretos de dicha área.
A diferencia del modelo BLP, un objeto no puede pertenecer en la misma ventana de tiempo a dos áreas de trabajo (de forma simultánea), como el caso Sec,{A,L} en la Figura 16 que permitiría el manejo de dos categorías, A y L, de forma simultánea. De hecho, se quiere evitar este comportamiento por razones fundamentales: (1) en el contexto planteado un usuario maneja información personal, familiar y laboral de forma disyunta, y (2) la mezcla de datos conduce a confusiones que pueden ocasionar fugas de información.
La Figura 17 muestra la política que AndroidBLP soporta. Tanto las operaciones de lectura, como las operaciones de lectura tienen más restricciones que una política BLP, es decir, son un subconjunto de las operaciones permitidas por una política BLP. Estas restricciones adicionales responden mejor a una hipótesis comúnmente aceptada en el caso de dispositivos móviles: los usuarios no tienen conocimientos técnicos y se confunde fácilmente; al restringir las operaciones que pueden ser fuente de dichas confusiones se disminuyen los problemas potenciales. El administrador sería el único con acceso total (Sec,{P,F,L}).
Figura 17. AndroidBLP soporta una política más restringida que la política BLP correspondiente.
A continuación se detallaran las amenazas a las cuales estaría expuesta AndroidBLP, sus requerimientos funcionales y de seguridad.
Sec, {P,F,L}
Sec, {P} Sec, {L}
Conf, {F}
Conf, {P} Conf, {L}
Público Sec, {F}
Lectura: Escritura :
3.3.2 Requerimientos de la Aplicación
Modelo de Amenazas
Para evaluar las amenazas que pueden afectar a AndroidBLP utilizaremos el modelo STRIDE desarrollado por Microsoft [24] que se detalla a continuación:
Amenaza Descripción
Spoofing (Suplantación de identidad)
Suplantar quiere decir adoptar la personalidad de otra persona en un equipo. Un ejemplo de suplantación de identidad es el acceso ilegal a la información de autenticación de otro usuario y el posterior uso de la misma, como el nombre de usuario y la contraseña.
Tampering (Manipular datos)
La manipulación de datos implica la modificación malintencionada de éstos. Algunos ejemplos son la modificación no autorizada de datos persistentes, como los que se mantienen en una base de datos, o la modificación de datos durante su transferencia entre equipos en una red abierta como, por ejemplo, Internet.
Repudiation (Repudio)
Las amenazas de repudio son aquellas en las que los usuarios niegan la autoría de una acción sin que otras partes puedan probar lo contrario. Por ejemplo, un usuario realiza una operación ilegal en un sistema sin que exista la posibilidad de realizar un seguimiento de la misma. De igual forma, el no rechazo se refiere a la posibilidad de un sistema de contrarrestar las amenazas de repudio. Por ejemplo, un usuario que adquiere un artículo tiene que firmar un recibo al entregarse dicho artículo. De esta forma, el proveedor puede utilizar el recibo firmado como prueba de la entrega del paquete.
Information disclosure (Divulgación de
información)
Las amenazas de divulgación de información suponen la revelación de información a individuos que no deben tener acceso a la misma. Por ejemplo, la posibilidad de que los usuarios lean un archivo al que no se les ha proporcionado acceso, o la posibilidad de un intruso de leer datos que se están transfiriendo entre dos equipos.
Denial of service (Denegación de servicio)
Los ataques por denegación de servicio (DoS) ocasionan la pérdida de servicio a los usuarios válidos, por ejemplo, deshabilitando temporalmente un servidor Web. Debe protegerse contra determinados tipos de amenazas DoS a fin de mejorar la disponibilidad y fiabilidad del sistema.
Elevation of privilege (Elevación de privilegios)
En este tipo de amenaza, un usuario sin privilegios obtiene acceso con privilegios y, por tanto, la capacidad de poner en peligro o destruir todo el sistema. Un tipo de amenaza de elevación de privilegios es la situación en la que un agresor burla todas las defensas del sistema con éxito y se integra en la parte del sistema de confianza.
Tabla 5 “The STRIDE Threat Model” de Microsoft, tomado de [24]
Basándonos en el modelo anteriormente descrito, a continuación se describen las amenazas a las que estará expuesta AndroidBLP y la forma en la cual serán manejadas. Las amenazas que no se encuentren en este listado están fuera del alcance de este proyecto.
Amenaza Descripción Control
Spoofing (Suplantación de identidad) Compromiso del usuario y contraseña de acceso a la aplicación.
No hay control
Ataque por fuerza bruta para
conocer la contraseña de un usuario,
Bloqueo del usuario después de 3 intentos errados. Técnicas de Desarrollo seguro de aplicaciones.
Tampering (Manipular datos)
Modificación no autorizada de los archivos.
Dentro de la aplicación no se podrá acceder a ningún archivo sin una previa validación de las políticas de seguridad definidas por el administrador.
Detección de cambios en la integridad de los archivos realizados por fuera de la aplicación.
Cifrado de los datos.
Bitácora de las acciones realizadas por el usuario. Generación de copias de seguridad cifradas. Técnicas de Desarrollo seguro de aplicaciones.
Repudiation
(Repudio) Ejecución de acciones no autorizadas.
Information disclosure (Divulgación de información) Divulgación de información al ser extraída de la aplicación.
No hay control
Divulgación no autorizada de información entre áreas de trabajo o niveles de
confidencialidad.
No se podrá acceder a ningún archivo sin una previa validación de las políticas de seguridad definidas por el administrador. Cifrado de los datos.
Técnicas de Desarrollo seguro de aplicaciones.
Denial of service (Denegación de servicio)
Bloqueo de los usuarios al ingresar la contraseña errada 3 veces.
No hay control
Elevation of privilege
(Elevación de privilegios)
Elevación de privilegios de los usuarios,
cambiando de área de trabajo o nivel de
confidencialidad.
Toda asignación de área de trabajo o nivel de confidencialidad podrá ser realizada únicamente por el administrador de la aplicación.
Bitácora de las acciones realizadas por el usuario. Técnicas de Desarrollo seguro de aplicaciones.
Tabla 6 Análisis de Amenazas
Requerimientos Funcionales
AndroidBLP contara con dos módulos, el de administración y el de usuario, que tendrán las siguientes funcionalidades:
Módulo de Administración:
Funcionalidad Descripción
Gestión de Usuarios
Creación, modificación y eliminación de las cuentas los usuarios en la aplicación.
Bloqueo y desbloqueo de dichas cuenta de usuario.
Asignación/remoción de los usuarios a las áreas de trabajo y niveles de confidencialidad.
Gestión de Archivos
Cambio de área de trabajo para los archivos.
Cambios del nivel de confidencialidad de los archivos.
de Bitácoras (logs)
Limpieza bitácoras de la aplicación.
Gestión Copias de Respaldo
(Backups)
Generación copia de respaldo de los datos contenidos en la aplicación, configuración, usuarios y derechos asignados.
Restaurar las copias de respaldo.
Gestión de Configuración
Tiempos de valides de la contraseñas Longitud de las contraseñas
Complejidad de las contraseñas Tamaño de las bitácoras
Acción a tomar cuando se alcance el tamaño definido de las bitácoras.
Tabla 7 Funcionalidades - Modulo Administración
Módulo de Usuario:
Funcionalidad Descripción
Gestión de Archivos
Lectura, creación, modificación y eliminación de archivos.
Gestión de Contraseñas
Cambio de contraseña del usuario.
Tabla 8 Funcionalidades - Modulo Usuario
Los requerimientos funcionales para cada módulo de la aplicación serán los siguientes:
ID Funcionalidad Requerida
Objetivo
RF1 Gestión de
Usuarios - Creación
Crear usuarios nuevos incluyendo datos como nombre, userid, contraseña, área de trabajo y nivel de confidencialidad.
RF2 Gestión de Usuarios - Modificación
Modificar los datos del usuario incluyendo nombre, contraseña, estado de la cuenta (bloqueada o desbloqueada), área de trabajo y nivel de acceso.
RF3 Gestión de Usuarios - Eliminación
Eliminar un usuario en la aplicación.
Archivos- Cambio Área de Trabajo
RF5 Gestión de Archivos- Cambio nivel de confidencialidad
Reasignar el nivel de confidencialidad de un archivo
RF6 Gestión de
Bitácoras - Lectura
Mostrar las bitácoras donde esta registradas las actividades de los usuarios.
RF7 Gestión de Bitácoras – Limpieza
Eliminar el contenido de las bitácoras previa confirmación.
RF8 Gestión Copias de Respaldo-
Generación
Generar copias de respaldo, en un archivo externo, de los datos contenidos en la aplicación.
RF9 Gestión Copias de Respaldo-
Restauración
Restaurar en la aplicación la copia de respaldo contenida en un archivo externo.
RF10 Gestión de Configuración
Definir los valores de Tiempos de valides , Longitud y complejidad de las contraseñas, así como el tamaño de las bitácoras y la acción a tomar cuando se alcance el dicho tamaño
Tabla 9 Requerimientos Funcionales de la Aplicación
Requerimientos de Seguridad
Los requerimientos de seguridad de AndroidBLP serán los siguientes:
ID Categoría Descripción
RS1 Cifrado Todos los datos de usuario que en la aplicación no sean explícitamente clasificados como públicos deben estar cifrados.
RS2 Mediación Completa
Dentro de la aplicación cada que el sistema reciba un requerimiento por parte de un usuario para realizar cualquier acción, se debe verificar que dicho usuario se encuentre activo y tenga los derechos requeridos (validación de las políticas de seguridad definidas por el administrador) Fuera de la aplicación no se podrá garantizar la existencia de la Mediación Completa para el acceso a los archivos.
RS3 Verificación Integridad de Archivos
Dentro de la aplicación, y con el objetivo de detectar Manipulación de los datos fuera de la misma (Tampering), se debe verificar la integridad de cada archivo antes de abrirlo.
RS3 Validación de
Entradas
No se deberá utilizar directamente información provista por el usuario en ninguna operación dinámica.
Deberá existir una rutina de validación de datos de entrada centralizada para la aplicación.
Todo lo que no esté expresamente aprobado, es negado.
Cada entrada debe ser validada y se debe permitir únicamente el tipo de datos de entrada definido y con la longitud definida.
RS4 Manejo de Logs
Restringir el acceso a los logs solo a usuarios autorizados. Registrar en el log todas las fallas de validación.
Registrar en el log todos los intentos de autenticación, en particular los fallidos.
Registrar en el log todas las fallas en los controles de acceso. Registrar en el log todos los eventos de intento de evasión de
controles, incluyendo cambios en el estado de la información no esperados.
Registrar en el log todas las excepciones del sistema.
Registrar en el log todas las funciones administrativas, incluyendo cambios en la configuración de seguridad.
Utilizar una función de hash para validar la integridad de los logs.
RS5 Manejo de Errores
Cuando se presente un error este debe ser manejado de tal manera que no permita la ejecución de actividades no autorizadas.
Por defecto, al presentarse un error el sistema debe comportarse como si la operación que lo genero NO estuviera autorizada para ser realizada.
Tabla 10 Requerimientos de Seguridad en la Aplicación
3.4 ARQUITECTURA DE LA SOLUCIÓN
Esta sección presenta el diseño del sistema, por medio de diagramas de casos de uso, diagrama de clases y diagramas de secuencias. También presenta el diseño de seguridad planteado para responder al objetivo principal, permitir al usuario controlar las características y políticas de confidencialidad sobre sus datos.
3.4.1 Diseño del Sistema
Con el objetivo de describir el diseño del sistema utilizaremos diagramas UML de Casos de Uso, de Clase y de Secuencias.
3.4.1.1 Diagrama de Caso de Uso
Un diagrama de caso de uso es utilizado para representar la interacción del usuario con el sistema y que acciones realiza este para cumplir con sus objetivos de diseño.
Las acciones más importantes que usuario puede realizar en AndroidBLP son:
Configuración Inicial de la Aplicación, si es el usuario administrador Iniciar sesión en la aplicación
Crear nuevos usuarios, si es el usuario Administrador Cambiar su contraseña
Importar Archivo Abrir Archivo Eliminar Archivo
Las acciones nombradas anteriormente se muestran en los siguientes diagramas de Caso de Uso.
Figura 19 Diagrama Caso de Uso para inicio de sesión
Figura 21 Diagrama Caso de Uso para cambio de password
Figura 23 Diagrama Caso de Uso para abrir archivo
3.4.1.2 Diagrama de Clases
Un diagrama de clases es utilizado para representar la estructura del sistema con la ayuda de clases, atributos, operaciones en los atributos y la relación entre las diversas clases. La Figura 25 presenta las clases utilizadas por la funcionalidad de la aplicación.
A continuación se realiza un resumen de cada una de las clases representadas en la Figura 25. LoginActivity: Esta actividad es utilizada para cargar la aplicación y permitir los datos de inicio de sesión del usuario.
Users: En esta clase se realizan las acciones de verificación de la existencia del usuario, así como también la creación, cambio de contraseña y eliminación de los usuarios. Aquí se cargan desde la base de datos o se mantiene hasta que se almacena en la base de datos, la información del usuario y las claves de acceso a los archivos cifradas con AES utilizando como clave valores derivados del password del usuario.
PassphraseWrappedKEKStruct: Esta clase es la encargada de almacenar y manejar las claves de cifrado intermedias del usuario.
KEKWrappedVolumeKeyStruct: Esta clase es la encargada de almacenar y manejar las claves de cifrado de las diferentes áreas y clasificaciones.
FileBrowser: Cuando el usuario ha iniciado sesión mediante esta clase se le muestra las áreas, clasificaciones y archivos a los cuales tiene derecho a acceder.
Files: En esta clase se realizan las acciones de manejo de archivos, incluyendo la importación desde el sistema de archivo del dispositivo Android, la apertura de archivos protegidos por la aplicación y el borrado de los mismos. Durante las operaciones de importación se realizan cifrado de los archivos y durante las operaciones de apertura se realiza descifrado.
SqlManager: Esta clase se encarga de manejar todas las operaciones relacionadas con el motor de base de datos SQLlTE como son la creación, actualización y eliminación de registros generadas por el manejo de usuarios y archivos.
AesCbcWithIntegrity: Esta clase es la encarga de manejar todas las operaciones de cifrado y descifrado incluyendo verificación de integridad del resultado, generación aleatoria y derivación de claves.
SecretKeys: Esta clase se utiliza para almacenar de manera temporal las claves de confidencialidad e integridad que son utilizadas por AesCbcWithIntegrity en los procesos de cifrado y descifrado de datos.
CipherTextIvMac: Esta clase se utiliza por AesCbcWithIntegrity para almacenar de manera temporal el resultado de las operaciones de cifrado, incluyendo el vector de inicialización utilizado (Iv) y el valor de verificación utilizado para comprobar la integridad de los datos cifrados.
LinuxPRNSecureRandom,PrngFixes,LinuxSecureRandomProvider: Estas clases son utilizadas por AesCbcWithIntegrity para la generación segura de valores aleatorios que son utilizados como base en la generación y derivación de claves.
3.4.1.3 Diagrama de Secuencia
Los diagramas de secuencia son usados para mostrar la interacción y los mensajes enviados entre los objetos durante la ejecución de alguna funcionalidad.
Las interacciones más importantes que la aplicación realiza son:
Configuración Inicial de la Aplicación, si es el usuario administrador Iniciar sesión en la aplicación
Crear nuevos usuarios, si es el usuario Administrador Cambiar su contraseña
Importar Archivo Abrir Archivo Eliminar Archivo
En los siguientes diagramas de secuencia se puede ver la interacción y los mensajes que son intercambiados entre el usuario, el dispositivo Android, la aplicación, el sistema de archivo y el motor de base de datos SQLITE.
Figura 27 Diagrama de Secuencia - Inicio de Sesión
Figura 29 Diagrama de Secuencia - Cambio de Contraseña
Figura 31 Diagrama de Secuencia - Abrir Archivo
3.4.2 Diseño de Seguridad
Es este sección detallaremos la arquitectura y el funcionamiento de las controles de seguridad incluidos en el sistema, específicamente la protección criptográfica de datos y el control de acceso, con el fin de dar cumplimiento a los objetivos planteados.
3.4.2.1 Áreas de Trabajo y Niveles de Confidencialidad
Debido a los requerimientos definidos en la Tabla 2 “Áreas de Trabajo”, en la Tabla 3 “Clasificación de la Información” y en la Tabla 4 “Modelo de control”, en la arquitectura de seguridad se definió la combinación de Área de Trabajo y Nivel de Confidencialidad bajo el nombre genérico de “Volumen”.
La definición Volúmenes (combinación de Área de Trabajo y Nivel de Confidencialidad) permite la aplicación de manera consistente en cada uno de ellos de las medidas protección que sean definidas, tales como cifrado y control de acceso.
A continuación se establecen los “Volúmenes” definidos para la aplicación.
Área de Trabajo Clasificación de la Información Nombre del Volumen Personal
Publico PP
Confidencial PC
Secreto PS
Familiar
Publico FP
Confidencial FC
Secreto FS
Empresarial
Publico EP
Confidencial EC
Secreto ES
Tabla 11 Definición de Volúmenes
3.4.2.2 Autorización
Para implementar el modelo de control de acceso descrito en la sección 3.2 es necesario asignar a un usuario una clase de seguridad. La clase de seguridad representa el nivel de acceso que tiene el usuario sobre un volumen y es representada como un atributo almacenado en el campo UserRights de la clase Users.
Los atributos son valores predefinidos que no pueden ser cambiados por el usuario del dispositivo, y la asignación de los mismos a los usuarios es controlada por el administrador de la aplicación.
