Elementos de Aplicaciones
Android proporciona una plataforma de código abierto y un entorno de aplicación para dispositivos móviles. El sistema operativo central se basa en el kernel de Linux. Las aplicaciones de Android se escriben con mayor frecuencia en el lenguaje de programación Java y se ejecutan en la máquina virtual Dalvik. Sin embargo, las aplicaciones también se pueden escribir en código nativo. Las aplicaciones se instalan desde un solo archivo con la extensión de archivo .apk.
Los principales bloques de construcción de aplicaciones de Android son:
AndroidManifest.xml : el archivo AndroidManifest.xml es el archivo de control que le dice al sistema qué hacer con todos los componentes de nivel superior (específicamente actividades, servicios, receptores de transmisión y proveedores de contenido que se describen a continuación) en una aplicación. Esto también especifica qué permisos son necesarios.
Actividades : una actividad es, por lo general, el código para una única tarea centrada en el usuario. Por lo general, incluye mostrar una interfaz de usuario al usuario, pero no es necesario; algunas actividades nunca muestran las interfaces de usuario. Normalmente, una de las actividades de la aplicación es el punto de entrada a una aplicación.
Servicios : un servicio es un cuerpo de código que se ejecuta en segundo plano. Puede ejecutarse en su propio proceso o en el contexto del proceso de otra aplicación. Otros componentes se "vinculan" a un Servicio e invocan métodos en él a través de llamadas a procedimientos remotos. Un ejemplo de un Servicio es un reproductor de medios: incluso cuando el usuario sale de la interfaz de usuario de selección de medios, es probable que el usuario todavía tenga la intención de que la música siga sonando. Un servicio mantiene la música incluso cuando la interfaz de usuario se ha completado.
Broadcast Receiver : un BroadcastReceiver es un objeto que se instancia cuando el sistema operativo u otra aplicación emite un mecanismo IPC conocido como Intent . Una aplicación puede registrar un receptor para el mensaje de batería baja, por ejemplo, y cambiar su comportamiento en función de esa información.
El modelo de permisos de Android: acceso a las API protegidas
Todas las aplicaciones de Android se ejecutan en un Sandbox de aplicaciones . De forma predeterminada, una aplicación de Android solo puede acceder a una gama limitada de recursos del sistema. El sistema administra el acceso de las aplicaciones de Android a los recursos que, si se usan de manera incorrecta o malintencionada, podrían afectar negativamente la experiencia del usuario, la red o los datos del dispositivo.
Estas restricciones se implementan en una variedad de formas diferentes. Algunas capacidades están restringidas por una falta intencional de API para la funcionalidad sensible (por ejemplo, no hay una API de Android para manipular directamente la tarjeta SIM). En algunos casos, la separación de funciones proporciona una medida de seguridad, como ocurre con el aislamiento del almacenamiento por aplicación. En otros casos, las API confidenciales están destinadas a aplicaciones confiables y están protegidas a través de un mecanismo de seguridad conocido como Permisos.
Estas API protegidas incluyen:
- Funciones de la cámara
- Datos de ubicación (GPS)
- Funciones Bluetooth
- Funciones de telefonía
- Funciones SMS/MMS
- Conexiones de red/datos
Estos recursos solo son accesibles a través del sistema operativo. Para hacer uso de las API protegidas en el dispositivo, una aplicación debe definir las capacidades que necesita en su manifiesto. Todas las versiones de Android 6.0 y superiores usan un modelo de permisos de tiempo de ejecución . Si un usuario solicita una función de una aplicación que requiere una API protegida, el sistema muestra un cuadro de diálogo que solicita al usuario que niegue o permita el permiso.
Una vez otorgados, los permisos se aplican a la aplicación siempre que esté instalada. Para evitar la confusión del usuario, el sistema no vuelve a notificar al usuario sobre los permisos otorgados a la aplicación, y las aplicaciones que están incluidas en el sistema operativo central o empaquetadas por un OEM no solicitan permisos al usuario. Los permisos se eliminan si se desinstala una aplicación, por lo que una reinstalación posterior volverá a mostrar los permisos.
Dentro de la configuración del dispositivo, los usuarios pueden ver los permisos de las aplicaciones que han instalado previamente. Los usuarios también pueden desactivar algunas funciones de forma global cuando lo deseen, como desactivar el GPS, la radio o el wi-fi.
En el caso de que una aplicación intente usar una función protegida que no se haya declarado en el manifiesto de la aplicación, la falla del permiso generalmente dará como resultado que se devuelva una excepción de seguridad a la aplicación. Las comprobaciones de permisos de la API protegida se aplican al nivel más bajo posible para evitar la elusión. En la Figura 2 se muestra un ejemplo de la mensajería del usuario cuando se instala una aplicación mientras solicita acceso a las API protegidas.
Los permisos predeterminados del sistema se describen en https://developer.android.com/reference/android/Manifest.permission.html . Las aplicaciones pueden declarar sus propios permisos para que los usen otras aplicaciones. Dichos permisos no se enumeran en la ubicación anterior.
Al definir un permiso, un atributo de nivel de protección le dice al sistema cómo se debe informar al usuario sobre las aplicaciones que requieren el permiso, o quién puede tener un permiso. Los detalles sobre la creación y el uso de permisos específicos de la aplicación se describen en https://developer.android.com/guide/topics/security/security.html .
Hay algunas capacidades del dispositivo, como la capacidad de enviar intenciones de transmisión de SMS, que no están disponibles para aplicaciones de terceros, pero que pueden ser utilizadas por aplicaciones preinstaladas por el OEM. Estos permisos usan el permiso signatureOrSystem.
Cómo entienden los usuarios las aplicaciones de terceros
Android se esfuerza por aclarar a los usuarios cuándo interactúan con aplicaciones de terceros e informar al usuario de las capacidades que tienen esas aplicaciones. Antes de la instalación de cualquier aplicación, se muestra al usuario un mensaje claro sobre los diferentes permisos que solicita la aplicación. Después de la instalación, no se le pide al usuario que confirme ningún permiso.
Hay muchas razones para mostrar los permisos inmediatamente antes del momento de la instalación. Esto es cuando el usuario está revisando activamente la información sobre la aplicación, el desarrollador y la funcionalidad para determinar si se ajusta a sus necesidades y expectativas. También es importante que aún no hayan establecido un compromiso mental o financiero con la aplicación y que puedan comparar fácilmente la aplicación con otras aplicaciones alternativas.
Algunas otras plataformas utilizan un enfoque diferente para la notificación al usuario, solicitando permiso al comienzo de cada sesión o mientras las aplicaciones están en uso. La visión de Android es que los usuarios cambien sin problemas entre aplicaciones a voluntad. Proporcionar confirmaciones cada vez ralentizaría al usuario y evitaría que Android ofreciera una excelente experiencia de usuario. Hacer que el usuario revise los permisos en el momento de la instalación le da la opción de no instalar la aplicación si se siente incómodo.
Además, muchos estudios de interfaz de usuario han demostrado que solicitar demasiado al usuario hace que el usuario comience a decir "OK" a cualquier cuadro de diálogo que se muestre. Uno de los objetivos de seguridad de Android es transmitir de manera efectiva información de seguridad importante al usuario, lo que no se puede hacer mediante cuadros de diálogo que el usuario debe aprender a ignorar. Al presentar la información importante una vez, y solo cuando es importante, es más probable que el usuario piense en lo que está aceptando.
Algunas plataformas optan por no mostrar ninguna información sobre la funcionalidad de la aplicación. Ese enfoque evita que los usuarios entiendan y discutan fácilmente las capacidades de la aplicación. Si bien no es posible que todos los usuarios siempre tomen decisiones completamente informadas, el modelo de permisos de Android hace que la información sobre las aplicaciones sea fácilmente accesible para una amplia gama de usuarios. Por ejemplo, las solicitudes de permisos inesperadas pueden hacer que los usuarios más sofisticados hagan preguntas críticas sobre la funcionalidad de la aplicación y compartan sus inquietudes en lugares como Google Play , donde están visibles para todos los usuarios.
| Permisos en la instalación de la aplicación -- Google Maps | Permisos de una aplicación instalada: Gmail |
 |  |
Figura 1. Visualización de permisos para aplicaciones
Comunicación entre procesos
Los procesos pueden comunicarse utilizando cualquiera de los mecanismos tradicionales de tipo UNIX. Los ejemplos incluyen el sistema de archivos, los sockets locales o las señales. Sin embargo, los permisos de Linux aún se aplican.
Android también proporciona nuevos mecanismos IPC:
Binder : un mecanismo de llamada de procedimiento remoto basado en capacidad ligera diseñado para un alto rendimiento al realizar llamadas en proceso y entre procesos. Binder se implementa mediante un controlador de Linux personalizado. Consulte https://developer.android.com/reference/android/os/Binder.html .
Servicios : los servicios (discutidos anteriormente) pueden proporcionar interfaces directamente accesibles mediante el enlace.
Intenciones : una intención es un objeto de mensaje simple que representa una "intención" de hacer algo. Por ejemplo, si su aplicación quiere mostrar una página web, expresa su "Intento" para ver la URL creando una instancia de Intent y entregándola al sistema. El sistema localiza alguna otra pieza de código (en este caso, el Navegador) que sabe cómo manejar ese Intent y lo ejecuta. Las intenciones también se pueden usar para transmitir eventos interesantes (como una notificación) en todo el sistema. Consulte https://developer.android.com/reference/android/content/Intent.html .
ContentProviders : un ContentProvider es un almacén de datos que brinda acceso a los datos en el dispositivo; el ejemplo clásico es el ContentProvider que se utiliza para acceder a la lista de contactos del usuario. Una aplicación puede acceder a los datos que otras aplicaciones han expuesto a través de un ContentProvider, y una aplicación también puede definir sus propios ContentProviders para exponer sus propios datos. Consulte https://developer.android.com/reference/android/content/ContentProvider.html .
Si bien es posible implementar IPC mediante otros mecanismos, como sockets de red o archivos de escritura mundial, estos son los marcos de trabajo IPC de Android recomendados. Se alentará a los desarrolladores de Android a utilizar las mejores prácticas para proteger los datos de los usuarios y evitar la introducción de vulnerabilidades de seguridad.
API sensibles al costo
Una API sensible al costo es cualquier función que pueda generar un costo para el usuario o la red. La plataforma Android ha colocado API sensibles a los costos en la lista de API protegidas controladas por el sistema operativo. El usuario deberá otorgar permiso explícito a las aplicaciones de terceros que soliciten el uso de API sensibles a los costos. Estas API incluyen:
- Telefonía
- SMS/MMS
- Red/Datos
- Facturación en la aplicación
- Acceso NFC
Android 4.2 agrega más control sobre el uso de SMS. Android proporcionará una notificación si una aplicación intenta enviar SMS a un código corto que utiliza servicios premium, lo que podría generar cargos adicionales. El usuario puede elegir si permitir que la aplicación envíe el mensaje o bloquearlo.
Acceso a la tarjeta SIM
El acceso de bajo nivel a la tarjeta SIM no está disponible para aplicaciones de terceros. El sistema operativo maneja todas las comunicaciones con la tarjeta SIM, incluido el acceso a la información personal (contactos) en la memoria de la tarjeta SIM. Las aplicaciones tampoco pueden acceder a los comandos AT, ya que estos son administrados exclusivamente por la capa de interfaz de radio (RIL). RIL no proporciona API de alto nivel para estos comandos.
Informacion personal
Android ha colocado API que brindan acceso a los datos del usuario en el conjunto de API protegidas. Con un uso normal, los dispositivos Android también acumularán datos de usuario dentro de las aplicaciones de terceros instaladas por los usuarios. Las aplicaciones que decidan compartir esta información pueden utilizar las verificaciones de permisos del sistema operativo Android para proteger los datos de aplicaciones de terceros.
Figura 2. El acceso a datos confidenciales del usuario solo está disponible a través de API protegidas
Los proveedores de contenido del sistema que probablemente contengan información personal o de identificación personal, como contactos y calendario, se han creado con permisos claramente identificados. Esta granularidad proporciona al usuario una indicación clara de los tipos de información que se pueden proporcionar a la aplicación. Durante la instalación, una aplicación de terceros puede solicitar permiso para acceder a estos recursos. Si se otorga el permiso, la aplicación se puede instalar y tendrá acceso a los datos solicitados en cualquier momento cuando se instale.
Cualquier aplicación que recopile información personal, de forma predeterminada, tendrá esos datos restringidos solo a la aplicación específica. Si una aplicación elige hacer que los datos estén disponibles para otras aplicaciones a través de IPC, la aplicación que otorga acceso puede aplicar permisos al mecanismo de IPC que aplica el sistema operativo.
Dispositivos de entrada de datos confidenciales
Los dispositivos Android suelen proporcionar dispositivos de entrada de datos confidenciales que permiten que las aplicaciones interactúen con el entorno circundante, como la cámara, el micrófono o el GPS. Para que una aplicación de terceros acceda a estos dispositivos, primero se le debe proporcionar acceso de forma explícita por parte del usuario mediante el uso de los permisos del sistema operativo Android. Tras la instalación, el instalador le indicará al usuario que solicite permiso para el sensor por su nombre.
Si una aplicación quiere saber la ubicación del usuario, la aplicación requiere un permiso para acceder a la ubicación del usuario. Tras la instalación, el instalador le preguntará al usuario si la aplicación puede acceder a la ubicación del usuario. En cualquier momento, si el usuario no desea que ninguna aplicación acceda a su ubicación, puede ejecutar la aplicación "Configuración", ir a "Ubicación y seguridad" y desmarcar "Usar redes inalámbricas" y "Habilitar satélites GPS". . Esto deshabilitará los servicios basados en ubicación para todas las aplicaciones en el dispositivo del usuario.
Metadatos del dispositivo
Android también se esfuerza por restringir el acceso a datos que no son intrínsecamente confidenciales, pero que pueden revelar indirectamente características sobre el usuario, sus preferencias y la forma en que usa un dispositivo.
De forma predeterminada, las aplicaciones no tienen acceso a los registros del sistema operativo, el historial del navegador, el número de teléfono o la información de identificación de hardware/red. Si una aplicación solicita acceso a esta información en el momento de la instalación, el instalador le preguntará al usuario si la aplicación puede acceder a la información. Si el usuario no otorga acceso, la aplicación no se instalará.
Autoridades de certificación
Android incluye un conjunto de autoridades de certificación del sistema instaladas, que son de confianza en todo el sistema. Antes de Android 7.0, los fabricantes de dispositivos podían modificar el conjunto de CA enviadas en sus dispositivos. Sin embargo, los dispositivos que ejecutan 7.0 y superior tendrán un conjunto uniforme de CA del sistema, ya que ya no se permite la modificación por parte de los fabricantes de dispositivos.
Para agregarse como una nueva CA pública al conjunto de acciones de Android, la CA debe completar el Proceso de inclusión de CA de Mozilla y luego presentar una solicitud de función contra Android ( https://code.google.com/p/android/issues/entry ) para que la CA se agregue a la CA de Android establecida en el Proyecto de código abierto de Android (AOSP).
Todavía hay CA que son específicas del dispositivo y no deben incluirse en el conjunto básico de CA de AOSP, como las CA privadas de los operadores que pueden ser necesarias para acceder de manera segura a los componentes de la infraestructura del operador, como las puertas de enlace de SMS/MMS. Se alienta a los fabricantes de dispositivos a incluir las CA privadas solo en los componentes/aplicaciones que necesitan confiar en estas CA. Para obtener más detalles, consulte Configuración de seguridad de la red .
Firma de aplicaciones
La firma de código permite a los desarrolladores identificar al autor de la aplicación y actualizar su aplicación sin crear interfaces y permisos complicados. Cada aplicación que se ejecuta en la plataforma Android debe estar firmada por el desarrollador. Las aplicaciones que intentan instalarse sin estar firmadas son rechazadas por Google Play o el instalador del paquete en el dispositivo Android.
En Google Play, la firma de aplicaciones une la confianza que Google tiene con el desarrollador y la confianza que el desarrollador tiene con su aplicación. Los desarrolladores saben que su aplicación se proporciona, sin modificaciones, en el dispositivo Android; y los desarrolladores pueden ser responsables del comportamiento de su aplicación.
En Android, la firma de aplicaciones es el primer paso para colocar una aplicación en su Application Sandbox. El certificado de aplicación firmado define qué identificación de usuario está asociada con qué aplicación; diferentes aplicaciones se ejecutan con diferentes ID de usuario. La firma de aplicaciones garantiza que una aplicación no pueda acceder a ninguna otra aplicación excepto a través de un IPC bien definido.
Cuando se instala una aplicación (archivo APK) en un dispositivo Android, Package Manager verifica que el APK se haya firmado correctamente con el certificado incluido en ese APK. Si el certificado (o, más exactamente, la clave pública en el certificado) coincide con la clave utilizada para firmar cualquier otro APK en el dispositivo, el nuevo APK tiene la opción de especificar en el manifiesto que compartirá un UID con el otro de manera similar. APK firmados.
Las aplicaciones pueden estar firmadas por un tercero (OEM, operador, mercado alternativo) o autofirmadas. Android proporciona firma de código mediante certificados autofirmados que los desarrolladores pueden generar sin ayuda ni permiso externos. Las solicitudes no tienen que estar firmadas por una autoridad central. Actualmente, Android no realiza la verificación de CA para los certificados de aplicación.
Las aplicaciones también pueden declarar permisos de seguridad en el nivel de protección de firma, lo que restringe el acceso solo a las aplicaciones firmadas con la misma clave mientras se mantienen distintos UID y entornos limitados de aplicaciones. Se permite una relación más estrecha con un entorno limitado de aplicaciones compartido a través de la función de UID compartido donde dos o más aplicaciones firmadas con la misma clave de desarrollador pueden declarar un UID compartido en su manifiesto.
Verificación de la aplicación
Android 4.2 y posteriores admiten la verificación de aplicaciones. Los usuarios pueden optar por habilitar "Verificar aplicaciones" y hacer que un verificador de aplicaciones evalúe las aplicaciones antes de la instalación. La verificación de aplicaciones puede alertar al usuario si intenta instalar una aplicación que podría ser dañina; si una aplicación es especialmente mala, puede bloquear la instalación .
Gestión de derechos digitales
La plataforma Android proporciona un marco DRM extensible que permite que las aplicaciones administren contenido protegido por derechos de acuerdo con las restricciones de licencia asociadas con el contenido. El marco DRM admite muchos esquemas DRM; qué esquemas DRM admite un dispositivo se deja al fabricante del dispositivo.
El marco DRM de Android se implementa en dos capas arquitectónicas (consulte la figura a continuación):
Una API de marco DRM, que se expone a las aplicaciones a través del marco de aplicaciones de Android y se ejecuta a través de la máquina virtual Dalvik para aplicaciones estándar.
Un administrador DRM de código nativo, que implementa el marco DRM y expone una interfaz para complementos DRM (agentes) para manejar la administración de derechos y el descifrado para varios esquemas DRM
Figura 3. Arquitectura de la gestión de derechos digitales en la plataforma Android