Mejores prácticas de seguridad del sistema

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

Autenticación biométrica

Adquiera, almacene y procese cuidadosamente 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 cuando se utilizan modalidades biométricas pasivas, como el reconocimiento facial, para transacciones (por ejemplo, pagos) que involucran claves vinculadas a 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 mediciones sin procesar de sensores y funciones derivadas) fuera del dispositivo. Si es posible, mantenga estos datos en un entorno seguro y aislado, como Trusted Execution Environment (TEE) o Secure Element.

Los dispositivos con datos biométricos deben admitir la API BiometricPrompt , que ofrece una interfaz común y consistente para que los desarrolladores de aplicaciones aprovechen la autenticación basada en biometría en sus aplicaciones. Solo los datos biométricos sólidos pueden 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. Por este motivo, todos los dispositivos Android deben implementar una política SELinux sólida .

  • Implementar una política de privilegios mínimos.
  • Evite otorgar permisos 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 al controlador, como gpu_device , audio_device , etc.
  • Utilice nombres significativos para procesos, archivos y tipos de SELinux.
    • Asegúrese de que no se utilicen etiquetas predeterminadas y que no 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 demasiados privilegios y políticas inactivas. Una política innecesariamente grande desperdicia memoria, desperdicia espacio en disco al necesitar una imagen de arranque más grande y afecta negativamente los tiempos de búsqueda de políticas en tiempo de ejecución.

Carga dinámica de la política SELinux

No cargue dinámicamente la política SELinux en dispositivos Android. Hacerlo puede provocar problemas como:

  • Impedir la aceptación de parches de seguridad críticos.
  • Exponiendo la capacidad de rootear un dispositivo mediante la recarga de políticas.
  • Exponer un vector de ataques de intermediario contra el actualizador de políticas.
  • Lo que resulta en 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 diagnóstico, depuración, desarrollo o reparación en garantía, acceso especial controlado por secretos conocidos por el desarrollador. Para evitar puertas traseras:

  • Escanee todas las aplicaciones de terceros utilizando una herramienta de escaneo de vulnerabilidades de aplicaciones reconocida en la industria.
  • Realice revisiones de código de todo el código con acceso confidencial, incluidas bibliotecas de terceros.
  • Utilice Google Play Protect cargando aplicaciones en Google Play para escanear. Puede cargar aplicaciones para escanear sin publicarlas en Google Play.
  • No cargue previamente herramientas centradas en diagnósticos o reparaciones en las versiones de lanzamiento. Instale estas herramientas únicamente 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 hashes de herramientas de prueba y depuración internas y escanee compilaciones para estos APK antes de usar la imagen del sistema.
  • Escanee todas las aplicaciones propias utilizando una herramienta de escaneo de vulnerabilidades de aplicaciones reconocida en la industria.
  • Contrate una empresa de pruebas de seguridad de aplicaciones de terceros para evaluar todas las aplicaciones de diagnóstico críticas 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 los elementos de consentimiento y desactive la herramienta después de recopilar la información de diagnóstico necesaria.
  • Almacene 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. Sólo 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 puedan usarse para software espía, como el registro de pulsaciones de teclas, el uso de micrófonos o de cámaras, no se utilicen sin el consentimiento explícito del usuario. Las aplicaciones que utilizan estos métodos potencialmente invasivos de la privacidad deben divulgarse con mucha claridad junto con una política de privacidad a la que el usuario debe dar su consentimiento. 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 requiera 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.
  • Lo ideal es no incluir 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.
  • Presentar el diálogo de consentimiento de forma clara e inequívoca.
  • 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 utilice mensajes que se descarten automáticamente o que caduquen.

Funcionalidad integrada en AOSP

Incorporar funcionalidad adicional en AOSP a menudo puede tener comportamientos y consecuencias inesperados; proceda con precaución.

  • Asegúrese de que se le pregunte al usuario si desea utilizar diferentes aplicaciones predeterminadas (por ejemplo, motor de búsqueda, navegador web, iniciador) y revele el envío de datos desde el dispositivo.
  • Asegúrese de que los APK de AOSP estén firmados con el certificado AOSP.
  • Ejecute pruebas de regresión y mantenga un registro de cambios para determinar si se ha agregado 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 su 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 mínima interacción del usuario para aumentar la probabilidad de que los usuarios acepten e instalen actualizaciones en su dispositivo Android. Se recomienda encarecidamente implementar actualizaciones integradas del sistema o una característica de seguridad equivalente.
  • Asegúrese de comprender los requisitos acumulativos del nivel de parche de seguridad (SPL) de Android tal como se declara en el Boletín de seguridad de Android . Por ejemplo, los dispositivos que utilizan el nivel de parche de seguridad 2018-02-01 deben incluir todos los problemas asociados con ese nivel de parche de seguridad, así como las correcciones 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 amenazas de emergencia, el costo evaluado actualmente supera los beneficios. En su lugar, cree un método de actualización OTA sólido para distribuir rápidamente protecciones contra vulnerabilidades.

Gestión de claves

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

  • No comparta claves de firma con terceros.
  • 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ódulos 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 públicamente conocida.
  • Administre las 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 un 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. No eliminar correctamente todos los datos al desbloquear puede permitir que un atacante físicamente cercano obtenga acceso no autorizado a datos confidenciales del usuario de Android. Para evitar la divulgación de datos del usuario, un dispositivo que admita el desbloqueo debe implementarlo correctamente.

  • Después de que el usuario confirma el comando de desbloqueo, el dispositivo debe iniciar un borrado de datos inmediato. La bandera unlocked no se debe configurar hasta que se complete la eliminación segura.
  • Si no se puede completar una eliminación segura, el dispositivo debe permanecer bloqueado.
  • Si es compatible con el dispositivo de bloque subyacente, se debe utilizar ioctl(BLKSECDISCARD) o equivalente. Para dispositivos MultiMediaCard (eMMC) integrados, esto significa utilizar un comando de borrado seguro o recorte seguro. Para eMMC 4.5 y 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 utilizar ioctl(BLKDISCARD) en su lugar. En dispositivos eMMC, esta es una operación de recorte normal.
  • Si no se admite BLKDISCARD , es aceptable sobrescribir los dispositivos de bloque con todos 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 utilizan 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 fue desbloqueado y/o vuelto a bloquear. Sin embargo, recomendamos encarecidamente que volver a bloquear el gestor de arranque y restablecer los valores de fábrica posteriormente restaure la funcionalidad completa del dispositivo.

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

Un dispositivo que está desbloqueado se puede volver a bloquear posteriormente utilizando el comando fastboot oem lock . Bloquear el gestor de arranque proporciona la misma protección de los datos del 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 del dispositivo

Los dispositivos deben ser revisados ​​por un pentester competente antes de su envío. El pentesting debe establecer que el dispositivo siguió las pautas de seguridad proporcionadas aquí, así como las pautas de seguridad internas del OEM.

Pruebas de seguridad

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

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