Android mejora continuamente sus capacidades y ofertas de seguridad. Vea las listas de mejoras por lanzamiento en la navegación izquierda.
Androide 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.
androide 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.
androide 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.
androide 11
Todas las versiones de Android incluyen docenas de mejoras de seguridad para proteger a los usuarios. Para obtener una lista de algunas de las mejoras de seguridad más importantes disponibles en Android 11, consulta la Versión de Android Notas
androide 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:
- En Android Entorno de ejecución
- Conscrypt
- DNS Agente de resolución
- DocumentsUI
- ExtServices
- Contenido multimedia
- ModuleMetadata
- Redes
- PermissionController
- Datos de la zona horaria
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>
paraACCESS_FINE_LOCATION
oACCESS_COARSE_LOCATION
, el sistema agrega automáticamente un elemento<uses-permission>
paraACCESS_BACKGROUND_LOCATION
durante la instalación. - Si tu app solicita
ACCESS_FINE_LOCATION
oACCESS_COARSE_LOCATION
, el sistema automáticamente agregaACCESS_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, establecetargetSdkVersion
ocompileSdkVersion
de tu app en29
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:
- Archivos en el directorio específico de la app, a los que se accede mediante
getExternalFilesDir()
. - Fotos, videos y clips de audio que la app creó desde el almacén de contenido multimedia
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.
Build
TelephonyManager
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 permisoREAD_PHONE_STATE
. De lo contrario, se produce unSecurityException
.
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:
- El método
getConfiguredNetworks()
siempre muestra una lista vacía. - Cada método de operación de red que muestra un valor de número entero:
addNetwork()
yupdateNetwork()
—siempre devuelve -1. - Cada operación de red que muestra un valor booleano (
removeNetwork()
,reassociate()
,enableNetwork()
,disableNetwork()
,reconnect()
ydisconnect()
) siempre muestrafalse
.
androide 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.
androide 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 deBuild.SERIAL
, que está protegida por un permiso controlado por el usuario. Dirección MAC mejorada aleatorización en algunos chipsets.
androide 7
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 7.0
- Encriptación basada en archivos. La encriptación a nivel de archivo en lugar de encriptar toda el área de almacenamiento como una sola unidad, aísla y protege a usuarios y perfiles individuales (como datos funciona) en un dispositivo.
- Inicio directo. El inicio directo, habilitado por la encriptación basada en archivos, permite que ciertas apps, como la alarma y las funciones de accesibilidad, se ejecuten cuando el dispositivo está encendido, pero no desbloqueado.
- Inicio verificado. El inicio verificado ahora se aplica estrictamente impedir que se inicien los dispositivos vulnerados admite la corrección de errores para y mejorar la confiabilidad contra la corrupción de datos no maliciosa.
- SELinux. La configuración actualizada de SELinux y el aumento de la cobertura de Seccomp aumentan el hermetismo de la zona de pruebas de la aplicación y reducen la superficie de ataque.
- La aleatorización del orden de carga de la biblioteca y ASLR mejorado. Un aumento de aleatoriedad provoca que algunos ataques basados en reutilización de código sean menos efectivos.
- Endurecimiento del kernel. Se agregó una protección de memoria adicional para los kernel más nuevos, el proceso consiste en: marcar porciones de la memoria del kernel como de “solo lectura”, restringir el acceso del kernel a direcciones del espacio de usuario y reducir aún más la superficie de ataque existente.
- Esquema de firma de APK v2. Se introdujo una firma para todo el archivo que mejora la velocidad de verificación y refuerza las garantías de integridad.
- Almacén de CA confiable. Para facilitar el control de las apps acceso al tráfico de red seguro, autoridades certificadoras instaladas por el usuario y aquellos instalados a través de las APIs de Device Admin ya no son de confianza de forma predeterminada. para las apps orientadas al nivel de API 24 y versiones posteriores. Además, todos los dispositivos Android nuevos deben envíase con la misma tienda de CA de confianza.
- Configuración de seguridad de la red. Configura la seguridad de la red y TLS a través de un archivo de configuración declarativo.
androide 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.
androide 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()
yrecvfrom()
FD_CLR()
,FD_SET()
yFD_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 anteriores
Todas las versiones de Android incluyen docenas de mejoras de seguridad para proteger a los usuarios. A continuación, se muestran algunas de las mejoras de seguridad disponibles en Android 4.4:
- La zona de pruebas de Android se reforzó con SELinux. Android ahora usa SELinux en modo de aplicación forzosa. SELinux es un sistema de control de acceso obligatorio (MAC) en el kernel de Linux que se usa para aumentar el modelo de seguridad existente basado en el control de acceso discrecional (DAC). Esto brinda protección adicional contra posibles riesgos de seguridad vulnerabilidades.
- Por VPN del usuario. En dispositivos de varios usuarios, las VPN ahora se aplican por usuario. De esta manera, un usuario puede orientar todo el tráfico de red a través de una VPN sin afectar a otros usuarios en el dispositivo.
- Compatibilidad con el proveedor de ECDSA en AndroidKeyStore. Android ahora tiene un proveedor de almacén de claves que permite el uso de algoritmos ECDSA y DSA.
- Advertencias de supervisión de dispositivos. Android envía una advertencia a los usuarios si se ha recibido al almacén de certificados del dispositivo, que podría permitir tráfico de red encriptado.
- FORTIFY_SOURCE. Android ahora es compatible con el nivel 2 de FORTIFY_SOURCE, y todo el código se compila estas protecciones. Se mejoró FORTIFY_SOURCE para que funcione con clang.
- Fijación de certificados. Android 4.4 detecta y previene el uso fraudulento de productos certificados usados en las comunicaciones SSL/TLS seguras.
- Correcciones de seguridad. Android 4.4 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 Es posible que Android también incluya estas correcciones.
Todas las versiones de Android incluyen decenas de mejoras de seguridad para proteger usuarios. A continuación, se incluyen algunas de las mejoras de seguridad disponibles En Android 4.3:
- Zona de pruebas de Android reforzada con SELinux Esta versión fortalece la zona de pruebas de Android con el sistema de control de acceso obligatorio (MAC) de SELinux en el kernel de Linux. El refuerzo de SELinux es invisible para los usuarios y desarrolladores, y agrega solidez al modelo de seguridad existente de Android, a la vez que mantiene la compatibilidad con las apps existentes. Para garantizar la compatibilidad continua, esta versión permite el uso de SELinux en un modo permisivo. Este modo registra cualquier incumplimiento de la política, pero no dañará las apps ni afectará el comportamiento del sistema.
- No hay programas
setuid
nisetgid
. Se agregó compatibilidad con las capacidades del sistema de archivos a los archivos del sistema de Android y se quitaron todos los programassetuid
osetgid
. De esta manera, se reduce la superficie de ataque de raíz y la probabilidad de posibles vulnerabilidades de seguridad. - Autenticación ADB. A partir de Android 4.2.2, las conexiones a ADB se autentican con un par de claves RSA. Esto evita el uso no autorizado de ADB en el que el atacante tiene acceso físico a un dispositivo.
- Restringe Setuid desde apps para Android.
La partición
/system
ahora se activa en nosuid para procesos generados por Zygote, lo cual evita que las apps para Android ejecuten programassetuid
. De esta manera, se reduce la superficie de ataque de raíz y la probabilidad de posibles vulnerabilidades de seguridad. - Límite de capacidades.
Android Zygote y ADB ahora usan
prctl(PR_CAPBSET_DROP)
para soltar innecesarias antes de ejecutar las apps. Esto evita que las apps para Android y las que se inician desde el shell adquieran capacidades privilegiadas. - Proveedor de AndroidKeyStore. Android ahora tiene un proveedor de almacén de claves que permite que las apps creen claves de uso exclusivo. Esto proporciona a las apps con una API para crear o almacenar claves privadas que no pueden otras apps.
- Llavero
isBoundKeyAlgorithm
. La API de Keychain ahora proporciona un método (isBoundKeyType
) que permite que las apps confirmen que las teclas de todo el sistema están vinculadas a una raíz de confianza de hardware para el dispositivo. Esto proporciona un lugar para crear o almacenar claves privadas que no se pueden exportar incluso si se vulnera la raíz. NO_NEW_PRIVS
Android Zygote ahora usaprctl(PR_SET_NO_NEW_PRIVS)
para bloquear la adición de privilegios nuevos antes de ejecutar el código de la app. Esta impide que las apps para Android realicen operaciones que pueden elevar privilegios con execve. (Esto requiere la versión 3.5 del kernel de Linux). o una posterior).- Mejoras de
FORTIFY_SOURCE
. Se habilitóFORTIFY_SOURCE
en Android x86 y MIPS y fortificaronstrchr()
,strrchr()
,strlen()
y Llamadas deumask()
. Esto puede detectar posibles vulnerabilidades de corrupción de memoria o constantes de cadenas sin terminar. - Protección contra el traslado. Se habilitaron las reubicaciones de solo lectura (relro) para los ejecutables vinculados de forma estática y se quitaron todas las reubicaciones de texto en el código de Android. Esto proporciona una defensa en profundidad contra posibles vulnerabilidades de corrupción de la memoria.
- Se mejoró EntropyMixer. EntropyMixer ahora escribe entropía durante el apagado o reiniciar, además de una mezcla periódica. Esto permite retener toda la entropía generada mientras los dispositivos están encendidos y es especialmente útil para los dispositivos que se reinician inmediatamente después del aprovisionamiento.
- Correcciones de seguridad: Android 4.3 también incluye correcciones para vulnerabilidades específicas de Android. Se proporcionó información sobre estas vulnerabilidades con los miembros de Open Handset Alliance y las correcciones están disponibles en Android Open. Proyecto fuente. Para mejorar la seguridad, algunos dispositivos con versiones anteriores de Android también pueden incluir estas correcciones.
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 implementaFORTIFY_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 enfalse
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)