Diseño de Sistemas Operativos. Trabajo 1. El Proyecto Android. Miguel Jiménez López Juan Hernández García Víctor Manuel Fernández Castro

Transcripción

1 Diseño de Sistemas Operativos Trabajo 1 El Proyecto Android Miguel Jiménez López Juan Hernández García Víctor Manuel Fernández Castro Abril de 2013

2 El Proyecto Android Contenido 1. Introducción Arquitectura del sistema operativo Máquina virtual Dalvik... 6 Restricciones de Diseño... 6 El Formato.dex... 7 El Cigoto Bloques de construcción... 7 Actividades (activities)... 8 Servicios (services)... 8 Proveedores de contenido... 8 Receptores de difusión (broadcast receivers)... 9 Activando componentes Ciclo de vida de una actividad Ciclo de vida de una aplicación Gestión de memoria Seguridad en Android Sistema de seguridad Arquitectura del sistema de seguridad Seguridad a nivel de sistema y de kernel Seguridad a nivel de usuario Actualizaciones Bibliografía Autores: Miguel Jiménez López Juan Hernández García Víctor Manuel Fernández Castro 2

3 1. Introducción El avance de la tecnología móvil en la última década ha sido espectacular. Todos podemos recordar los primeros teléfonos móviles, esos grandes aparatos que servían casi exclusivamente para mandar y/o recibir llamadas y mensajes. Con el paso de los años fueron evolucionando y se añadieron nuevas funcionalidades como la capacidad de capturar y almacenar imágenes, transferencia de datos, reproducción de música, etc. En este ambiente comienzan a aparecer las primeras rudimentarias aplicaciones, que tenían como meta principal dotar al dispositivo de una funcionalidad añadida que lo convirtiera en algo más que un simple teléfono. En el año 1994 aparece el primer smartphone de la historia, el IBM Simon. Como muchas de las cosas adelantadas a su tiempo, este teléfono paso desapercibido y no consiguió encontrar un lugar en el mercado. Nokia dio una oportunidad a estos nuevos dispositivos en el 2002 con el Nokia 7650, oportunidad que no cuajó en el mercado por su elevado precio inicial (600 ). En los años posteriores hasta el 2007 hubo una tendencia clara hacia la reducción de tamaño de los dispositivos y la incorporación de más y más funcionalidades mediante aplicaciones. Los denominados teléfonos inteligentes empiezan a encontrar su nuevo nicho de mercado y los sistemas operativos encargados de su funcionamiento comienza a aflorar y evolucionar. El 5 de noviembre de 2007, Google presenta oficialmente el proyecto Android, aunque este ya existía desde Android se presenta como una plataforma software de código abierto basado en Linux que incluye un sistema operativo para dispositivos móviles. Tan sólo siete días más tarde, Google lanza una primera versión del emulador de Android, junto con una aplicación, para que cualquier persona pudiera ver cómo era este nuevo sistema operativo y, lo más importante, que los programadores comenzasen a desarrollar aplicaciones para el mismo. El Android Market es inaugurado el día 28 de Agosto de 2008, dando un fuerte empujón a Android y abriéndole numerosas puertas comerciales. Posteriormente el Android Market pasó a ser llamado Google Play, y a fecha del 1 de Enero del 2012 contaba ya con más de aplicaciones. El crecimiento de número de aplicaciones ha sido exponencial tras el paso de los años, y se estima que en el 2014 se habrá superado ya el millón de aplicaciones. Volviendo a los orígenes, el 23 de Septiembre de 2008 ve la luz el HTC G1, smartphone con la primera versión de Android. De esta primera versión se destacaron sobre otras características la completa integración con todos los servicios suministrados por Google y su navegador compatible con HTML y XHTML. A partir de este momento se comienza a trabajar en nuevas versiones de Android para no sólo la instalación en smartphone, sino en tablets y todo tipo de objetos integrados en el denominado Internet de las Cosas. Desde el 2008 hasta la fecha han surgido 17 versiones distintas de Android al mercado. Todas ellas (y como detalles 3

4 curioso) han sido nombradas con nombres de postres. La lista de versiones es la siguiente: Apple Pie (v1.0): Tarta de manzana. Banana Bread (v1.1): Pan de plátano. Cupcake (v1.5): Magdalena glaseada. Donut (v1.6): Rosquilla. Éclair (v2.0/v2.1): Pastel francés. Froyo (v2.2) (abreviatura de «frozen yogurt»): Yogur helado. Gingerbread (v2.3): Pan de jengibre. Honeycomb (v3.0/v3.1/v3.2): Panal de miel. Ice Cream Sandwich (v4.0): Sándwich de helado. Jelly Bean (v4.1/v4.2): Judía de gominola. Key Lime Pie (v4.3): Tarta de lima. A día de hoy, Android abarca una amplia sección del mercado y mantiene la inercia necesaria para seguir creciendo mucho más. La integración en las recientes SmartTVs y resto de objetos inteligentes es sólo uno de los muchos campos abiertos y explotables. En este trabajo se pretende aclarar los puntos claves de Android, así como su arquitectura, la máquina virtual Dalvik, componentes de programación, ciclo de vida de aplicaciones y actividad, gestión de memoria y algunas cuestiones de seguridad. Hay mucho que descubrir bajo la carcasa de este androide de Google. Echemos un buen vistazo. 2. Arquitectura del sistema operativo La arquitectura de Android es por capas, donde cada capa software brinda servicios a su capa superior. Todo reposa en una capa donde se encuentran los drivers de Linux, siendo esta de acceso privado. A esta capa la llamaremos Linux Kernel. El resto de capas se detallan a continuación: Aplications: esta capa está formada por un conjunto de aplicaciones base, por defecto. Este conjunto de aplicaciones son el navegador, un cliente de mail, un calendario, un reloj, etc. Son un conjunto de funcionalidades que se considera básico ofrecer. Están escritas en el lenguaje de programación JAVA. Aplication Framework: esta capa es una capa que ofrece servicio a las aplicaciones. En ella encontramos interfaces de acceso público que ayudan a los desarrolladores en el desarrollo de aplicaciones. La idea subyacente es la reutilización de componentes. Esta capa incluye: o Telephony Manager: encargado de la gestión del hardware del teléfono. 4

5 o View System: conjunto de vistas o elementos necesarios para el desarrollo de una aplicación. Esto incluye botones, grills, barras de progreso, cajas de texto, etiquetas de texto, etc. o Content providers: contiene los datos que frecuentemente son compartidos entre aplicaciones, para que estas puedan tener un buen acceso a los mismos. Entre ellos se encuentra la agenda del teléfono. o Resource Manager: administrador de recursos. En los proyectos de aplicaciones móviles tendremos que tener acceso a numerosos recursos, como por ejemplo: cadenas predefinidas, gráficos, colores, etc. Este módulo se encarga de su correcta administración. o Notification Manager: administrador de alertas. A menudo las aplicaciones necesitan mostrar alertas. Estas alertas se muestran en ventanas especiales o elementos específicos. Este módulo se encarga de su correcta gestión. o Activity Manager: administrador de actividades. Las actividades en Android son los procesos en otros sistemas operativos. Las actividades pasan por diversos estados a lo largo de todo su ciclo de vida (como ya se verá más adelante). Este gestor es el que se encarga del correcto flujo de las mismas. o Location Manager: servicio de localización. Encargado de la transferencia de información con un lugar concreto. Esta API ofrece muchas posibilidades (aún por explotar), como la recepción dinámica de información sobre un lugar geográfico donde nos encontramos. Ofrece gran potencia de cara al internet de las cosas. o XMPP Service: servicio de paso de mensajes entre aplicaciones Android. Utilizado, por ejemplo, para paso de información en juegos multijugador. Android Runtime: está compuesta por el núcleo de bibliotecas básicas y la máquina virtual Dalvik (de la que hablaremos en el apartado siguiente). Libraries: conjunto de bibliotecas escritas en C/C++ que dan soporte a desarrolladores. Se accede a ellas por medio de la capa Application Framework. Entre las más relevantes se encuentra SQLite, encargada de la reproducción multimedia de contenido de múltiples formatos. 5

6 3. Máquina virtual Dalvik Java siempre ha sido elogiado por su alta portabilidad entre múltiples sistemas. Esto en parte ha sido gracias a su máquina virtual Java Virtual Machine (JVM). Aunque este éxito es conocido en sus sistemas de sobremesa (JSE) y servidores (JEE), el ecosistema de java para móviles (JME) se queda algo por debajo del rendimiento y comportamiento deseado en un dispositivo portátil. Google tuvo claro que escogería Java como lenguaje de programación, pero también que dejaría de lado JME y JVM en pos de su propia máquina virtual, Dalvik. Al mismo tiempo también decidió no hacer uso de todas las bibliotecas de Java, y utilizar sólo un limitado número de estas, las estrictamente necesarias. Dalvik presenta algunas ventajas en el ámbito de los dispositivos móviles frente a otras máquinas virtuales. A continuación se explicarán algunas de las características de esta máquina virtual de Google. Restricciones de Diseño La plataforma Android fue creada para dispositivos con restricciones de memoria, procesamiento y energía. Los requisitos mínimos para utilizar Android son los siguientes: Características Requerimientos Mínimos Chipset ARM-based Memoria 128 MB RAM; 256 MB Flash Externa Almacenamiento Mini/Micro SD Display Principal QVGA TFT LCD o superior; 16 bit color o superior Teclas de navegación 5 maneras de navegación, con 5 teclas de aplicación, encendido/apagado, cámara y control de volumen. Cámara 2MP CMOS USB Standard mini-b USB interface Bluetooth 1.2 o 2.0 Muchos dispositivos móviles, o casi todos en la actualidad, superan con creces estos requerimientos mínimos. No obstante, la tabla sirve para hacernos una idea de cuán necesario es tener en cuenta la gestión de recursos a la hora de generar programas o aplicaciones para un dispositivo Android. Aparte del control de recursos, ya que habrá muchas aplicaciones en corriendo al mismo tiempo en el dispositivo, será estrictamente necesario que estén correctamente aisladas unas de otras, así como del núcleo, para que no puedan interferir mutuamente. La capa de arquitectura del sistema que llamábamos Android Runtime, debería facilitar o dar soporte para: Limitar velocidad del procesador. Limitar RAM consumida. 6

7 No trabajar con espacio de swap. (Consume demasiado) Control de batería. Servicios aislados unos de otros con posibilidad de compartir datos. Dado que uno de los objetivos es el aislamiento, hacer uso de una máquina virtual parece lo apropiado, sin embargo las máquinas virtuales convencionales no son capaces de encontrar un balance entre todas las características deseadas citadas. Google realiza su máquina virtual cumpliendo las premisas siguientes: Cada aplicación de Android se ejecutará en su propia instancia de Dalvik. Dalvik es compilado, luego se pueden ejecutar varias instancias de Dalvik de manera eficiente. Dalvik ejecuta ficheros con la extensión.dex, formato totalmente optimizado. La máquina virtual Dalvik es basada en registros, y ejecuta clases compiladas por un compilador de java que has sido transformadas correctamente a un fichero formato.dex. No sólo debe ser rápida la ejecución de una máquina virtual, la creación de una nueva instancia de máquina virtual debe serlo igualmente. El Formato.dex La diferencia esencial radica en que, cuando se compila para Java, cada clase se traduce en un fichero.class. Esto significa que si tienes cinco clases, en Java tendrás cinco.class asociados a estas. El formato.dex resume esta información en un sólo fichero, que además facilita la compartición de datos. En la mayoría de los casos se consigue una gran mejora en cuento a tamaño de código ejecutable y eficiencia. El Cigoto Como se ha dicho antes, el tiempo de creación de una nueva instancia de la máquina virtual debe ser corto. Android utiliza el concepto de cigoto para compartir rápidamente datos entre máquinas virtuales y permitir un lanzamiento rápida de nuevas. El cigoto es un proceso de la máquina virtual que se lanza en tiempo de arranque del sistema. Cuando el cigoto ha comenzado, inicializa Dalvik quien a su vez inicializa y precarga las bibliotecas del núcleo. Generalmente estas bibliotecas son de sólo lectura y son fuertes candidatas a ser compartidas entre procesos. En este momento, el cigoto se dedica a escuchar llamadas que indiquen que se requiere su uso para la creación de nuevos procesos mediante una llamada fork(). Crear nuevas instancias de esta manera es una forma rápida de generación de procesos, y el tiempo de comienzo de aplicaciones se minimiza enormemente. 4. Bloques de construcción Los componentes de la aplicación son los bloques esenciales de una aplicación para Android. Cada componente es un punto a través del cual el sistema puede entrar en la 7

8 aplicación, aunque no todos. Algunos son dependientes entre sí, pero cada uno es un objeto propio y juega un papel específico. Todos los bloques definen el comportamiento de la aplicación. Hay cuatro tipos diferentes de bloques, cada uno con su propio propósito y su propio ciclo de vida. Actividades (activities) El componente más común de la plataforma Android. Una actividad representa una pantalla en la interfaz de usuario. Generalmente se muestran a pantalla completa, pero pueden ser ventanas flotantes o aparecer dentro de otra actividad. Las actividades trabajan conjuntamente para ofrecer una experiencia coherente pero son independientes unas de otras. Así, cualquier aplicación puede ejecutar cualquier actividad de otra (siempre que ésta lo permita). Por ejemplo, una aplicación de correo electrónico tendrá una actividad para listar correos, otra para leerlos y otra para redactar uno nuevo; y la aplicación de cámara podría abrir esta última para enviar una foto por correo. Una actividad se implementa como subclase de Activity, y una de las actividades de una aplicación será la principal (equivalente a la clase Main de Java). Servicios (services) Los servicios son componentes que se ejecutan en segundo plano (demonio) para realizar operaciones de larga duración o llevar a cabo un trabajo para otros procesos. No tienen interfaz de usuario. Un servicio puede ser un reproductor de música en segundo plano, que funciona mientras el usuario trabaja en otra aplicación, o un demonio que recibe datos, evitando que se bloquee el explorador de Internet. Los servicios se implementan como subclase de Service y pueden ser ejecutados por otro programa. Proveedores de contenido Los proveedores de contenido administran conjuntos compartidos de datos de aplicación. Permiten almacenar datos en el sistema de archivos, una base de datos SQLite, Internet o cualquier lugar de almacenamiento persistente al que la aplicación tenga acceso. A través de ellos, otras aplicaciones pueden consultar o modificar los datos (con los permisos necesarios). Por ejemplo, Android proporciona un proveedor de contenido que almacena los contactos de la agenda del usuario. Sin embargo, un proveedor de contenido se puede utilizar para almacenar datos privados. Por ejemplo, un bloc de notas puede utilizar uno de ellos para almacenar notas, aunque no se vayan a compartir. 8

9 Los proveedores de contenido se implementan como subclase de ContentProvider y deben respetar una serie de APIs para que otras aplicaciones puedan acceder a sus datos. Receptores de difusión (broadcast receivers) Los receptores de difusión son componentes que responden a eventos lanzados en todo el sistema. Muchos de estos eventos son producidos por Android, como una señal de que se apaga la pantalla, la batería se está agotando o se ha capturado una la pantalla. Las aplicaciones también pueden lanzar difusiones de este tipo, tales como la descarga de un archivo, que está disponible para ser utilizado por otros programas. Los receptores no tienen interfaz de usuario pero permiten crear notificaciones en la barra de estado para avisar al usuario. Normalmente los receptores son simplemente puertas a otros componentes que atienden al evento, y suelen realizar una mínima cantidad de trabajo. Un receptor de difusión se implementa como subclase de BroadcastReceiver y cada evento se entrega como un objeto Intent. Un aspecto único del diseño de Android es que cualquier aplicación puede iniciar un componente de otra aplicación. Por ejemplo, si queremos capturar una foto con la cámara del dispositivo, no es necesario que escribamos una actividad que lo haga sino que basta con utilizar la actividad correspondiente de la aplicación Cámara del aparato. No es necesario incorporar ni enlazar el código de aplicación de la cámara, tan sólo hay que iniciar la actividad, y la foto tomada se devuelve a la aplicación. De cara al usuario, la actividad de la cámara simplemente será una actividad más en la aplicación. Cuando Android inicia un componente, se inicia un nuevo proceso para la aplicación (si no estaba abierta) e instancia los objetos necesarios. Si una actividad llama a otra de otra aplicación, no se ejecuta un nuevo proceso sino que la actividad se instancia en el mismo proceso. Por lo tanto, a diferencia de la mayoría de sistemas, en Android las aplicaciones no tienen un solo punto de entrada. Ya que el sistema ejecuta cada aplicación en un proceso aparte, con un usuario aparte y permisos que restringen el acceso a otras aplicaciones, un programa no puede activar directamente un componente de otra aplicación. Por supuesto, Android sí puede, de modo que lo haremos informando al sistema del componente que queremos iniciar. Activando componentes Las actividades, los servicios y los receptores de difusión se activan mediante mensajes asíncronos llamados intentos (Intents), que sirven para enlazar componentes entre sí en tiempo de ejecución. Podemos entenderlos como mensajeros que solicitan una acción en otros componentes. 9

10 Los intentos se instancian como objetos de Intent, que definen un mensaje para activar un componente o un tipo de componente (intentos explícitos o implícitos, respectivamente). Para las actividades y los servicios, los intentos definen la acción a realizar (ver o enviar algo, por ejemplo), y pueden especificar la dirección de los datos objeto (que el componente llamado pueda necesitar). En algunos casos podemos ejecutar una actividad para recibir un resultado, por ejemplo, si abrimos la agenda para que el usuario seleccione un contacto, el intento de retorno incluirá la dirección del contacto elegido. Para los receptores de difusión, los intentos únicamente definen el aviso que se está emitiendo. En el caso de proveedores de contenido, no se activan por intentos, sino que se activan cuando son el destino de un resolutor (ContentResolver). Éste administra todas las transacciones directas con los proveedores de contenido, de forma que el componente maestro lo hace a través del resolutor, creando una capa de abstracción con el proveedor de contenido, por seguridad. 5. Ciclo de vida de una actividad Las actividades en Android se gestionan como una pila de actividades. Cuando una actividad se inicia se coloca en el top de la pila y se convierte en actividad en ejecución. La actividad anterior se mantiene debajo en la pila, y no volverá al primer plano mientras la nueva exista. Una actividad tiene esencialmente cuatro estados: Activa. En primer plano en la pantalla (en el top de la pila), Pausada. La actividad ha perdido el foro pero sigue siendo visible, por ejemplo si ha aparecido sobre ella una ventana flotante u otra actividad transparente. Una actividad pausada se mantiene completamente viva (mantiene su estado y permanece unida al gestor de ventanas), pero puede ser matada por el sistema en condiciones de poca memoria. Detenida. La actividad ha sido ocultada completamente por otra actividad. Mantiene su estado aun siendo no visible, pero se eliminará si hay poca memoria antes que una actividad pausada. Si una actividad está pausada o detenida, el sistema podrá eliminarla de la memoria bien pidiéndole que se cierre o bien matando a su proceso. La próxima vez que se abra deberá ser completamente reiniciada y se restaurará su estado anterior. El siguiente diagrama muestra el flujo por el que pasa una actividad: 10

11 Hay tres bucles importantes dentro del ciclo de una actividad: Toda la vida de una actividad ocurre entre la primera llamada a oncreate(bundle) y la llamada final a ondestroy(). En la primera se establecerá toda la configuración global del estado de la actividad, y se liberará en la última. Por ejemplo, si vamos a tener una hebra en segundo plano para descargar datos de la red, la podemos crear en oncreate() y la detendremos en ondestroy(). El tiempo visible es el que sucede entre una llamada a onstart() y su correspondiente onstop(). Durante este tiempo el usuario puede ver la actividad en la pantalla, aunque pueda no ser en primer plano e interactuando con él. En este tiempo podremos mantener los recursos necesarios para mostrar la actividad. El tiempo en primer plano de una actividad ocurre entre una llamada a onresume() y otra a onpause(). En todo ese tiempo la actividad se encuentra sobre todas las demás y en interacción con el usuario. Estos métodos han de ser ligeros, porque las actividades frecuentemente serán pausadas y reactivadas, como cuando se bloquea la pantalla o cuando la actividad envía un intento a otra. La gestión del tiempo visible es muy importante en el diseño de una actividad, ya que garantiza que el usuario tenga la sensación de que la aplicación está siempre viva y no pierde su progreso. El tiempo visible es el acotado por el rectángulo de la siguiente ilustración: 11

12 Hay algunos casos en los que una actividad es detenida y reiniciada, como en que el usuario abra Aplicaciones recientes, se realice una acción que desencadene la apertura de otra actividad, o que el dispositivo reciba una llamada mientras se usa la aplicación. 6. Ciclo de vida de una aplicación El sistema operativo Android intenta mantener los procesos de aplicación todo el tiempo posible, pero al final tendrá que eliminar procesos antiguos cuando quede poca memoria, en beneficio de los nuevos. Hay cuatro estados en general en los que un proceso puede estar, en base a las actividades que aloja. En orden de importancia son las siguientes: 1. Actividad en primer plano. La actividad con la que está interactuando el usuario, es la más importante. Sólo se eliminará como último recurso, si se agota la memoria. En ese caso el dispositivo habría alcanzado la máxima paginación, y es necesario para mantener la capacidad de respuesta del sistema. 2. Actividad visible. La actividad aparece en pantalla pero no está en primer plano, se considera muy importante y no se mata a menos que se requiera memoria para la actividad que está actualmente en primer plano. 3. Actividad de fondo. No es visible por el usuario, está en pausa. No se considera crítica, de forma que el sistema podrá eliminar el proceso para dar memoria a procesos visibles o en primer plano. Si esto ocurre, cuando el usuario vuelva a ella se volverá a crear con el estado que tenía anteriormente. 4. Proceso vacío. Es uno que no alberga actividades ni otros componentes, como servicios o receptores de difusión. Son más rápidos de eliminar cuando la memoria escasea. 7. Gestión de memoria Una idea muy extendida en Google, recordada por Patrick Dubroy en una charla en Google I/O llamada Gestión de memoria en aplicaciones Android [4] es que el software se expande para llenar toda la memoria disponible. 12

13 En otras palabras, debemos olvidarnos del concepto de memoria disponible y de la necesidad de cerrar aplicaciones por nuestra cuenta para liberarlas. Tanto en Android como en otros muchos sistemas Unix, la memoria libre es memoria desaprovechada. Cada aplicación en Android funciona en un proceso separado con una instancia de la máquina virtual Dalvik distinta, que funciona sobre el núcleo Linux. La gestión de memoria es responsabilidad del sistema operativo, que se encargará de cerrar los procesos cuando se necesiten sus recursos. Dalvik es una máquina virtual basada en registros (la máquina oficial de Java, HotSpot, está basada en pila), optimiza la velocidad y el espacio en memoria, además de asegurar que se puede ejecutar múltiples instancias de ella eficientemente. Las tareas de bajo nivel, como gestión de hebras y de memoria, recaen sobre Linux. Todo el hardware y los servicios del sistema son administrados a través de Dalvik, lo cual proporciona a los desarrolladores de aplicaciones Android una capa de abstracción que les evita preocuparse de la implementación hardware. Android se ocupa de tener memoria disponible para los procesos que la requieran, para lo cual establece una prioridad entre los procesos basándose en su ciclo de vida. Cuando se necesite memoria, el sistema operativo detendrá los procesos en orden de precedencia; si dos procesos tienen la misma prioridad, se eliminará primero el que haya estado más tiempo en prioridad baja. Como decíamos más arriba, la selección del proceso a eliminar está relacionada con el estado de la actividad, concretamente se eliminará primero el proceso con menor prioridad, es decir, empezando por el proceso vacío. Android administra las aplicaciones en ejecución, por tanto el usuario no se tiene que preocupar de cerrarlas manualmente. Es más, es contraproducente cerrar programas por cuenta propia sólo por mantener memoria libre porque, por un lado, no vamos a tener más rendimiento Dalvik proporciona una cantidad fija de memoria heap a cada proceso, del orden de 48 MB pero dependiendo del dispositivo y, por otro, vamos a forzar al sistema a cargar la aplicación desde cero, con un consumo superfluo de tiempo y batería. 8. Seguridad en Android Las plataformas móviles necesitan garantizar unos niveles de seguridad que protejan los datos de los usuarios así como el hardware del dispositivo y la red. Es por este motivo que Android implementa una arquitectura en varias capas para el sistema de seguridad que permite, además, una mayor flexibilidad. Hay que tener en cuenta que las plataformas móviles trabajan constantemente con la red y son objetivos potenciales para muchos atacantes ya que el dispositivo, en general, contiene información privada e importante del usuario. Antes de comenzar a describir las características del sistema de seguridad, se detallan rápidamente las principales características de cualquier sistema Android: 13

14 1. Se ejecutan en una multitud de plataformas hardware por lo que el control de seguridad es algo más complicado. 2. El sistema operativo en el que se basa es un kernel de Linux. Éste es quién controla todos los recursos hardware del sistema móvil. 3. Cualquier aplicación desarrollada para Android requiere un entorno de ejecución que la soporte: Android Runtime. Básicamente, aportan un conjunto de servicios necesarios para que las aplicaciones funcionen correctamente. 4. Aplicaciones de Android, que pueden ser desarrolladas por los usuarios o bien venir pre-instaladas en el sistema y que extienden la funcionalidad del kernel. 5. Además de las aplicaciones anteriormente mencionadas, Google también proporciona distintos servicios en la nube a través de Google Play. Es importante tener en cuenta todos los elementos que interactúan en un sistema Android ya que las reglas o mecanismos de seguridad deberán proteger de cualquier tipo de ataque. Sistema de seguridad Arquitectura del sistema de seguridad Los objetivos del sistema de seguridad son: Proteger los datos del usuario. Gestionar de forma segura los recursos del sistema. Aislar las aplicaciones. Para dar soporte a todos los objetivos, Android implementa una serie de mecanismos: Seguridad a nivel del sistema operativo. Técnica de Sandbox para proporcionar el aislamiento a nivel de aplicación. Comunicación segura entre procesos. Utilización de firmas digitales para las aplicaciones. Permisos a nivel de aplicación y de usuario. A continuación, se muestra una imagen con la estructura en capas del software de un sistema Android. Cada capa supone que la capa inmediatamente inferior es segura. 14

15 En las secciones posteriores, se detallarán los aspectos más relevantes del sistema de seguridad. Seguridad a nivel de sistema y de kernel Android se basa en un sistema operativo Linux. Hay que tener en cuenta que Linux lleva ya muchos años en uso por lo que está bastante actualizado en muchos aspectos de seguridad. No obstante, debido a las características peculiares que introducen las plataformas móviles, Android introduce algunas mejoras: Modelo de permisos basado en el usuario. Aislamiento de procesos. Mecanismo de comunicación de procesos seguro (IPC). Capacidad de eliminar cualquier parte no necesaria y potencialmente insegura del kernel. Evidentemente, se proporcionan los mecanismos necesarios para la gestión de recursos por parte de múltiples usuarios. A nivel de kernel también se implementa la técnica de Sandbox para proteger las aplicaciones que se ejecutan en el espacio del sistema operativo. La implementación del sandbox es muy sencilla. Se basa en utilizar la propiedad del kernel de Linux que permite la gestión de diversos usuarios con distintos permisos. 15

16 Android ejecuta cada aplicación con un identificador de usuario distinto y por tanto, con permisos y espacios de usuario distintos también. Esto hace que las aplicaciones estén aisladas y por tanto, impide los accesos indeseados. Evidentemente, este esquema no es perfecto y también puede ser vulnerado. Sin embargo, se basa en un kernel de Linux que tiene ya muchos mecanismos de seguridad que dificultan los ataques y posibles brechas de seguridad. Como medida de seguridad adicional, la partición del sistema solo contiene el código de Android y algunas bibliotecas importantes de orígenes confiables. No se permite la ejecución de ningún software no seguro y el acceso a la misma se realiza en modo de solo escritura. Todo esto proporciona un arranque seguro. Los ficheros en Android están soportados de la misma forma que en los sistemas UNIX y por tanto, existe un mecanismo de permisos que los protege. De la misma manera, se incorporan bibliotecas específicas que permiten el uso de primitivas criptográficas como: AES, RSA, DSA y SHA que aumentan la seguridad del sistema completo. Los mecanismos de seguridad en cuanto al manejo de memoria varían en función de la versión de Android que consideremos. No obstante, detallamos los más relevantes que ayudan a la prevención de: Desbordamiento de buffer. Desbordamiento de enteros. Doble liberación de memoria. Vulnerabilidades en el formateo de cadenas de caracteres. Puede encontrar más información en [7]. Seguridad a nivel de usuario El sistema de ficheros en Android está totalmente encriptados de forma que es necesario conocer la contraseña para poder acceder a los mismos. La clave de cifrado se deriva de la contraseña de usuario y se le aplica el algoritmo AES128. Además, la seguridad se refuerza generando semillas aleatorias SHA1 y utilizando el algoritmo PBKDF2 antes de descifrar la clave. Además, cada dispositivo puede protegerse con una contraseña de manera que el acceso al mismo está limitado a aquellos que la conocen. A partir de la versión 2.2 de Android, se proporciona un sistema de administración de dispositivos a nivel de sistema en la API. Esto permite que se puedan incluir mecanismos extras de seguridad a la hora de acceder a los dispositivos (por ejemplo por medio de contraseñas alfanuméricas o PIN numéricos). Android permite el almacenamiento y uso de firmas y certificados digitales que son de confianza para realizar operaciones críticas como por ejemplo, accesos por SSH. Gracias a estos certificados, se agiliza el proceso de autenticación que requieren algunos servicios y permite validar que la entidad que los ofrece es de confianza y que por tanto, no habrá ningún problema de seguridad. 16

17 Android proporciona mecanismos para el acceso a VPNs. A través de un cliente VPN, se pueden utilizar servicios basados en PPTP, L2TP, IPSec y VPN. Esto añade un nuevo nivel de seguridad ya que ciertas aplicaciones solo deberían ejecutarse en entornos (redes) confiables. Gracias a la VPN esto es posible. Como se ha dicho con anterioridad, cada aplicación está aislada en un Sandbox por lo que tiene limitado los recursos a los que puede acceder. Existen muchos recursos que solo son accesibles a través del sistema operativo (cámara, GPS, Bluetooth, SMS, Red, etc). Cada aplicación debe declarar los permisos que necesitará para su ejecución, esto se hace a través de un manifiesto que el usuario deberá confirmar a la hora de instalar la misma. Si el usuario acepta el manifiesto, se le concederán todos los permisos necesarios a dicha aplicación (no es posible conceder o denegar permisos individuales). Obviamente, si se elimina o desinstala una aplicación se borran todos los permisos concedidos por lo que en una actualización posterior deberemos aceptar de nuevo el manifiesto de la aplicación. Otros mecanismos de seguridad que implementa Android a parte de los proporcionados por el kernel de Linux a nivel de proceso son: Binder: Está basado en la capacidad de llamada a un procedimiento remoto cuando se necesita un elevado rendimiento en un proceso. 17

18 Servicios: Proporcionan interfaces específicas lo cual aumenta la seguridad. Intents: Representa la 'intención' de hacer algo. Esto permite que el sistema valide las peticiones de forma que aumente la seguridad. ContentProviders: Es un almacén de datos que proporciona acceso compartido y seguro entre aplicaciones. Una aplicación debe conceder explícitamente permisos para que otra distinta pueda acceder a datos incluidos en un ContentProvider. Además, Android también protege los datos de dispositivos de entrada y metadatos ya que contienen información sensible acerca del usuario. Una aplicación solo podrá acceder a aquellos servicios a los que se le haya autorizado (generalmente al aceptar en el manifiesto de instalación). Las aplicaciones deben ir firmadas de manera que a la hora de la instalación se pueda identificar el autor de la aplicación así como los permisos que requiere para su ejecución. Ninguna aplicación no firmada se instalará en un sistema Android al menos desde una fuente confiable como Google Play. Actualizaciones Otra forma de proporcionar mayor seguridad en los entornos Android es por medio de las actualizaciones. Por medio de estas, se solucionan muchos problemas de seguridad detectados y se mejora el sistema de seguridad de Android. 9. Bibliografía 1. Android Developer Reference: Application Fundamentals Android Developer Reference: Class Activity Android Developer Reference: Stopping and Restarting an Activity Patrick Dubroy s Conference at Goolge I/O: Memory Management for Android Apps Mobile World: Memory management in Android El Rincón de Android: Gestión de Memoria RAM en Android Android Open Source Project, Security. Consultado el 2/4/