Mejores prácticas de seguridad del sistema

Esta sección contiene recomendaciones para garantizar la seguridad del sistema operativo y los dispositivos principales de Android.

Autenticación biométrica

Adquiera, almacene y procese cuidadosamente los datos biométricos para la autenticación del usuario. Debería:

  • Exija el método de autenticación principal antes de utilizar cualquier otra forma de autenticación (incluida la biométrica).
  • Requerir una confirmación explícita para indicar la intención al usar modalidades biométricas pasivas, como el reconocimiento facial, para transacciones (por ejemplo, pagos) que involucran claves vinculadas a la autenticación.
  • Requerir el método de autenticación principal cada 72 horas.
  • Utilice una canalización totalmente segura para todos los datos biométricos y su manipulación.
  • Nunca envíe datos biométricos (incluidas las mediciones del sensor sin procesar y las funciones derivadas) fuera del dispositivo. Si es posible, mantenga estos datos en un entorno seguro y aislado, como el entorno de ejecución de confianza (TEE) o el elemento seguro.

Los dispositivos con datos biométricos deben ser compatibles con la API BiometricPrompt , que ofrece una interfaz común y coherente para que los desarrolladores de aplicaciones aprovechen la autenticación basada en datos biométricos en sus aplicaciones. Solo la biometría sólida puede integrarse con BiometricPrompt y las integraciones deben seguir las pautas del Documento de definición de compatibilidad (CDD) de Android .

Para obtener más pautas biométricas, consulte Pautas de implementación biométrica de HAL .

SELinux

SELinux proporciona la definición y aplicación de gran parte del modelo de seguridad de Android. El uso correcto de SELinux es fundamental para la seguridad de los dispositivos Android y puede ayudar a mitigar el impacto de las vulnerabilidades de seguridad. Todos los dispositivos Android deben implementar una política SELinux sólida por este motivo.

  • Implementar una política de privilegios mínimos.
  • Evite otorgar CAP_DAC_OVERRIDE , CAP_SYS_ADMIN y CAP_NET_ADMIN .
  • No registre datos del sistema en la tarjeta SD.
  • Utilice los tipos proporcionados para el acceso del controlador, como gpu_device , audio_device , etc.
  • Use nombres significativos para procesos, archivos y tipos de SELinux.
    • Asegúrese de que no se utilicen etiquetas predeterminadas y que no se les conceda acceso.
  • La política específica del dispositivo debe representar del 5 al 10 % de la política general que se ejecuta en un dispositivo. Es casi seguro que las personalizaciones en el rango de más del 20% contienen dominios con privilegios excesivos y políticas inactivas. Una política innecesariamente grande desperdicia memoria, desperdicia espacio en disco al requerir una imagen de arranque más grande y afecta negativamente los tiempos de búsqueda de la política en tiempo de ejecución.

Carga dinámica de la política de SELinux

No cargue dinámicamente la política de SELinux en dispositivos Android. Si lo hace, puede dar lugar a problemas, tales como:

  • Impedir la aceptación de parches de seguridad críticos.
  • Exponer la capacidad de rootear un dispositivo mediante la recarga de políticas.
  • Exponer un vector para ataques de intermediarios contra el actualizador de políticas.
  • Dando como resultado dispositivos bloqueados debido a errores con las actualizaciones de políticas.

puertas traseras

Las aplicaciones de Android no deben tener puertas traseras ni formas de acceder al sistema o a los datos que eludan los mecanismos de seguridad normales. Esto incluye acceso especial de diagnóstico, depuración, desarrollo o reparación de garantía controlado por secretos conocidos por el desarrollador. Para evitar puertas traseras:

  • Analice todas las aplicaciones de terceros con una herramienta de análisis de vulnerabilidades de aplicaciones reconocida en la industria.
  • Realice revisiones de código de todo el código con acceso confidencial, incluidas las bibliotecas de terceros.
  • Utilice Google Play Protect cargando aplicaciones en Google Play para escanear. Puede cargar aplicaciones para escanear sin publicar en Google Play.
  • No precargue herramientas centradas en el diagnóstico o la reparación en las versiones de lanzamiento. Instale estas herramientas solo bajo demanda para resolver problemas específicos. Además, estas herramientas no deben operar ni cargar ningún dato específico de la cuenta.

Herramientas de desarrollo

Las herramientas de desarrollo, como las herramientas de depuración, prueba y diagnóstico, a menudo pueden crear brechas de seguridad no deseadas en su dispositivo al revelar cómo funcionan y los datos que recopilan. Para asegurarse de que las herramientas de desarrollo no lleguen a las compilaciones de producción:

  • Desarrolle una lista negra de hash de herramientas de prueba y depuración internas y escanee compilaciones para estos APK antes de usar la imagen del sistema.
  • Analice todas las aplicaciones propias con una herramienta de análisis de vulnerabilidades de aplicaciones reconocida en la industria.
  • Contrate a una empresa de pruebas de seguridad de aplicaciones de terceros para evaluar todas las aplicaciones críticas de diagnóstico en el dispositivo antes de cualquier actualización importante, especialmente si la aplicación es desarrollada por un tercero.
  • Asegúrese de que solo el usuario pueda habilitar la herramienta, ya sea verbalmente o por chat, durante una sesión de soporte. Almacene artefactos de consentimiento y deshabilite la herramienta después de recopilar la información de diagnóstico necesaria.
  • Guarde el registro de uso de esta herramienta en un registro accesible por el usuario en su cuenta de operador.
  • Asegúrese de que cualquier información de identificación personal (PII) o datos de telemetría del dispositivo recopilados por la herramienta estén sujetos a prácticas de anonimización, retención y eliminación relevantes para el país. Solo se deben recopilar datos relevantes para la llamada de soporte. Estos datos deben eliminarse después de cada llamada.
  • Asegúrese de que las técnicas que se pueden utilizar para el software espía, como el registro de pulsaciones de teclas, el uso del micrófono o el uso de la cámara, no se utilicen sin el consentimiento explícito del usuario. Las aplicaciones que utilizan estos métodos potencialmente invasivos para la privacidad deben divulgarse muy claramente junto con una política de privacidad que el usuario debe aceptar. Las aplicaciones como esta no deben habilitarse sin el consentimiento explícito del usuario.

Aquí hay algunas sugerencias adicionales para consultar al implementar la divulgación y el consentimiento:

Divulgación en la aplicación

  • Muestra el uso normal de la aplicación directamente en la aplicación. No requiere que el usuario navegue a un menú o configuración.
  • Describa el tipo de datos que se recopilan y explique cómo se utilizarán los datos.
  • Idealmente, no incluya esta información en una política de privacidad o términos de servicio. No lo incluya con otras divulgaciones no relacionadas con la recopilación de datos personales o confidenciales.
  • El consentimiento debe ser afirmativo. No considere la navegación fuera de la divulgación, incluido tocar o presionar el botón Atrás o Inicio, como consentimiento.
  • Presente el diálogo de consentimiento de una manera clara y sin ambigüedades.
  • Requerir una acción afirmativa del usuario, como tocar para aceptar o pronunciar un comando, para aceptar.
  • No recopile datos personales o sensibles antes de obtener el consentimiento afirmativo.
  • No uses mensajes que se descarten automáticamente o caduquen.

Funcionalidad integrada en AOSP

La incorporación de funciones adicionales en AOSP a menudo puede tener un comportamiento y consecuencias inesperados; proceda con precaución.

  • Asegúrese de que se le pregunte al usuario si desea usar diferentes aplicaciones predeterminadas (por ejemplo, motor de búsqueda, navegador web, lanzador) y revele el envío de datos fuera del dispositivo.
  • Asegúrese de que los APK de AOSP estén firmados con el certificado de AOSP.
  • Ejecute pruebas de regresión y mantenga un registro de cambios para determinar si se agregó código a los APK de AOSP.

Actualizaciones de seguridad

Los dispositivos Android deben recibir soporte de seguridad continuo durante al menos dos años desde el lanzamiento. Esto incluye recibir actualizaciones periódicas que aborden las vulnerabilidades de seguridad conocidas.

  • Trabaje con socios de hardware, como sus proveedores de SoC, para establecer acuerdos de soporte adecuados para todos los componentes de su dispositivo Android.
  • Asegúrese de que las actualizaciones de seguridad se puedan instalar con una interacción mínima del usuario para aumentar la probabilidad de que los usuarios acepten e instalen actualizaciones en su dispositivo Android. Se recomienda encarecidamente implementar actualizaciones del sistema sin problemas o una función de seguridad equivalente.
  • Asegúrese de comprender el requisito acumulativo del Nivel de parche de seguridad de Android (SPL) como se declara en el Boletín de seguridad de Android . Por ejemplo, los dispositivos que usan el nivel de parche de seguridad 2018-02-01 deben incluir todos los problemas asociados con ese nivel de parche de seguridad, así como soluciones para todos los problemas informados en todos los boletines de seguridad anteriores.

Actualizaciones dinámicas del kernel

No modifique dinámicamente los componentes críticos del sistema. Si bien hay algunas investigaciones que sugieren que las actualizaciones dinámicas del kernel ayudan a proteger contra las amenazas de emergencia, el costo evaluado actualmente supera los beneficios. En su lugar, cree un método sólido de actualización OTA para distribuir rápidamente las protecciones contra vulnerabilidades.

Gestión de claves

Mantenga buenas políticas y prácticas de gestión de claves para garantizar la seguridad de las claves de firma.

  • No comparta claves de firma con partes externas.
  • Si una clave de firma se ve comprometida, genere una nueva clave y firme dos veces todas las aplicaciones en el futuro.
  • Almacene todas las claves en hardware o servicios de módulo de alta seguridad que requieran múltiples factores para acceder.

Firma de imagen del sistema

La firma de la imagen del sistema es fundamental para determinar la integridad del dispositivo.

  • No firme dispositivos con una clave conocida públicamente.
  • Administre claves de firma de dispositivos de manera coherente con las prácticas estándar de la industria para el manejo de claves confidenciales, incluido un módulo de seguridad de hardware (HSM) que proporciona acceso limitado y auditable.

Cargadores de arranque desbloqueables

Muchos dispositivos Android admiten el desbloqueo, lo que permite al propietario del dispositivo modificar la partición del sistema o instalar un sistema operativo personalizado. Los casos de uso comunes incluyen la instalación de una imagen de sistema de terceros y la realización de desarrollo a nivel de sistemas en el dispositivo. Por ejemplo, para desbloquear la imagen del sistema en Google Nexus o Pixel, un usuario puede ejecutar fastboot oem unlock , que muestra este mensaje:

Como práctica recomendada, los dispositivos Android desbloqueables deben borrar de forma segura todos los datos del usuario antes de desbloquearlos. Si no se eliminan correctamente todos los datos durante el desbloqueo, es posible que un atacante físicamente cercano obtenga acceso no autorizado a datos confidenciales de usuarios de Android. Para evitar la divulgación de datos de usuario, un dispositivo que admita el desbloqueo debe implementarlo correctamente.

  • Después de que el usuario confirme el comando de desbloqueo, el dispositivo debe iniciar un borrado de datos inmediato. El indicador unlocked no debe establecerse hasta después de que se complete la eliminación segura.
  • Si no se puede completar una eliminación segura, el dispositivo debe permanecer en un estado bloqueado.
  • Si es compatible con el dispositivo de bloque subyacente, se debe usar ioctl(BLKSECDISCARD) o equivalente. Para los dispositivos integrados MultiMediaCard (eMMC), esto significa usar un comando Secure Erase o Secure Trim. Para eMMC 4.5 y versiones posteriores, esto significa usar un borrado o recorte normal seguido de una operación de desinfección.
  • Si BLKSECDISCARD no es compatible con el dispositivo de bloque subyacente, se debe usar ioctl(BLKDISCARD) en su lugar. En dispositivos eMMC, esta es una operación de ajuste normal.
  • Si no se admite BLKDISCARD , es aceptable sobrescribir los dispositivos de bloque con ceros.
  • Un usuario debe tener la opción de solicitar que se borren los datos del usuario antes de actualizar una partición. Por ejemplo, los dispositivos Nexus usan el fastboot oem lock para borrar los datos del usuario.
  • Un dispositivo puede registrar, a través de eFuses o un mecanismo similar, si un dispositivo se desbloqueó y/o se volvió a bloquear. Sin embargo, recomendamos encarecidamente que volver a bloquear el cargador de arranque con el restablecimiento de fábrica posterior debería restaurar la funcionalidad completa del dispositivo.

Estos requisitos garantizan que todos los datos se destruyan al finalizar una operación de desbloqueo. La falta de implementación de estas protecciones se considera una vulnerabilidad de seguridad de nivel moderado .

Un dispositivo que está desbloqueado puede volver a bloquearse posteriormente mediante el comando fastboot oem lock . Bloquear el cargador de arranque brinda la misma protección de los datos de usuario con el nuevo sistema operativo personalizado que estaba disponible con el sistema operativo del fabricante del dispositivo original (por ejemplo, los datos del usuario se borrarán si el dispositivo se desbloquea nuevamente).

Pentesting de dispositivos

Los dispositivos deben ser revisados ​​por un pentester competente antes del envío. Pentesting debe establecer que el dispositivo siguió la guía de seguridad proporcionada aquí, así como la guía de seguridad interna del OEM.

Pruebas de seguridad

Utilice las herramientas de prueba de seguridad proporcionadas por AOSP. En particular

  • Use herramientas de seguridad de la memoria durante el desarrollo: use MTE donde sea compatible (ARMv9 y superior) y HWASan donde no lo sea. Ejecute tantas pruebas como sea posible con estas herramientas habilitadas.
  • Use GWP-ASan y KFENCE en producción para la detección probabilística de problemas de seguridad de la memoria.