Prácticas recomendadas de seguridad del sistema

En esta sección, se incluyen recomendaciones para garantizar la seguridad del sistema operativo y los dispositivos Android principales.

Autenticación biométrica

Adquiere, almacena y procesa los datos biométricos para la autenticación del usuario con cuidado. Podrás:

  • Establece el método de autenticación principal antes de usar cualquier otra forma de autenticación (incluidas las biométricas).
  • Solicita una confirmación explícita para indicar la intención cuando se usen modalidades biométricas pasivas, como el reconocimiento facial, para transacciones (por ejemplo, pagos) que involucren claves vinculadas a la autenticación.
  • Solicita el método de autenticación principal cada 72 horas.
  • Usa una canalización completamente segura para todos los datos biométricos y el manejo de estos.
  • Nunca envíes datos biométricos (incluidas las mediciones de sensores sin procesar y las funciones derivadas) fuera del dispositivo. Si es posible, mantén estos datos en un entorno seguro y aislado, como el entorno de ejecución confiable (TEE) o el elemento seguro.

Los dispositivos con datos biométricos deben admitir la API de BiometricPrompt, que ofrece una interfaz común y coherente para que los desarrolladores de apps aprovechen la autenticación basada en datos biométricos en sus apps. Solo las biométricas sólidas pueden integrarse en BiometricPrompt, y las integraciones deben seguir los lineamientos del Documento de definición de compatibilidad de Android (CDD).

Para obtener más lineamientos biométricos, consulta los Lineamientos de implementación de HAL biométrico.

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. Por este motivo, todos los dispositivos Android deben implementar una política SELinux sólida.

  • Implementa una política de privilegio mínimo.
  • Evita otorgar permisos CAP_DAC_OVERRIDE, CAP_SYS_ADMIN y CAP_NET_ADMIN.
  • No registres datos del sistema en la tarjeta SD.
  • Usa los tipos proporcionados para el acceso del controlador, como gpu_device, audio_device, etcétera.
  • Usa nombres significativos para los procesos, los archivos y los tipos de SELinux.
    • Asegúrate de que no se usen etiquetas predeterminadas ni se les otorgue acceso.
  • La política específica del dispositivo debe representar entre el 5 y el 10% de la política general que se ejecuta en un dispositivo. Es casi seguro que las personalizaciones en el rango superior al 20%contengan dominios con privilegios excesivos y políticas inactivas. Una política innecesariamente grande desperdicia memoria y espacio en el disco, ya que requiere una imagen de arranque más grande, y afecta de forma negativa los tiempos de búsqueda de políticas del entorno de ejecución.

Carga dinámica de la política de SELinux

No cargues de forma dinámica la política de SELinux en dispositivos Android. De lo contrario, es posible que se produzcan problemas, como los siguientes:

  • Evitar la aceptación de parches de seguridad críticos
  • Se expone la capacidad de obtener acceso a la raíz de un dispositivo a través de la recarga de políticas.
  • Exponer un vector para ataques de intermediario contra el actualizador de políticas
  • Esto provoca que los dispositivos dejen de funcionar debido a errores con las actualizaciones de políticas.

Puertas Traseras

Las apps para Android no deben tener puertas traseras ni formas de acceder al sistema o a los datos que omitan los mecanismos de seguridad normales. Esto incluye el acceso especial a diagnósticos, debugging, desarrollo o reparación de garantía, controlado por secretos que el desarrollador conoce. Para evitar puertas traseras, haz lo siguiente:

  • Analiza todas las apps de terceros con una herramienta de análisis de vulnerabilidades de apps reconocida por la industria.
  • Realiza revisiones de código de todo el código con acceso sensible, incluidas las bibliotecas de terceros.
  • Para usar Google Play Protect, sube apps a Google Play para que se analicen. Puedes subir apps para que se analicen sin publicarlas en Google Play.
  • No precargues herramientas enfocadas en diagnósticos o reparaciones en compilaciones de lanzamiento. Instala estas herramientas solo a pedido para resolver problemas específicos. Además, estas herramientas no deben operar ni subir datos específicos de la cuenta.

Herramientas de desarrollo

Las herramientas de desarrollo, como las de depuración, prueba y diagnóstico, a menudo pueden crear brechas de seguridad no deseadas en tu dispositivo, ya que revelan cómo funcionan y los datos que recopilan. Para asegurarte de que las herramientas de desarrollo no lleguen a las compilaciones de producción, haz lo siguiente:

  • Desarrolla una lista negra de hashes de herramientas de depuración y prueba internas, y analiza las compilaciones de estos APKs antes de usar la imagen del sistema.
  • Analiza todas las apps propias con una herramienta de análisis de vulnerabilidades de apps reconocida por la industria.
  • Contrata a una empresa externa de pruebas de seguridad de apps para que evalúe todas las apps de diagnóstico integradas en el dispositivo antes de cualquier actualización importante, en especial si la app la desarrolló un tercero.
  • Asegúrate de que solo el usuario pueda habilitar la herramienta, ya sea de forma verbal o por chat, durante una sesión de asistencia. Almacena artefactos de consentimiento y, luego, inhabilita la herramienta después de recopilar la información de diagnóstico necesaria.
  • Almacena el registro de uso de esta herramienta en un registro al que el usuario pueda acceder en su cuenta del operador.
  • Asegúrate de que la información de identificación personal (PII) o los datos de telemetría del dispositivo que recopila 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 los datos relevantes para la llamada de asistencia. Estos datos se deben borrar después de cada llamada.
  • Asegúrate de que no se usen técnicas que puedan usarse para software espía, como el registro de teclas, el uso del micrófono o el uso de la cámara, sin el consentimiento explícito del usuario. Las apps que usan estos métodos potencialmente invasivos de la privacidad deben divulgarse de forma muy clara junto con una política de privacidad a la que el usuario debe dar su consentimiento. Las apps como esta no deben estar habilitadas sin el consentimiento explícito del usuario.

Estas son algunas sugerencias adicionales que puedes consultar cuando implementes la divulgación y el consentimiento:

Divulgación en la app

  • Muestra el uso normal de la app directamente en ella. No exijas que el usuario navegue a un menú o a la configuración.
  • Describe el tipo de datos que se recopilan y explica cómo se usan.
  • Lo ideal es que no incorpores esta información en una política de privacidad ni en las condiciones del servicio. No la incluyas con otras divulgaciones que no estén relacionadas con la recopilación de datos personales o sensibles.
  • El consentimiento debe ser afirmativo. No consideres como consentimiento la acción de salir de la divulgación, lo que incluye presionar los botones de inicio, salir o atrás.
  • Presenta el cuadro de diálogo de consentimiento de manera clara y sin ambigüedades.
  • Solicita una acción afirmativa del usuario, como presionar para aceptar o decir un comando, para aceptar.
  • No recopiles datos personales ni sensibles antes de obtener el consentimiento afirmativo.
  • No uses mensajes que caduquen o se descarten automáticamente.

Funcionalidad incorporada en AOSP

La incorporación de funciones adicionales en AOSP a menudo puede tener comportamientos y consecuencias inesperados. Procede con precaución.

  • Asegúrate de que se le pregunte al usuario si quiere usar diferentes apps predeterminadas (por ejemplo, un motor de búsqueda, un navegador web o un selector) y divulgar el envío de datos fuera del dispositivo.
  • Asegúrate de que los APKs de AOSP estén firmados con el certificado de AOSP.
  • Ejecuta pruebas de regresión y mantén un registro de cambios para determinar si se agregó código a los APK de AOSP.

Actualizaciones de seguridad

Los dispositivos Android deben recibir asistencia de seguridad continua durante al menos dos años a partir del lanzamiento. Esto incluye recibir actualizaciones periódicas que abordan vulnerabilidades de seguridad conocidas.

  • Trabaja con socios de hardware, como los proveedores de SoC, para implementar los acuerdos de asistencia adecuados para todos los componentes de tu dispositivo Android.
  • Asegúrate 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 las actualizaciones en sus dispositivos Android. Se recomienda implementar las Actualizaciones del sistema sin interrupciones o una función de seguridad equivalente.
  • Asegúrate de comprender el requisito acumulativo del nivel de parche de seguridad (SPL) de Android, como se declara en el boletín de seguridad de Android. Por ejemplo, los dispositivos que usan el nivel de parche de seguridad del 1 de febrero de 2018 deben incluir todos los problemas asociados con ese nivel, así como las correcciones de todos los problemas informados en todos los boletines de seguridad anteriores.

Actualizaciones dinámicas del kernel

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

Administración de claves

Mantén buenas políticas y prácticas de administración de claves para garantizar la seguridad de las claves de firma.

  • No compartas las claves de firma con terceros.
  • Si se vulnera una clave de firma, genera una nueva y firma dos veces todas las apps en el futuro.
  • Almacenar todas las claves en hardware o servicios de módulos de alta seguridad que requieran varios factores para acceder

Firma de imágenes del sistema

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

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

Bootloaders que se pueden desbloquear

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

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

  • Una vez que el usuario confirme el comando de desbloqueo, el dispositivo debe iniciar una limpieza de datos inmediata. La marca unlocked no se debe establecer hasta 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 el dispositivo de almacenamiento en bloques subyacente lo admite, se debe usar ioctl(BLKSECDISCARD) o un equivalente. En el caso de los dispositivos con MultiMediaCard (eMMC) incorporados, 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 limpieza.
  • Si el dispositivo de almacenamiento en bloque subyacente no admite BLKSECDISCARD, se debe usar ioctl(BLKDISCARD). En los dispositivos eMMC, esta es una operación de Trim normal.
  • Si no se admite BLKDISCARD, se acepta reemplazar los dispositivos de almacenamiento en bloque con todos los ceros.
  • El usuario debe tener la opción de exigir que se borren los datos del usuario antes de actualizar una partición. Por ejemplo, los dispositivos Nexus usan el comando 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ó o volvió a bloquearse. Sin embargo, te recomendamos que vuelvas a bloquear el bootloader y, luego, restablezcas la configuración de fábrica para que se restablezca la funcionalidad completa del dispositivo.

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

Un dispositivo desbloqueado se puede volver a bloquear con el comando fastboot oem lock. El bloqueo del bootloader proporciona la misma protección de los datos del usuario con el nuevo SO personalizado que estaba disponible con el SO del fabricante original del dispositivo (por ejemplo, se borran los datos del usuario si se vuelve a desbloquear el dispositivo).

Pruebas de penetración de dispositivos

Un pentester competente debe revisar los dispositivos antes del envío. La prueba de penetración debe establecer que el dispositivo siguió las instrucciones de seguridad que se proporcionan aquí, así como las instrucciones de seguridad internas del OEM.

Pruebas de seguridad

Usa las herramientas de pruebas de seguridad que proporciona AOSP. En particular

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