Seguridad de las apps

En esta página, se describen varios aspectos de la seguridad de las apps.

Elementos de las apps

Android proporciona una plataforma de código abierto y un entorno de apps para dispositivos móviles. El sistema operativo principal se basa en el kernel de Linux. Las apps para Android se escriben con mayor frecuencia en el lenguaje de programación Java y se ejecutan en la máquina virtual de Android Runtime (ART). Sin embargo, las apps también se pueden escribir en código nativo. Las apps se instalan desde un solo archivo con la extensión de archivo APK.

Los principales componentes básicos de las apps para Android son los siguientes:

• 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, las actividades, los servicios, los receptores de emisión y los proveedores de contenido que se describen a continuación) en una app. También especifica qué permisos son obligatorios.

• Actividades: En general, una actividad es el código de una sola tarea enfocada en el usuario que usa la clase Activity. Por lo general, una actividad incluye mostrar una IU al usuario, pero no es obligatorio. Algunas actividades nunca muestran IU. Por lo general, una de las actividades de la app es el punto de entrada a la app.

• Servicios: Un servicio es un cuerpo de código que se ejecuta en segundo plano, basado en la clase Service. Puede ejecutarse en su propio proceso o en el contexto del proceso de otra app. Otros componentes se vinculan a un servicio y, luego, invocan métodos en él a través de llamadas de procedimiento remoto. Un ejemplo de servicio es un reproductor multimedia: incluso cuando el usuario sale de la IU de selección de medios, es probable que quiera que la música siga reproduciéndose. Un servicio mantiene la música en funcionamiento incluso cuando se completa la IU.

• Receptor de transmisiones: Un receptor de transmisiones es un objeto de la clase BroadcastReceiver. Se instancia cuando el sistema operativo o alguna otra app emiten un mecanismo de IPC conocido como intent, una instancia de la clase Intent. Por ejemplo, una app puede registrar un receptor para el mensaje de batería baja y cambiar su comportamiento en función de esa información.

Modelo de permisos de Android: Accede a las APIs protegidas

Todas las apps en Android se ejecutan en una zona de pruebas de aplicaciones. De forma predeterminada, una app para Android solo puede acceder a un rango limitado de recursos del sistema. El sistema administra el acceso de las apps para Android a los recursos que, si se usan de forma incorrecta o maliciosa, podrían afectar negativamente la experiencia del usuario, la red o los datos del dispositivo.

Estas restricciones se implementan de diversas formas. Algunas capacidades están restringidas por la falta intencional de APIs 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 roles proporciona una medida de seguridad, como con el aislamiento del almacenamiento por app. En otros casos, las APIs sensibles están diseñadas para que las usen apps de confianza y están protegidas a través de un mecanismo de seguridad conocido como permisos.

Estas APIs protegidas incluyen las siguientes:

• Funciones de la cámara
• Datos de ubicación (GPS)
• Funciones de Bluetooth
• Funciones de telefonía
• Funciones de SMS/MMS
• Conexiones de red o de datos

Solo se puede acceder a estos recursos a través del sistema operativo. Para usar las APIs protegidas en el dispositivo, una app debe definir las capacidades que necesita en su manifiesto. Todas las versiones de Android 6.0 y posteriores usan un modelo de permisos de tiempo de ejecución. Si un usuario solicita una función de una app que requiere una API protegida, el sistema muestra un diálogo en el que se le solicita al usuario que rechace o permita el permiso.

Una vez que se otorgan, los permisos se aplican a la app mientras esté instalada. Para evitar confusiones, el sistema no vuelve a notificar al usuario sobre los permisos otorgados a la app, y las apps que se incluyen en el sistema operativo principal o que un OEM agrupa no solicitan permisos al usuario. Los permisos se quitan si se desinstala una app, por lo que una reinstalación posterior vuelve a mostrar los permisos.

En la configuración del dispositivo, los usuarios pueden ver los permisos de las apps que instalaron anteriormente. Los usuarios también pueden desactivar algunas funciones de forma global cuando lo deseen, como el GPS, la radio o el Wi-Fi.

En el caso de que una app intente usar una función protegida que no se haya declarado en el manifiesto de la app, el error de permiso suele generar una excepción de seguridad que se devuelve a la app. Las verificaciones de permisos de la API protegida se aplican en el nivel más bajo posible para evitar la elusión. En la Figura 2, se muestra un ejemplo del mensaje que ve el usuario cuando se instala una app mientras se solicita acceso a las APIs protegidas.

Los permisos predeterminados del sistema se describen en Manifest.permission. Las apps pueden declarar sus propios permisos para que los usen otras apps. Estos permisos no se indican en la ubicación anterior.

Cuando se define un permiso, un atributo protectionLevel le indica al sistema cómo se debe informar al usuario de las apps que requieren el permiso, o quién puede tener un permiso. En la lista de tareas de seguridad, se describen los detalles para crear y usar permisos específicos de la app.

Algunas capacidades del dispositivo, como la capacidad de enviar intents de transmisión de SMS, no están disponibles para las apps de terceros, pero pueden ser utilizadas por las apps preinstaladas por el OEM. Estos permisos usan el permiso signatureOrSystem.

Cómo entienden los usuarios las apps de terceros

Android se esfuerza por dejar en claro a los usuarios cuando interactúan con apps de terceros y les informa sobre las capacidades que tienen esas apps. Antes de instalar cualquier app, se le muestra al usuario un mensaje claro sobre los diferentes permisos que solicita la app. Después de la instalación, no se le vuelve a solicitar al usuario que confirme ningún permiso.

Existen muchos motivos para mostrar los permisos inmediatamente antes del tiempo de instalación. Es el momento en que el usuario revisa activamente la información sobre la app, 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 app, y que puedan compararla fácilmente con otras apps alternativas.

Otras plataformas usan un enfoque diferente para notificar a los usuarios, ya que solicitan permiso al comienzo de cada sesión o mientras se usan las apps. La visión de Android es que los usuarios puedan cambiar de app sin problemas cuando lo deseen. Proporcionar confirmaciones cada vez ralentizaría al usuario y evitaría que Android brindara una excelente experiencia del usuario. Si el usuario revisa los permisos en el momento de la instalación, tendrá la opción de no instalar la app si no se siente cómodo.

Además, muchos estudios de la interfaz de usuario demostraron que solicitarle demasiada información al usuario hace que este comience a hacer clic en Aceptar en cualquier diálogo que se muestre. Uno de los objetivos de seguridad de Android es transmitir de manera eficaz información importante sobre seguridad al usuario, lo que no se puede hacer con diálogos que el usuario está capacitado para ignorar. Si se presenta la información importante una sola vez y solo cuando es necesario, es más probable que el usuario piense en lo que acepta.

Algunas plataformas deciden no mostrar información sobre la funcionalidad de la app. Ese enfoque impide que los usuarios comprendan y analicen fácilmente las capacidades de la app. Si bien no es posible que todos los usuarios tomen siempre decisiones completamente fundamentadas, el modelo de permisos de Android hace que la información sobre las apps sea fácilmente accesible para una amplia variedad de usuarios. Por ejemplo, las solicitudes de permisos inesperadas pueden llevar a los usuarios más sofisticados a hacer preguntas críticas sobre la funcionalidad de la app y compartir sus inquietudes en lugares como Google Play, donde son visibles para todos los usuarios.

Permisos durante la instalación de la app: Google Traductor	Permisos de una app instalada: Gmail

Figura 1: Se muestran los permisos de las apps.

Comunicación entre procesos

Los procesos pueden comunicarse con cualquiera de los mecanismos tradicionales de tipo Unix. Entre los ejemplos, se incluyen el sistema de archivos, los sockets locales o los indicadores. Sin embargo, los permisos de Linux seguirán aplicándose.

Android también proporciona nuevos mecanismos de IPC:

• Binder: Es un mecanismo de llamada de procedimiento remoto basado en capacidades y ligero, diseñado para ofrecer un alto rendimiento cuando se realizan llamadas en el proceso y entre procesos. Binder se implementa con un controlador de Linux personalizado. Para obtener una descripción de la clase, consulta Binder.

• Servicios: Los servicios pueden proporcionar interfaces directamente accesibles con el vinculador. Para obtener una descripción más detallada, consulta Elementos de las apps.

• Intents: Un intent es un objeto de mensaje simple que representa una intención de hacer algo. Por ejemplo, si tu app quiere mostrar una página web, expresa su intención de ver la URL creando una instancia de intent y entregándosela al sistema. El sistema localiza otro fragmento de código (en este caso, el navegador) que sabe cómo controlar esa intención y lo ejecuta. Los intents también se pueden usar para transmitir eventos interesantes (como una notificación) en todo el sistema. Para obtener una descripción de la clase, consulta Intent.

• Proveedores de contenido: Un proveedor de contenido es un almacén de datos que proporciona acceso a los datos del dispositivo. El ejemplo clásico es el proveedor de contenido que se usa para acceder a la lista de contactos del usuario. Una app puede acceder a los datos que otras apps expusieron con un proveedor de contenido, y también puede definir su propio proveedor de contenido para exponer sus propios datos. Para obtener una descripción de la clase, consulta ContentProvider.

Si bien es posible implementar IPC con otros mecanismos, como sockets de red o archivos que admiten escritura pública, estos son los frameworks de IPC de Android recomendados. Se recomienda a los desarrolladores de Android que sigan las prácticas recomendadas para proteger los datos de los usuarios y evitar la introducción de vulnerabilidades de seguridad.

APIs 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 de Android colocó las APIs sensibles al costo en la lista de APIs protegidas controladas por el SO. El usuario debe otorgar permiso explícito a las apps de terceros que soliciten el uso de APIs sensibles a los costos. Se incluyen las siguientes API:

• Telefonía
• SMS y MMS
• Red o datos
• Facturación integrada en la aplicación
• Acceso con NFC

Android 4.2 agrega más control sobre el uso de SMS. Android proporciona una notificación si una app intenta enviar SMS a un código corto que utiliza servicios premium que pueden generar cargos adicionales. El usuario puede elegir si desea permitir que la app envíe el mensaje o bloquearla.

Acceso a la tarjeta SIM

Las apps de terceros no tienen acceso de bajo nivel a la tarjeta SIM. El SO controla todas las comunicaciones con la tarjeta SIM, incluido el acceso a la información personal (contactos) en la memoria de la tarjeta SIM. Las apps tampoco pueden acceder a los comandos AT, ya que la capa de interfaz de radio (RIL) los administra de forma exclusiva. La RIL no proporciona APIs de alto nivel para estos comandos.

Información personal

Android colocó las APIs que brindan acceso a los datos del usuario en el conjunto de APIs protegidas. Con el uso normal, los dispositivos Android también acumulan datos del usuario en las apps de terceros que instalan los usuarios. Las apps que eligen compartir esta información pueden usar las verificaciones de permisos del SO Android para proteger los datos de las apps de terceros.

Figura 2: El acceso a los datos sensibles del usuario solo está disponible a través de APIs protegidas.

Los proveedores de contenido del sistema que probablemente contengan información personal o de identificación personal, como contactos y calendario, se crearon con permisos claramente identificados. Esta granularidad le proporciona al usuario una indicación clara de los tipos de información que se pueden proporcionar a la app. Durante la instalación, una app de terceros puede solicitar permiso para acceder a estos recursos. Si se otorga el permiso, la app se puede instalar y tener acceso a los datos solicitados en cualquier momento mientras esté instalada.

De forma predeterminada, cualquier app que recopile información personal tiene restringido el acceso a esos datos solo a la app específica. Si una app decide poner los datos a disposición de otras apps a través de la IPC, la app que otorga el acceso puede aplicar permisos al mecanismo de IPC que el sistema operativo aplica.

Dispositivos de entrada de datos sensibles

Los dispositivos Android suelen proporcionar dispositivos de entrada de datos sensibles que permiten que las apps interactúen con el entorno circundante, como la cámara, el micrófono o el GPS. Para que una app de terceros acceda a estos dispositivos, el usuario primero debe otorgarle acceso de forma explícita a través de los permisos del SO Android. Durante la instalación, el instalador le solicita al usuario permiso para acceder al sensor por su nombre.

Si una app quiere conocer la ubicación del usuario, necesita un permiso para acceder a ella. Tras la instalación, el instalador le pregunta al usuario si la app puede acceder a su ubicación. En cualquier momento, si el usuario no quiere que ninguna app acceda a su ubicación, puede ejecutar la app de Configuración, ir a Ubicación y seguridad y anular la selección de Usar redes inalámbricas y Habilitar satélites GPS. Esto inhabilita los servicios basados en la ubicación para todas las apps del dispositivo del usuario.

Metadatos del dispositivo

Android también se esfuerza por restringir el acceso a los datos que no son intrínsecamente sensibles, pero que pueden revelar indirectamente características sobre el usuario, sus preferencias y la forma en que usa un dispositivo.

De forma predeterminada, las apps no tienen acceso a los registros del sistema operativo, el historial del navegador, el número de teléfono ni la información de identificación de hardware o de red. Si una app solicita acceso a esta información durante la instalación, el instalador le preguntará al usuario si la app puede acceder a la información. Si el usuario no otorga acceso, no se instalará la app.

Autoridades certificadoras

Android incluye un conjunto de autoridades certificadoras 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 AC que se incluían en sus dispositivos. Sin embargo, los dispositivos que ejecutan Android 7.0 y versiones posteriores tienen un conjunto uniforme de CAs del sistema, ya que los fabricantes de dispositivos ya no pueden realizar modificaciones.

Para agregarse como una nueva AC pública al conjunto de ACs predeterminadas de Android, la AC debe completar el Proceso de inclusión de ACs de Mozilla y, luego, presentar una solicitud de función contra Android ( https://code.google.com/p/android/issues/entry) para que se agregue la AC al conjunto de ACs predeterminadas de Android en el Proyecto de código abierto de Android (AOSP).

Aún existen CA que son específicas del dispositivo y no deberían incluirse en el conjunto principal de CA de AOSP, como las CA privadas de los operadores que pueden ser necesarias para acceder de forma segura a los componentes de la infraestructura del operador, como las puertas de enlace de SMS/MMS. Se recomienda a los fabricantes de dispositivos que incluyan las AC privadas solo en los componentes o las apps que necesiten confiar en estas AC. Para obtener más detalles, consulta Configuración de seguridad de la red.

Firma de apps

La firma de código permite a los desarrolladores identificar al autor de la app y actualizarla sin crear interfaces ni permisos complicados. Todas las apps que se ejecutan en la plataforma de Android deben estar firmadas por el desarrollador. Google Play o el instalador de paquetes del dispositivo Android rechazan las apps que intentan instalarse sin estar firmadas.

En Google Play, la firma de apps une la confianza que Google tiene en el desarrollador y la confianza que el desarrollador tiene en su app. Los desarrolladores saben que su app se proporciona sin modificaciones al dispositivo Android y pueden ser responsables del comportamiento de su app.

En Android, la firma de apps es el primer paso para colocar una app en su zona de pruebas de la app. El certificado de la app firmada define qué ID de usuario está asociado con qué app. Las diferentes apps se ejecutan con diferentes IDs de usuario. La firma de apps garantiza que una app no pueda acceder a ninguna otra, excepto a través de IPC bien definidos.

Cuando se instala una app (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 precisamente, la clave pública del certificado) coincide con la clave que se usó para firmar cualquier otro APK en el dispositivo, el nuevo APK tiene la opción de especificar en el manifiesto que comparte un UID con los otros APKs firmados de manera similar.

Las apps pueden estar firmadas por un tercero (OEM, operador, mercado alternativo) o autofirmadas. Android proporciona firma de código con certificados autofirmados que los desarrolladores pueden generar sin asistencia ni permiso externos. Las apps no tienen que estar firmadas por una autoridad central. Actualmente, Android no realiza la verificación de la CA para los certificados de apps.

Las apps también pueden declarar permisos de seguridad en el nivel de protección de firma, lo que restringe el acceso solo a las apps firmadas con la misma clave y, al mismo tiempo, mantiene UID y zonas de pruebas de aplicaciones distintos. Se permite una relación más cercana con un Application Sandbox compartido a través de la función de UID compartido, en la que dos o más apps firmadas con la misma clave de desarrollador pueden declarar un UID compartido en su manifiesto.

Verificación de apps

Android 4.2 y versiones posteriores admiten la verificación de apps. Los usuarios pueden habilitar Verificar aplicaciones y hacer que un verificador de aplicaciones evalúe las apps antes de la instalación. La verificación de aplicaciones puede alertar al usuario si intenta instalar una app que puede ser dañina. Si una app es particularmente mala, puede bloquear su instalación.

Administración de derechos digitales

La plataforma de Android proporciona un framework extensible de administración de derechos digitales (DRM) que permite a las apps administrar contenido protegido por derechos según las restricciones de licencia asociadas con el contenido. El framework de DRM admite muchos esquemas de DRM. Los esquemas de DRM que admite un dispositivo dependen del fabricante del dispositivo.

El framework de DRM de Android se implementa en dos capas de arquitectura (consulta la figura 3):

• Una API del framework de DRM, que se expone a las apps a través del framework de apps de Android y se ejecuta a través de la VM de ART para las apps estándar.

• Un administrador de DRM de código nativo que implementa el marco de trabajo de DRM y expone una interfaz para que los complementos (agentes) de DRM controlen la administración de derechos y el descifrado de varios esquemas de DRM

Figura 3: Arquitectura de DRM en la plataforma de Android.