Elementos de las aplicaciones
Android proporciona una plataforma de código abierto y un entorno de aplicaciones para dispositivos móviles. El sistema operativo principal se basa en el kernel de Linux. Las aplicaciones de Android suelen estar escritas en el lenguaje de programación Java y se ejecutan en la máquina virtual Android Runtime (ART). Sin embargo, las aplicaciones también se pueden escribir en código nativo. Las aplicaciones se instalan desde un único archivo con la extensión de archivo .apk.
Los principales componentes básicos de las aplicaciones de Android son:
AndroidManifest.xml : el archivo AndroidManifest.xml es el archivo de control que le indica 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 se requieren.
Actividades : una actividad es, generalmente, el código para una única tarea centrada en el usuario. Por lo general, incluye mostrar una UI al usuario, pero no es necesario: algunas actividades nunca muestran UI. 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 mediante llamadas a procedimientos remotos. Un ejemplo de Servicio es un reproductor multimedia: incluso cuando el usuario sale de la interfaz de usuario de selección de medios, es probable que todavía tenga la intención de que la música siga reproduciéndose. Un Servicio mantiene la música incluso cuando se ha completado la interfaz de usuario.
Receptor de transmisión : un BroadcastReceiver es un objeto del que se crea una instancia cuando el sistema operativo u otra aplicación emite un mecanismo de 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 API protegidas
Todas las aplicaciones en Android se ejecutan en un entorno de pruebas de aplicaciones . De forma predeterminada, una aplicación de Android sólo puede acceder a una gama limitada de recursos del sistema. El sistema administra el acceso de las aplicaciones de Android a recursos que, si se usan de manera incorrecta o maliciosa, 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 existe una API de Android para manipular directamente la tarjeta SIM). En algunos casos, la separación de roles proporciona una medida de seguridad, como ocurre con el aislamiento del almacenamiento por aplicación. En otros casos, las API confidenciales están diseñadas para que las utilicen aplicaciones confiables y están protegidas mediante 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
Solo se puede acceder a estos recursos a través del sistema operativo. Para utilizar 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 utilizan 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 le solicita que niegue o permita el permiso.
Una vez concedidos, los permisos se aplican a la aplicación siempre que esté instalada. Para evitar confusión del usuario, el sistema no notifica nuevamente al usuario sobre los permisos otorgados a la aplicación, y las aplicaciones que están incluidas en el sistema operativo principal 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 globalmente cuando así lo deseen, como desactivar el GPS, la radio o el Wi-Fi.
En el caso de que una aplicación intente utilizar una característica protegida que no haya sido declarada en el manifiesto de la aplicación, la falla del permiso generalmente resultará en una excepción de seguridad que se devolverá a la aplicación. Las comprobaciones de permisos de API protegidas se aplican al nivel más bajo posible para evitar la elusión. En la Figura 2 se muestra un ejemplo de mensajes de usuario cuando se instala una aplicación mientras solicita acceso a 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 utilicen otras aplicaciones. Dichos permisos no figuran 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 utilizan el permiso SignatureOrSystem.
Cómo entienden los usuarios las aplicaciones de terceros
Android se esfuerza por dejar claro a los usuarios cuándo interactúan con aplicaciones de terceros e informarles sobre 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 vuelve a solicitar al usuario que confirme ningún permiso.
Hay muchas razones para mostrar permisos inmediatamente antes del momento de la instalación. Esto ocurre cuando el usuario revisa activamente información sobre la aplicación, el desarrollador y la funcionalidad para determinar si coincide con 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 compararla fácilmente con otras aplicaciones alternativas.
Algunas otras plataformas utilizan un enfoque diferente para la notificación al usuario, solicitando permiso al inicio 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 e impedirí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 no se siente cómodo.
Además, muchos estudios de interfaz de usuario han demostrado que solicitar demasiado al usuario hace que éste comience a decir "OK" a cualquier cuadro de diálogo que se muestra. 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 estará entrenado para ignorar. Al presentar la información importante una vez, y sólo 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 impide que los usuarios comprendan y analicen fácilmente las capacidades de la aplicación. Si bien no es posible que todos los usuarios tomen siempre decisiones plenamente 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 incitar a usuarios más sofisticados a hacer preguntas críticas sobre la funcionalidad de la aplicación y compartir sus inquietudes en lugares como Google Play , donde son visibles para todos los usuarios.
| Permisos en la instalación de la aplicación - Google Translate | 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, sockets locales o señales. Sin embargo, los permisos de Linux aún se aplican.
Android también proporciona nuevos mecanismos de IPC:
Carpeta : un mecanismo liviano de llamada a procedimiento remoto basado en capacidades 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 a las que se puede acceder directamente mediante Binder.
Intenciones : una intención es un objeto de mensaje simple que representa una "intención" de hacer algo. Por ejemplo, si su aplicación desea mostrar una página web, expresa su "Intención" de ver la URL creando una instancia de Intención y entregándola al sistema. El sistema localiza algún otro fragmento de código (en este caso, el navegador) que sabe cómo manejar ese Intent y lo ejecuta. Los intents también se pueden utilizar 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 proporciona acceso a los datos del 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 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 utilizando otros mecanismos, como sockets de red o archivos de escritura mundial, estos son los marcos de 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 a los costos
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 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 añade mayor 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 que podrían generar cargos adicionales. El usuario puede elegir si permite que la aplicación envíe el mensaje o lo bloquea.
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 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 aplicaciones de terceros instaladas por los usuarios. Las aplicaciones que optan por compartir esta información pueden utilizar comprobaciones 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 concede el permiso, la aplicación podrá instalarse y tendrá acceso a los datos solicitados en cualquier momento durante su instalación.
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 poner los datos a disposición de 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, como una cámara, un micrófono o un GPS. Para que una aplicación de terceros acceda a estos dispositivos, primero el usuario debe proporcionarle acceso explícitamente mediante el uso de permisos del sistema operativo Android. Tras la instalación, el instalador solicitará al usuario que solicite permiso para acceder al sensor por su nombre.
Si una aplicación quiere saber la ubicación del usuario, la aplicación requiere 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, entonces el usuario 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 la 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 sensibles, pero que pueden revelar indirectamente características sobre el usuario, sus preferencias y la forma en que utiliza un dispositivo.
De forma predeterminada, las aplicaciones no tienen acceso a los registros del sistema operativo, al historial del navegador, al número de teléfono ni a la información de identificación del hardware/red. Si una aplicación solicita acceso a esta información durante la instalación, el instalador le preguntará al usuario si la aplicación puede acceder a la información. Si el usuario no concede acceso, la aplicación no se instalará.
Autoridades certificadoras
Android incluye un conjunto de autoridades de certificación del sistema instaladas, en las que se confía en todo el sistema. Antes de Android 7.0, los fabricantes de dispositivos podían modificar el conjunto de CA incluidas en sus dispositivos. Sin embargo, los dispositivos que ejecutan 7.0 y superiores 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 ser agregada como una nueva CA pública al conjunto de stock de Android, la CA debe completar el proceso de inclusión de CA de Mozilla y luego presentar una solicitud de función para Android ( https://code.google.com/p/android/issues/entry ). para agregar la CA a la CA de Android estándar configurada 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 principal de CA AOSP, como las CA privadas de los operadores que pueden ser necesarias para acceder de forma segura a componentes de la infraestructura del operador, como las puertas de enlace de SMS/MMS. Se recomienda a los fabricantes de dispositivos que incluyan las CA privadas solo en los componentes/aplicaciones que deben confiar en estas CA. Para obtener más detalles, consulte Configuración de seguridad de red .
Firma de aplicaciones
La firma de código permite a los desarrolladores identificar al autor de la aplicación y actualizarla sin crear interfaces ni 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 por 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 modificar, al dispositivo Android; y los desarrolladores pueden ser considerados 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é ID de usuario está asociado 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, el Administrador de paquetes 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 solicitudes 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 asistencia 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 aplicaciones.
Las aplicaciones también pueden declarar permisos de seguridad en el nivel de protección de Firma, restringiendo el acceso solo a aplicaciones firmadas con la misma clave mientras mantienen UID y entornos de pruebas de aplicaciones distintos. Se permite una relación más estrecha con una zona de pruebas de aplicaciones compartida a través de la función 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 versiones 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 a las aplicaciones administrar contenido protegido por derechos de acuerdo con las restricciones de licencia asociadas con el contenido. El marco DRM soporta muchos esquemas DRM; Los esquemas DRM que admite un dispositivo quedan en manos del 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 está expuesta a aplicaciones a través del marco de aplicaciones de Android y se ejecuta a través de ART VM para aplicaciones estándar.
Un administrador DRM de código nativo, que implementa el marco DRM y expone una interfaz para que los complementos (agentes) DRM manejen la administración de derechos y el descifrado para varios esquemas DRM.
Figura 3. Arquitectura de Gestión de Derechos Digitales en la plataforma Android