Mejoras de seguridad

Android mejora continuamente sus funciones y ofertas de seguridad. Consulta las listas de mejoras por versión en el panel de navegación izquierdo.

Android 14

Todas las versiones de Android incluyen docenas de mejoras de seguridad para proteger a los usuarios. Estas son algunas de las principales mejoras de seguridad disponibles en Android 14:

  • El AddressSanitizer asistido por hardware (HWASan), que se introdujo en Android 10, es una herramienta de detección de errores de memoria similar a AddressSanitizer. Android 14 ofrece mejoras significativas en HWASan. Descubre cómo ayuda a prevenir errores en las versiones de Android, HWAddressSanitizer
  • En Android 14, a partir de las apps que comparten datos de ubicación con terceros, el diálogo de permisos de tiempo de ejecución del sistema ahora incluye una sección en la que se puede hacer clic y en la que se destacan las prácticas de uso compartido de datos de la app, incluida información como el motivo por el que una app puede decidir compartir datos con terceros.
  • Android 12 introdujo una opción para inhabilitar la compatibilidad con 2G a nivel del módem, que protege a los usuarios del riesgo de seguridad inherente del modelo de seguridad obsoleto de la red 2G. Reconocer cómo la inhabilitación crítica de 2G podría ser para clientes empresariales, Android 14 habilita esta función de seguridad en Android Enterprise, se introduce la asistencia para que los administradores de TI restrinjan la capacidad de un equipo cambiar a una versión inferior a 2G.
  • Se agregó compatibilidad para rechazar conexiones móviles de cifrado nulo, lo que garantiza que el tráfico de voz y SMS con conmutación de circuitos siempre esté encriptado y protegido contra la intercepción inalámbrica. Aprendizaje Más información sobre el programa de Android para endurecer la conectividad móvil
  • Se agregó compatibilidad con varios IMEI
  • Desde Android 14, AES-HCTR2 es el modo preferido de encriptación de nombres de archivos para dispositivos con instrucciones de criptografía acelerada.
  • Conectividad móvil
  • Se agregó documentación para el Centro de seguridad de Android.
  • Si tu app está orientada a Android 14 y usa la carga dinámica de códigos (DCL), Todos los archivos cargados de forma dinámica deben marcarse como de solo lectura. De lo contrario, el sistema arroja una excepción. Recomendamos que las apps eviten la carga dinámica de códigos siempre que sea posible, ya que de esta manera aumenta, en gran medida, el riesgo de que una app pueda verse comprometida por la inserción o la manipulación de código.

Consulta nuestras notas de la versión completas de AOSP y la lista de cambios y funciones de Android Developers.

Android 13

Todas las versiones de Android incluyen docenas de mejoras de seguridad para proteger a los usuarios. Estas son algunas de las principales mejoras de seguridad disponibles en Android 13:

  • Android 13 incorpora la compatibilidad con la presentación de varios documentos. Esta nueva interfaz de sesión de presentación permite que una app presente varios documentos, algo que no es posible con la API existente. Para obtener más información, consulta Credencial de identidad
  • En Android 13, los intents que se originan en aplicaciones externas se entregan a una componente exportado solo si los intents coinciden los elementos declarados de filtro de intents.
  • La API de Open Mobile (OMAPI) es una API estándar que se usa para comunicarse con el Elemento seguro de un dispositivo. Antes de Android 13, solo las apps y los módulos del framework tenían acceso a esta interfaz. Si los conviertes en una interfaz estable de proveedor, los módulos HAL también pueden comunicarse con los elementos seguros a través del servicio OMAPI. Para obtener más información, consulta Interfaz estable del proveedor de OMAPI
  • A partir de Android 13-QPR, los UIDs compartidos dejan de estar disponibles. Los usuarios de Android 13 o versiones posteriores deben colocar la línea "android:sharedUserMaxSdkVersion="32"" en su manifiesto. Esta entrada evita que los usuarios nuevos obtengan un UID compartido. Para obtener más información sobre los UIDs, consulta Firma de apps.
  • Android 13 agregó compatibilidad con primitivas criptográficas simétricas de Keystore, como AES (Estándar de encriptación avanzada), HMAC (código de autenticación de mensajes de hash con clave) y algoritmos criptográficos asimétricos (incluidas las curvas elípticas, RSA2048, RSA4096 y Curve 25519).
  • Android 13 (nivel de API 33) y las versiones posteriores son compatibles un permiso de tiempo de ejecución para enviar notificaciones no exentas desde una app. Esto les brinda a los usuarios controlar qué notificaciones de permisos ven.
  • Se agregó un mensaje por uso para las apps que solicitan acceso a todos los registros del dispositivo, lo que les permite a los usuarios permitir o denegar el acceso.
  • presentó el Android Virtualization Framework (AVF), que reúne diferentes hipervisores en un framework con APIs estandarizadas. Proporciona entornos de ejecución seguros y privados para ejecutar cargas de trabajo aisladas por hipervisor.
  • Se introdujo el esquema de firma de APK v3.1 Todas las rotaciones de claves nuevas que usan apksigner utilizan el esquema de firma v3.1 de forma predeterminada para la rotación objetivo en Android 13 y versiones posteriores.

Consulta las notas de la versión completas de AOSP y el desarrollador de Android funciones y la lista de cambios.

Android 12

Todas las versiones de Android incluyen docenas de mejoras de seguridad para proteger a los usuarios. A continuación, se incluyen algunas de las principales mejoras de seguridad disponibles en Android 12:

  • Android 12 presenta API de BiometricManager.Strings, que brinda cadenas localizadas para apps que usan BiometricPrompt para realizar la autenticación. Estas cadenas están pensadas para reconocer dispositivos y brindan más especificidad sobre los tipos de autenticación que se podrían usar. En Android 12, también incluye compatibilidad con sensores de huellas dactilares debajo de la pantalla
  • Se agregó compatibilidad con sensores de huellas dactilares debajo de la pantalla
  • Introducción al Lenguaje de definición de la interfaz de Android con huellas digitales (AIDL)
  • Compatibilidad con Face AIDL
  • Introducción de Rust como lenguaje para el desarrollo de plataformas
  • Se agregó la opción para que los usuarios otorguen acceso solo a su ubicación aproximada
  • Se agregaron indicadores de privacidad a la barra de estado cuando una app usa la cámara o el micrófono.
  • Private Compute Core (PCC) de Android
  • Se agregó una opción para inhabilitar la compatibilidad con 2G.

Android 11

Every Android release includes dozens of security enhancements to protect users. For a list of some of the major security enhancements available in Android 11, see the Android Release Notes.

Android 10

Todas las versiones de Android incluyen decenas de mejoras de seguridad para proteger usuarios. Android 10 incluye varias mejoras de seguridad y privacidad. Consulta las notas de la versión de Android 10. para obtener una lista completa de los cambios en Android 10.

Seguridad

BoundsSanitizer

Android 10 implementa BoundsSanitizer (BoundSan) en Bluetooth y códecs. BoundSan usa la limpieza de límites de UBSan. Esta mitigación está habilitada a nivel de cada módulo. Ayuda a mantener seguros los componentes importantes de Android y no debe inhabilitarse. BoundSan está habilitado en los siguientes códecs:

  • libFLAC
  • libavcdec
  • libavcenc
  • libhevcdec
  • libmpeg2
  • libopus
  • libvpx
  • libspeexresampler
  • libvorbisidec
  • libaac
  • libxaac

Memoria de solo ejecución

De forma predeterminada, las secciones de código ejecutable de los objetos binarios del sistema AArch64 están marcadas como de solo ejecución (no legibles) para endurecer la mitigación contra ataques de reutilización de código just-in-time. El código que combina los datos y el código, y el código que inspecciona deliberadamente esas secciones (sin reasignar primero los segmentos de la memoria como legibles) ya no funciona. Apps con un SDK de Android 10 objetivo (nivel de API) 29 o versiones posteriores) se ven afectadas si la app intenta leer secciones de código de solo ejecución memoria (XOM) habilitada en la memoria sin marcar primero para que sean legibles.

Acceso ampliado

Agentes de confianza, el mecanismo subyacente utilizado por la autenticación terciaria mecanismos como Smart Lock, solo pueden extender el desbloqueo en Android 10. Confiar los agentes ya no pueden desbloquear un dispositivo bloqueado y solo pueden mantenerlo desbloqueado durante un máximo de cuatro horas.

Autenticación facial

La autenticación facial permite a los usuarios desbloquear el dispositivo con solo mirar la parte frontal. Android 10 agrega compatibilidad para una pila nueva de autenticación facial que puede procesar marcos de cámara de forma segura, lo que preserva la seguridad y privacidad durante la autenticación facial en hardware compatible. Android 10 también facilita que las implementaciones que cumplen con la seguridad permitan la integración de apps para transacciones de banca en línea, por ejemplo, y otros servicios.

Limpieza de desbordamiento de enteros

Android 10 habilita la limpieza de desbordamiento de enteros (IntSan) en códecs de software. Asegúrate de que el rendimiento de reproducción sea aceptable para cualquier códec que no sea compatible con el hardware del dispositivo. IntSan está habilitada en los siguientes códecs:

  • libFLAC
  • libavcdec
  • libavcenc
  • libhevcdec
  • libmpeg2
  • libopus
  • libvpx
  • libspeexresampler
  • libvorbisidec

Componentes modulares del sistema

Android 10 modulariza algunos componentes del sistema Android y les permite actualizarse fuera del ciclo normal de lanzamientos de Android. Algunos módulos incluyen lo siguiente:

OEMCrypto

Android 10 usa la versión 15 de la API de OEMCrypto.

Scudo

Scudo es un asignador de memoria dinámico en modo de usuario diseñado para ser más resistente contra las vulnerabilidades relacionadas con pilas. Proporciona la asignación C estándar y las primitivas de desasignación y las primitivas de C++.

ShadowCallStack

ShadowCallStack (SCS) es un LLVM. de instrumentación que protege contra reemplazos de la dirección de devolución (como desbordamiento del búfer de pila), guardando la dirección de devolución de una función en un bucket una instancia de ShadowCallStack asignada en el prólogo de función de funciones que no son de hoja y la carga de la dirección de devolución desde el instancia de ShadowCallStack en el epílog de la función.

WPA3 y Wi-Fi Enhanced Open

Android 10 agrega compatibilidad con el Wi-Fi Estándares de seguridad de Acceso protegido 3 (WPA3) y Wi-Fi Enhanced Open para brindar mayor privacidad y solidez contra ataques conocidos.

Privacidad

Acceso a apps cuando se orienta a Android 9 o versiones anteriores

Si tu app se ejecuta en Android 10 o versiones posteriores, pero está orientada a Android 9 (nivel de API 28) o versiones anteriores, la plataforma se comportará de la siguiente manera:

  • Si tu app declara un elemento <uses-permission> para ACCESS_FINE_LOCATION o ACCESS_COARSE_LOCATION, el sistema agrega automáticamente un elemento <uses-permission> para ACCESS_BACKGROUND_LOCATION durante la instalación.
  • Si tu app solicita ACCESS_FINE_LOCATION o ACCESS_COARSE_LOCATION, el sistema automáticamente agrega ACCESS_BACKGROUND_LOCATION a la solicitud.

Restricciones de actividad en segundo plano

A partir de Android 10, el sistema aplica restricciones sobre iniciar actividades en segundo plano. Este cambio de comportamiento ayuda a minimizar las interrupciones para el usuario y a darle más control de lo que aparece en la pantalla. Siempre y cuando la app inicie actividades como resultado directo de la interacción del usuario, es probable que tu app no se vea afectada por estas restricciones.
Para obtener más información sobre la alternativa recomendada a iniciar actividades desde segundo plano, consulta la guía sobre cómo alertar usuarios de eventos con plazos definidos en tu app.

Metadatos de la cámara

Android 10 cambia la amplitud de información que getCameraCharacteristics() de forma predeterminada. En particular, tu app debe tener el elemento CAMERA permiso para acceder a metadatos potencialmente específicos de un dispositivo que se incluido en el valor que se muestra de este método.
Para obtener más información sobre estos cambios, consulta la sección sobre la cámara que requieren permiso.

Datos del portapapeles

A menos que tu app sea la entrada predeterminada de métodos de configuración (IME) o es la app que está enfocada, tu app no puede acceder a los datos del portapapeles en Android 10 o versiones posteriores

Ubicación del dispositivo

Para admitir el control adicional que tienen los usuarios sobre el acceso de la app a la información de ubicación, en Android 10 se introduce el permiso ACCESS_BACKGROUND_LOCATION.
A diferencia de los permisos ACCESS_FINE_LOCATION y ACCESS_COARSE_LOCATION, el permiso ACCESS_BACKGROUND_LOCATION solo afecta el acceso de una app a la ubicación cuando esta se ejecuta en segundo plano. Se considera que una app accede a la ubicación en segundo plano siempre y cuando no se cumpla alguna de las siguientes condiciones:

  • Se muestra una actividad que pertenece a otra app.
  • La app ejecuta un servicio en primer plano que declaró un primer plano. tipo de servicio location.
    Para declarar el tipo de servicio en primer plano para un servicio de tu app, establece targetSdkVersion o compileSdkVersion de tu app en 29 o una versión posterior. Obtén más información sobre cómo los servicios en primer plano pueden continuar acciones iniciadas por el usuario que requieren acceso a la ubicación

Almacenamiento externo

De forma predeterminada, las apps orientadas a Android 10 y versiones posteriores tienen un alcance el acceso al almacenamiento externo o al almacenamiento específico. Esas aplicaciones pueden ver los siguientes tipos de archivos en un dispositivo de almacenamiento externo sin la necesidad para solicitar permisos del usuario relacionados con el almacenamiento:

Para obtener más información sobre el almacenamiento específico y cómo compartir, acceder y modificar archivos guardados en dispositivos de almacenamiento externo, consulta las guías sobre cómo para administrar archivos en el almacenamiento externo y acceder a y modificar archivos multimedia.

Aleatorización de direcciones MAC

En los dispositivos que ejecutan Android 10 o versiones posteriores, el sistema transmite direcciones MAC aleatorias. de forma predeterminada.
Si tu app administra un caso de uso empresarial, puede proporciona APIs para varias operaciones relacionadas con direcciones MAC:

  • Obtén direcciones MAC aleatorias: Las apps de propietarios de dispositivos y perfiles pueden recuperar las direcciones MAC aleatorias asignadas a una red específica mediante una llamada a getRandomizedMacAddress().
  • Obtén direcciones MAC de fábrica reales: Las apps para propietarios de dispositivos pueden recuperar la dirección MAC real del hardware del dispositivo mediante una llamada a getWifiMacAddress(). Este método es útil para realizar un seguimiento de varios dispositivos.

Identificadores de dispositivo que no se pueden restablecer

A partir de Android 10, las apps deben tener el permiso de firma READ_PRIVILEGED_PHONE_STATE para acceder a los identificadores que no se pueden restablecer del dispositivo, incluido el IMEI y el número de serie.

Si tu app no tiene el permiso y solicitas información sobre los identificadores que no se pueden restablecer, la respuesta de la plataforma variará en función de la versión del SDK de destino:

  • Si tu app está orientada a Android 10 o versiones posteriores, se aplicará una SecurityException. de que ocurra.
  • Si tu app se orienta a Android 9 (nivel de API 28) o versiones anteriores, el método muestra null o datos del marcador de posición si la app tiene el permiso READ_PHONE_STATE. De lo contrario, se produce un SecurityException.

Reconocimiento de actividad física

Android 10 introduce el permiso de tiempo de ejecución android.permission.ACTIVITY_RECOGNITION para apps que necesitan detectar el recuento de pasos del usuario o clasificar su actividad física, como cuando camina, anda en bicicleta o está en un vehículo. Se diseñó para dar a los usuarios visibilidad sobre cómo se usan los datos que se usa en Configuración.
Algunas bibliotecas dentro de Google Play Services, como las de Activity la API de reconocimiento y las APIs de Google API de Fit, no proporciones resultados, a menos que el usuario le haya otorgado esta permiso.
La única solución integrada sensores en el dispositivo que requieren que declares este permiso son el paso contador y paso del detector.
Si tu app se orienta a Android 9 (nivel de API 28) o versiones anteriores, el sistema otorga automáticamente el permiso android.permission.ACTIVITY_RECOGNITION a tu app, según sea necesario, si esta cumple con cada uno de los siguientes condiciones:

  • El archivo de manifiesto incluye el permiso com.google.android.gms.permission.ACTIVITY_RECOGNITION.
  • El archivo de manifiesto no incluye el permiso android.permission.ACTIVITY_RECOGNITION.

Si el sistema le otorga automáticamente android.permission.ACTIVITY_RECOGNITION permiso, tu app retiene el permiso después de que actualices tu app para que se oriente a Android 10. Sin embargo, el usuario puede revocar este permiso en cualquier momento desde la configuración del sistema.

Restricciones del sistema de archivos /proc/net

En dispositivos que ejecutan Android 10 o versiones posteriores, las apps no pueden acceder a /proc/net, que incluye información sobre el estado de red de un dispositivo. Las apps que necesitan acceder a este tipo de información, como las VPN, deben usar la clase NetworkStatsManager o ConnectivityManager.

Se quitaron los grupos de permisos de la IU

A partir de Android 10, las apps no pueden ver cómo los permisos están agrupados en la IU.

Eliminación de la afinidad de contactos

A partir de Android 10, la plataforma no realiza un seguimiento de la afinidad de contactos información. Como resultado, si la app realiza una búsqueda en los contactos del usuario Los resultados no están ordenados por frecuencia de interacción.
La guía sobre ContactsProvider contiene un aviso que describe los campos específicos y métodos obsoletos en todos los dispositivos a partir de Android 10.

Acceso restringido a contenido de la pantalla

Para proteger las contraseñas contenidos de la pantalla, Android 10 impide el acceso silencioso a la el contenido de la pantalla del dispositivo cambiando el alcance READ_FRAME_BUFFER, CAPTURE_VIDEO_OUTPUT y Permisos CAPTURE_SECURE_VIDEO_OUTPUT. A partir de Android 10, solo se puede acceder a estos permisos mediante una firma.
Las aplicaciones que necesitan acceder al contenido de la pantalla del dispositivo deben usar el MediaProjection API, que muestra un mensaje en el que se le solicita al usuario que dé su consentimiento.

Número de serie del dispositivo USB

Si tu app está orientada a Android 10 o versiones posteriores, no podrá leer el número de serie hasta que el usuario otorgue el permiso de app al accesorio o dispositivo USB.
Para obtener más información sobre cómo trabajar con dispositivos USB, consulta la guía sobre cómo configurar Hosts USB.

Wi-Fi

Las apps que se orientan a Android 10 o versiones posteriores no pueden habilitar ni inhabilitar la red Wi-Fi. El método WifiManager.setWifiEnabled() siempre muestra false.
Si necesitas solicitar al usuario que habilite o inhabilite la red Wi-Fi, usa un panel de configuración.

Restricciones sobre el acceso directo a redes Wi-Fi configuradas

Para proteger la privacidad del usuario, se debe configurar manualmente la lista de redes Wi-Fi. se limita a las aplicaciones del sistema y a la política de dispositivo. controladores de la interfaz de red (DPC). Un DPC específico puede ser el propietario del dispositivo o el del perfil.
Si tu app se orienta a Android 10 o versiones posteriores, y no es una app del sistema o un DPC, entonces los siguientes métodos no mostrarán datos útiles:

Android 9

Todas las versiones de Android incluyen decenas de mejoras de seguridad para proteger usuarios. Para obtener una lista de algunas de las principales mejoras de seguridad disponibles en Android 9, consulta las Notas de la versión de Android.

Android 8

Todas las versiones de Android incluyen decenas de mejoras de seguridad para proteger usuarios. Estas son algunas de las principales mejoras de seguridad disponibles en Android 8.0:

  • Encriptación. Se agregó compatibilidad para desalojar la clave en el perfil de trabajo.
  • Inicio verificado. Se agregó el inicio verificado de Android (AVB). Verificado Base de código de inicio que admite protección contra reversiones para su uso en cargadores de inicio. AOSP. Se recomienda la compatibilidad con el bootloader para la protección contra reversiones del HLOS. Se recomienda que los cargadores de arranque solo se puedan desbloquear si el usuario interactúa físicamente con el dispositivo.
  • Pantalla de bloqueo. Mayor compatibilidad con el uso de modelos hardware para verificar la credencial de la pantalla de bloqueo.
  • KeyStore. Clave obligatoria para todos los dispositivos con Android 8.0 o versiones posteriores. Se agregó el ID y certificación para mejorar la inscripción automática.
  • Zona de pruebas Muchos componentes están más ajustados en la zona de pruebas con la interfaz estándar de Project Treble entre el framework y los componentes específicos del dispositivo. Se aplicó seccomp filtrado a todas las apps que no sean de confianza para reducir la superficie de ataque del kernel. WebView ahora se ejecuta en un proceso aislado con acceso muy limitado al resto del sistema.
  • Endurecimiento del kernel. Se implementó la copia de usuario endurecida, la emulación de PAN, el modo de solo lectura después de la inicialización y KASLR.
  • Endurecimiento del espacio de usuario. Se implementó la CFI para la pila de medios. Las superposiciones de apps ya no pueden cubrir ventanas críticas del sistema, y los usuarios tienen una forma de descartarlas.
  • Actualización del SO por transmisión. Se habilitaron las actualizaciones en dispositivos que tienen poco espacio en el disco.
  • Cómo instalar apps desconocidas. Los usuarios deben otorgar permiso para instalar apps desde una fuente que no sea una tienda de aplicaciones propia.
  • Privacidad. El ID de Android (SSAID) tiene un valor diferente para cada app y cada usuario en el dispositivo. Para apps de navegador web, ID de cliente de Widevine muestra un valor diferente para cada nombre de paquete de app y origen web. net.hostname ahora está vacío y el cliente dhcp ya no envía un nombre de host. android.os.Build.SERIAL se reemplazó por la API de Build.SERIAL, que está protegida por un permiso controlado por el usuario. Dirección MAC mejorada aleatorización en algunos chipsets.

Android 7

Every Android release includes dozens of security enhancements to protect users. Here are some of the major security enhancements available in Android 7.0:

  • File-based encryption. Encrypting at the file level, instead of encrypting the entire storage area as a single unit, better isolates and protects individual users and profiles (such as personal and work) on a device.
  • Direct Boot. Enabled by file-based encryption, Direct Boot allows certain apps such as alarm clock and accessibility features to run when device is powered on but not unlocked.
  • Verified Boot. Verified Boot is now strictly enforced to prevent compromised devices from booting; it supports error correction to improve reliability against non-malicious data corruption.
  • SELinux. Updated SELinux configuration and increased seccomp coverage further locks down the Application Sandbox and reduces attack surface.
  • Library load-order randomization and improved ASLR. Increased randomness makes some code-reuse attacks less reliable.
  • Kernel hardening. Added additional memory protection for newer kernels by marking portions of kernel memory as read-only, restricting kernel access to userspace addresses and further reducing the existing attack surface.
  • APK signature scheme v2. Introduced a whole-file signature scheme that improves verification speed and strengthens integrity guarantees.
  • Trusted CA store. To make it easier for apps to control access to their secure network traffic, user-installed certificate authorities and those installed through Device Admin APIs are no longer trusted by default for apps targeting API Level 24+. Additionally, all new Android devices must ship with the same trusted CA store.
  • Network Security Config. Configure network security and TLS through a declarative configuration file.

Android 6

Todas las versiones de Android incluyen docenas de mejoras de seguridad para proteger a los usuarios. A continuación, se incluyen algunas de las principales mejoras de seguridad disponibles en Android 6.0

  • Permisos de tiempo de ejecución. Las apps solicitan permisos durante el tiempo de ejecución, en lugar de que se les otorguen en el momento de la instalación. Los usuarios pueden activar o desactivar los permisos en M y en versiones anteriores a M de Google Chat.
  • Inicio verificado. Un conjunto de verificaciones criptográficas del sistema software se llevan a cabo antes de ejecución para garantizar que el teléfono esté en buen estado desde el bootloader hasta el sistema operativo.
  • Seguridad Aislamiento de Hardware. Nueva capa de abstracción de hardware (HAL) que usan la API de huellas dactilares, la pantalla de bloqueo, la encriptación del dispositivo y los certificados de cliente para proteger las claves contra ataques físicos locales o de vulneración del kernel
  • Huellas digitales. Los dispositivos ahora se pueden desbloquear con solo un táctil. Los desarrolladores también pueden aprovecha las nuevas APIs para usar huellas dactilares para bloquear y desbloquear claves de encriptación.
  • Adopción de tarjetas SD. Los medios extraíbles se pueden adoptado a un dispositivo y ampliar el almacenamiento disponible para datos locales de la app, fotos, videos, etc., pero seguirán estando protegidos por restricciones la encriptación.
  • Tráfico de texto simple. Los desarrolladores pueden usar un nuevo StrictMode para asegurarse de que su app no use texto simple.
  • Endurecimiento del sistema. Endurecimiento del sistema mediante políticas ejecutado por SELinux. Esto ofrece un mejor aislamiento entre los usuarios, un filtrado de IOCTL, una reducción de la amenaza de los servicios expuestos, un mayor endurecimiento de los dominios de SELinux y un acceso extremadamente limitado a /proc.
  • Control de acceso USB: Los usuarios deben confirmar que permiten el acceso USB a los archivos, el almacenamiento y otras funciones del teléfono. La configuración predeterminada ahora es solo cobrar con acceso sin requerir la aprobación explícita del usuario.

Android 5

5.0

Todas las versiones de Android incluyen docenas de mejoras de seguridad para proteger a los usuarios. Estas son algunas de las principales mejoras de seguridad disponibles en Android 5.0:

  • Encriptado de forma predeterminada. En los dispositivos que se envían con L preinstalada, la encriptación completa del disco está habilitada de forma predeterminada para mejorar la protección de los datos en dispositivos perdidos o robados. Los dispositivos que se actualizan a L se pueden encriptar en Configuración > Seguridad.
  • Se mejoró la encriptación de disco completo. La contraseña del usuario está protegida contra ataques de descifrado por fuerza bruta con scrypt y, cuando está disponible, la clave está vinculada al almacén de claves de hardware para evitar ataques fuera del dispositivo. Como siempre, el secreto del bloqueo de pantalla de Android y la clave de encriptación del dispositivo no se envían fuera del dispositivo ni se exponen a ninguna aplicación.
  • Zona de pruebas de Android reforzada con SELinux . Android ahora requiere SELinux en modo de aplicación forzosa para todos los dominios. SELinux es un obligatorio del sistema de control de acceso (MAC) del kernel de Linux que se utiliza para aumentar la modelo de seguridad de control de acceso discrecional (DAC) existente. Esta nueva capa proporciona protección adicional contra posibles vulnerabilidades de seguridad.
  • Smart Lock Android ahora incluye trustlets que proporcionan más flexibilidad para desbloquear dispositivos. Por ejemplo, los trustlets pueden permitir que los dispositivos se desbloqueen automáticamente cuando están cerca de otro dispositivo de confianza (a través de NFC o Bluetooth) o cuando los usa alguien con un rostro de confianza.
  • Modos multiusuario, de perfil restringido y de invitado para teléfonos y tablets Android ahora admite varios usuarios en teléfonos y incluye un modo invitado que se puede usar para proporcionar acceso temporal y sencillo a tu dispositivo sin otorgar acceso a tus datos y apps.
  • Actualizaciones de WebView sin OTA WebView ahora puede se actualiza de forma independiente del framework y sin un sistema OTA Esto permite una respuesta más rápida a los posibles problemas de seguridad en WebView.
  • Se actualizó la criptografía para HTTPS y TLS/SSL. TLSv1.2 y TLSv1.1 ahora están habilitados, la confidencialidad directa ahora es la preferida, AES-GCM ahora está habilitado y los conjuntos de algoritmos de cifrado débiles (MD5, 3DES y conjuntos de algoritmos de cifrado de exportación) ahora están inhabilitados. Consulta https://developer.android.com/reference/javax/net/ssl/SSLSocket.html para obtener más detalles.
  • Se quitó la compatibilidad con vinculadores que no son PIE. Android ahora requiere que todos los ejecutables vinculados de forma dinámica admitan PIE (ejecutables de posición independiente). Esto mejora el espacio de direcciones de Android de aleatorización de diseño (ASLR).
  • Mejoras de FORTIFY_SOURCE. La siguiente libc ahora implementan las protecciones FORTIFY_SOURCE: stpcpy(), stpncpy(), read() y recvfrom() FD_CLR(), FD_SET() y FD_ISSET(). Esta brinda protección contra las vulnerabilidades de corrupción en la memoria que incluyen esas funciones.
  • Correcciones de seguridad. Android 5.0 también incluye correcciones para Vulnerabilidades específicas de Android Los miembros de Open Handset Alliance recibieron información acerca de estas vulnerabilidades y las correcciones están disponibles en el Proyecto de código abierto de Android. Para mejorar la seguridad, algunos dispositivos con versiones anteriores de Android también pueden incluir estas correcciones.

Android 4 y versiones anteriores

Every Android release includes dozens of security enhancements to protect users. The following are some of the security enhancements available in Android 4.4:

  • Android sandbox reinforced with SELinux. Android now uses SELinux in enforcing mode. SELinux is a mandatory access control (MAC) system in the Linux kernel used to augment the existing discretionary access control (DAC) based security model. This provides additional protection against potential security vulnerabilities.
  • Per User VPN. On multi-user devices, VPNs are now applied per user. This can allow a user to route all network traffic through a VPN without affecting other users on the device.
  • ECDSA Provider support in AndroidKeyStore. Android now has a keystore provider that allows use of ECDSA and DSA algorithms.
  • Device Monitoring Warnings. Android provides users with a warning if any certificate has been added to the device certificate store that could allow monitoring of encrypted network traffic.
  • FORTIFY_SOURCE. Android now supports FORTIFY_SOURCE level 2, and all code is compiled with these protections. FORTIFY_SOURCE has been enhanced to work with clang.
  • Certificate Pinning. Android 4.4 detects and prevents the use of fraudulent Google certificates used in secure SSL/TLS communications.
  • Security Fixes. Android 4.4 also includes fixes for Android-specific vulnerabilities. Information about these vulnerabilities has been provided to Open Handset Alliance members and fixes are available in Android Open Source Project. To improve security, some devices with earlier versions of Android may also include these fixes.

Every Android release includes dozens of security enhancements to protect users. The following are some of the security enhancements available in Android 4.3:

  • Android sandbox reinforced with SELinux. This release strengthens the Android sandbox using the SELinux mandatory access control system (MAC) in the Linux kernel. SELinux reinforcement is invisible to users and developers, and adds robustness to the existing Android security model while maintaining compatibility with existing apps. To ensure continued compatibility this release allows the use of SELinux in a permissive mode. This mode logs any policy violations, but will not break apps or affect system behavior.
  • No setuid or setgid programs. Added support for filesystem capabilities to Android system files and removed all setuid or setgid programs. This reduces root attack surface and the likelihood of potential security vulnerabilities.
  • ADB authentication. Starting in Android 4.2.2, connections to ADB are authenticated with an RSA keypair. This prevents unauthorized use of ADB where the attacker has physical access to a device.
  • Restrict Setuid from Android Apps. The /system partition is now mounted nosuid for zygote-spawned processes, preventing Android apps from executing setuid programs. This reduces root attack surface and the likelihood of potential security vulnerabilities.
  • Capability bounding. Android zygote and ADB now use prctl(PR_CAPBSET_DROP) to drop unnecessary capabilities prior to executing apps. This prevents Android apps and apps launched from the shell from acquiring privileged capabilities.
  • AndroidKeyStore Provider. Android now has a keystore provider that allows apps to create exclusive use keys. This provides apps with an API to create or store private keys that cannot be used by other apps.
  • KeyChain isBoundKeyAlgorithm. Keychain API now provides a method (isBoundKeyType) that allows apps to confirm that system-wide keys are bound to a hardware root of trust for the device. This provides a place to create or store private keys that can't be exported off the device, even in the event of a root compromise.
  • NO_NEW_PRIVS. Android zygote now uses prctl(PR_SET_NO_NEW_PRIVS) to block addition of new privileges prior to execution app code. This prevents Android apps from performing operations that can elevate privileges through execve. (This requires Linux kernel version 3.5 or greater).
  • FORTIFY_SOURCE enhancements. Enabled FORTIFY_SOURCE on Android x86 and MIPS and fortified strchr(), strrchr(), strlen(), and umask() calls. This can detect potential memory corruption vulnerabilities or unterminated string constants.
  • Relocation protections. Enabled read only relocations (relro) for statically linked executables and removed all text relocations in Android code. This provides defense in depth against potential memory corruption vulnerabilities.
  • Improved EntropyMixer. EntropyMixer now writes entropy at shutdown or reboot, in addition to periodic mixing. This allows retention of all entropy generated while devices are powered on, and is especially useful for devices that are rebooted immediately after provisioning.
  • Security fixes. Android 4.3 also includes fixes for Android-specific vulnerabilities. Information about these vulnerabilities has been provided to Open Handset Alliance members and fixes are available in Android Open Source Project. To improve security, some devices with earlier versions of Android may also include these fixes.

Android ofrece un modelo de seguridad de varias capas, que se describe en el artículo Android Descripción general de seguridad. Cada actualización de Android incluye docenas de mejoras de seguridad para proteger a los usuarios. Los siguientes son algunos de los mecanismos mejoras introducidas en Android 4.2:

  • Verificación de aplicaciones: Los usuarios pueden optar por habilitar la función Verificar aplicaciones. hacer que un verificador de aplicaciones examine las apps antes de su instalación La verificación de aplicaciones puede alertar al usuario si intenta instalar una aplicación que podría dañino; Si una app es especialmente mala, puede bloquear su instalación.
  • Mayor control de los SMS premium: Android proporciona una notificación si una app intenta enviar SMS a un código corto que usa servicios premium que pueden generar cargos adicionales. El usuario puede elegir si permite para enviar el mensaje o bloquearlo.
  • VPN siempre activada: La VPN se puede configurar para que las apps no tengan el acceso a la red hasta que se establezca una conexión VPN. Esto evita que las apps envíen datos a través de otras redes.
  • Fijación de certificados: Las bibliotecas principales de Android ahora admiten fijación de certificados. Los dominios fijados reciben una validación de certificado falla si el certificado no se encadena a un conjunto de certificados esperados. Esto brinda protección contra posibles compromisos de las autoridades certificadoras.
  • Visualización mejorada de los permisos de Android: Los permisos se organizan en grupos que los usuarios pueden comprender más fácilmente. Durante la revisión de los permisos, el usuario puede hacer clic en el permiso para ver información más detallada.
  • Endurecimiento de installd: El daemon installd no se ejecuta como usuario raíz, lo que reduce la superficie de ataque potencial para la elevación de privilegios raíz.
  • Endurecimiento de la secuencia de comandos init: Ahora, las secuencias de comandos init aplican la semántica O_NOFOLLOW para evitar ataques relacionados con symlink.
  • FORTIFY_SOURCE: Android ahora implementa FORTIFY_SOURCE Esto lo utilizan las bibliotecas y apps del sistema para evitar daños en la memoria.
  • Configuración predeterminada de ContentProvider: Apps orientadas a la API nivel 17 tienen export establecido en false de forma predeterminada para cada Contenido Proveedor, lo que reduce la superficie de ataque predeterminada para las apps.
  • Criptografía: Se modificaron las implementaciones predeterminadas de SecureRandom y Cipher.RSA para usar OpenSSL Se agregó compatibilidad con SSL Socket para TLSv1.1 y TLSv1.2. con OpenSSL 1.0.1
  • Correcciones de seguridad: Las bibliotecas de código abierto actualizadas con correcciones de seguridad incluyen WebKit, libpng, OpenSSL y LibXML. Android 4.2 también incluye correcciones para vulnerabilidades específicas de Android. La información sobre estas vulnerabilidades a los miembros de Open Handset Alliance y las correcciones están disponibles en Proyecto de código abierto de Android Para mejorar la seguridad, algunos dispositivos con versiones anteriores de Android también pueden incluir estas correcciones.

Android proporciona un modelo de seguridad de varias capas que se describe en la Descripción general de seguridad de Android. Cada actualización de Android incluye docenas de mejoras de seguridad para proteger a los usuarios. Los siguientes son algunos de los mecanismos mejoras introducidas en las versiones 1.5 a 4.1 de Android:

Android 1.5
  • ProPolice para evitar desbordamientos del búfer de pila (-fstack-protector)
  • safe_iop para reducir los desbordamientos de números enteros
  • Extensiones para OpenBSD dlmalloc para evitar vulnerabilidades de doble free() y para evitar ataques de consolidación de fragmentos. Los ataques de consolidación de fragmentos son una forma común de aprovechar la corrupción del montón.
  • OpenBSD calloc para evitar desbordamientos de números enteros durante la asignación de memoria
Android 2.3
  • Protecciones de vulnerabilidad de cadenas de formato (-Wformat-security -Werror=format-security)
  • No eXecute (NX) basado en hardware para evitar la ejecución de código en la pila y en el montón
  • mmap_min_addr de Linux para mitigar la escalamiento de privilegios de eliminación de referencia de puntero nulo (se mejoró aún más en Android 4.1)
Android 4.0
Aleatorización del diseño del espacio de direcciones (ASLR) para aleatorizar las ubicaciones de claves en la memoria
Android 4.1
  • Compatibilidad con PIE (ejecutable de posición independiente)
  • Reubicaciones de solo lectura / vinculación inmediata (-Wl,-z,relro -Wl,-z,now)
  • dmesg_restrict habilitado (evita filtrar direcciones de kernel)
  • kptr_restrict habilitado (evita la filtración de direcciones del kernel)