Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Cifrado basado en archivos

Android 7.0 y superior admite el cifrado basado en archivos (FBE). El cifrado basado en archivos permite cifrar diferentes archivos con diferentes claves que se pueden desbloquear de forma independiente.

Este artículo describe cómo habilitar el cifrado basado en archivos en nuevos dispositivos y cómo las aplicaciones del sistema pueden usar las API de arranque directo para ofrecer a los usuarios la mejor y más segura experiencia posible.

Arranque directo

El cifrado de archivos permite una nueva característica introducida en Android 7.0 llamada directa de arranque . Direct Boot permite que los dispositivos encriptados se inicien directamente en la pantalla de bloqueo. Anteriormente, en los dispositivos que utilizan cifrado cifrado de disco completo (FDE), los usuarios necesitan para proporcionar credenciales antes de que los datos podrían ser visitada, impidiendo el teléfono contra el desempeño de todos pero el más básico de las operaciones. Por ejemplo, las alarmas no podían funcionar, los servicios de accesibilidad no estaban disponibles y los teléfonos no podían recibir llamadas, pero estaban limitados a las operaciones básicas del marcador de emergencia.

Con la introducción del cifrado basado en archivos (FBE) y las nuevas API para que las aplicaciones conozcan el cifrado, es posible que estas aplicaciones funcionen en un contexto limitado. Esto puede suceder antes de que los usuarios hayan proporcionado sus credenciales y, al mismo tiempo, protejan la información privada del usuario.

En un dispositivo habilitado para FBE, cada usuario del dispositivo tiene dos ubicaciones de almacenamiento disponibles para las aplicaciones:

  • Almacenamiento con credenciales cifradas (CE), que es la ubicación de almacenamiento predeterminada y solo está disponible después de que el usuario haya desbloqueado el dispositivo.
  • Almacenamiento encriptado por dispositivo (DE), que es una ubicación de almacenamiento disponible tanto durante el modo de arranque directo como después de que el usuario haya desbloqueado el dispositivo.

Esta separación hace que los perfiles de trabajo sean más seguros porque permite proteger a más de un usuario a la vez, ya que el cifrado ya no se basa únicamente en una contraseña de inicio.

La API de arranque directo permite que las aplicaciones con cifrado accedan a cada una de estas áreas. Hay cambios en el ciclo de vida de aplicaciones para dar cabida a la necesidad de notificar a las aplicaciones cuando el almacenamiento de la CE de un usuario está desbloqueado en respuesta a las primeras credenciales que entra a la pantalla de bloqueo, o en el caso del perfil de trabajo que proporciona un desafío de trabajo . Los dispositivos que ejecutan Android 7.0 deben admitir estas nuevas API y ciclos de vida, independientemente de si implementan o no FBE. Aunque, sin FBE, el almacenamiento DE y CE siempre estará en estado desbloqueado.

En el Proyecto de código abierto de Android (AOSP) se proporciona una implementación completa del cifrado basado en archivos en los sistemas de archivos Ext4 y F2FS y solo debe habilitarse en dispositivos que cumplan con los requisitos. Los fabricantes que elijan utilizar FBE tal vez deseen explorar formas de optimizar la función en función del sistema en chip (SoC) utilizado.

Todos los paquetes necesarios en AOSP se han actualizado para que sean compatibles con el arranque directo. Sin embargo, cuando los fabricantes de dispositivos utilicen versiones personalizadas de estas aplicaciones, querrán asegurarse de que, como mínimo, haya paquetes compatibles con el arranque directo que brinden los siguientes servicios:

  • Servicios de telefonía y marcador
  • Método de entrada para ingresar contraseñas en la pantalla de bloqueo

Ejemplos y fuente

Android proporciona una implementación de referencia de cifrado basado en archivos, en el que vold ( sistema / vold ) proporciona la funcionalidad para la gestión de dispositivos de almacenamiento y volúmenes en Android. La adición de FBE proporciona a vold varios comandos nuevos para admitir la administración de claves para las claves CE y DE de múltiples usuarios. Además del núcleo cambia de utilizar los encriptación basados en archivos capacidades en el kernel, muchos paquetes del sistema, incluyendo la pantalla de bloqueo y el SystemUI se han modificado para apoyar la FBE y cuenta directa de arranque. Éstos incluyen:

  • Marcador AOSP (paquetes / aplicaciones / Marcador)
  • Reloj de escritorio (paquetes / aplicaciones / DeskClock)
  • LatinIME (paquetes / métodos de entrada / LatinIME) *
  • Aplicación de configuración (paquetes / aplicaciones / Configuración) *
  • SystemUI (frameworks / base / packages / SystemUI) *

* Las aplicaciones del sistema que utilizan el defaultToDeviceProtectedStorage atributo manifest

Más ejemplos de aplicaciones y servicios que son conscientes de cifrado se pueden encontrar mediante la ejecución del comando mangrep directBootAware en el directorio de marcos o paquetes del árbol de fuentes AOSP.

Dependencias

Para utilizar la implementación AOSP de FBE de forma segura, un dispositivo debe cumplir las siguientes dependencias:

  • El soporte para el cifrado o encriptación Ext4 f2fs.
  • Soporte Keymaster con una versión HAL 1,0 o 2,0. No hay soporte para Keymaster 0.3 ya que no proporciona las capacidades necesarias ni asegura una protección suficiente para las claves de cifrado.
  • Keymaster / almacén de claves y Gatekeeper deben implementarse en una ejecución de confianza para el Medio Ambiente (ETE) para proporcionar protección a las teclas DE manera que un sistema operativo no autorizado (OS costumbre apareció en el dispositivo) no puede simplemente pedir las llaves DE.
  • Se requiere hardware Raíz de Confianza y arranque verificado unido a la inicialización keymaster para asegurar que las credenciales de cifrado de dispositivos no son accesibles por un sistema operativo no autorizado.

Nota: las políticas de almacenamiento se aplican a una carpeta y todas sus subcarpetas. Los fabricantes deben limitar el contenido que no está encriptado a la carpeta OTA y la carpeta que contiene la clave que desencripta el sistema. La mayoría de los contenidos deben residir en un almacenamiento cifrado con credenciales en lugar de un almacenamiento cifrado con el dispositivo.

Implementación

Primero y ante todo, aplicaciones como reloj despertador, teléfono, funciones de accesibilidad deben hacerse androide: directBootAware según directo de arranque documentación para desarrolladores.

Soporte Kernel

La compatibilidad del kernel para el cifrado Ext4 y F2FS está disponible en los kernels comunes de Android, versión 3.18 y superior. Para habilitarlo en un kernel de la versión 5.1 o superior, use:

CONFIG_FS_ENCRYPTION=y

Para los núcleos de más edad, el uso CONFIG_EXT4_ENCRYPTION=y si su dispositivo de userdata del sistema de ficheros Ext4 es, o el uso CONFIG_F2FS_FS_ENCRYPTION=y si su dispositivo de userdata del sistema de ficheros es f2fs.

Si el dispositivo apoyará el almacenamiento adoptables o utilizará cifrado de metadatos en el almacenamiento interno, también activar las opciones de configuración del kernel necesarios para el cifrado de metadatos como se describe en la documentación de cifrado metadatos .

Además del soporte funcional para el cifrado Ext4 o F2FS, los fabricantes de dispositivos también deben habilitar la aceleración criptográfica para acelerar el cifrado basado en archivos y mejorar la experiencia del usuario. Por ejemplo, en dispositivos basados ​​en ARM64, la aceleración ARMv8 CE (Cryptography Extensions) se puede habilitar configurando las siguientes opciones de configuración del kernel:

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

Para mejorar aún más el rendimiento y reducir el consumo de energía, los fabricantes de dispositivos pueden también considerar la implementación de hardware de encriptación en línea, que cifra / descifra los datos mientras se está en el camino a / desde el dispositivo de almacenamiento. Los kernels comunes de Android (versión 4.14 y posteriores) contienen un marco que permite utilizar el cifrado en línea cuando el hardware y la compatibilidad con controladores de proveedores están disponibles. El marco de cifrado en línea se puede habilitar configurando las siguientes opciones de configuración del kernel:

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

Si su dispositivo utiliza almacenamiento basado en UFS, habilite también:

CONFIG_SCSI_UFS_CRYPTO=y

Si su dispositivo utiliza almacenamiento basado en eMMC, habilite también:

CONFIG_MMC_CRYPTO=y

Habilitación del cifrado basado en archivos

Activación de FBE en un dispositivo requiere que le permite en el almacenamiento interno ( userdata ). Esto también habilita automáticamente FBE en almacenamiento adoptable; sin embargo, el formato de cifrado en el almacenamiento adoptable puede anularse si es necesario.

Almacenamiento interno

FBE está activado añadiendo la opción fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] a la columna de fs_mgr_flags del fstab línea de userdata . Esta opción define el formato de cifrado en el almacenamiento interno. Contiene hasta tres parámetros separados por dos puntos:

  • Los contents_encryption_mode define parámetros que algoritmo criptográfico se utiliza para cifrar el contenido del archivo. Puede ser aes-256-xts o adiantum . Dado que Android 11 también puede dejarse vacío para especificar el algoritmo predeterminado, que es aes-256-xts .
  • Los filenames_encryption_mode define parámetros que algoritmo criptográfico se utiliza para cifrar los nombres de archivo. Puede ser aes-256-cts , aes-256-heh , o adiantum . Si no se especifica, el valor predeterminado es aes-256-cts si contents_encryption_mode es aes-256-xts , o para adiantum si contents_encryption_mode es adiantum .
  • La flags de parámetros, de nuevo en Android 11, se muestra una lista de banderas separadas por el + carácter. Se admiten las siguientes banderas:
    • El v1 políticas de la versión 1 de cifrado bandera selecciona; el v2 bandera selecciona la versión 2 políticas de cifrado. Versión 2 políticas de cifrado utilizan una más segura y flexible función de derivación de claves . El valor predeterminado es v2 si el dispositivo lanzado el Android 11 o superior (según lo determinado por ro.product.first_api_level ), o v1 si el dispositivo lanzado el Android 10 o inferior.
    • El inlinecrypt_optimized bandera selecciona un formato cifrado que está optimizado para el hardware de encriptación en línea que no maneja un gran número de llaves de manera eficiente. Para ello, deriva solo una clave de cifrado de contenido de archivo por clave CE o DE, en lugar de una por archivo. La generación de IV (vectores de inicialización) se ajusta en consecuencia.
    • El emmc_optimized bandera es similar a inlinecrypt_optimized , pero también selecciona un método de generación de IV que limita IVs a 32 bits. Esta marca solo debe usarse en hardware de cifrado en línea que cumpla con la especificación JEDEC eMMC v5.2 y, por lo tanto, solo admita IV de 32 bits. En otro hardware de encriptación en línea, utilice inlinecrypt_optimized lugar. Esta bandera nunca debe usarse en almacenamiento basado en UFS; la especificación UFS permite el uso de IV de 64 bits.
    • En dispositivos que admiten las teclas de hardware-envuelta , la wrappedkey_v0 bandera permite el uso de teclas de hardware envuelto para FBE. Esto sólo se puede utilizar en combinación con el inlinecrypt opción de montaje, y, o bien la inlinecrypt_optimized o emmc_optimized bandera.

Si no está utilizando hardware de encriptación en línea el ajuste recomendado para la mayoría de los dispositivos es fileencryption=aes-256-xts . Si está utilizando hardware de encriptación en línea el ajuste recomendado para la mayoría de los dispositivos es fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (o equivalentemente fileencryption=::inlinecrypt_optimized ). En dispositivos sin ninguna forma de AES aceleración, Adiantum se puede utilizar en lugar de AES configurando fileencryption=adiantum .

En los dispositivos que puso en marcha con Android 10 o inferior, fileencryption=ice también se acepta para especificar el uso de la FSCRYPT_MODE_PRIVATE modo de cifrado de archivos contenidos. Este modo no está implementado por los kernels comunes de Android, pero los proveedores podrían implementarlo mediante parches de kernel personalizados. El formato en disco producido por este modo era específico del proveedor. En los dispositivos que se inician con Android 11 o superior, este modo ya no está permitido y, en su lugar, se debe utilizar un formato de cifrado estándar.

De forma predeterminada, el cifrado del contenido de los archivos se realiza mediante la API de criptografía del kernel de Linux. Si desea utilizar el cifrado de hardware en línea en lugar, también añadir el inlinecrypt opción de montaje. Por ejemplo, una completa fstab línea podría ser:

/dev/block/by-name/userdata /data f2fs nodev,noatime,nosuid,errors=panic,inlinecrypt wait,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized

Almacenamiento adoptable

Dado que Android 9, FBE y almacenamiento adoptables se pueden utilizar juntos.

Especificación del fileencryption opción fstab para userdata también permite automáticamente tanto FBE y cifrado de metadatos en el almacenamiento adoptables. Sin embargo, es posible anular la FBE y / o formatos de codificación de metadatos en el almacenamiento adoptable por el establecimiento de propiedades en PRODUCT_PROPERTY_OVERRIDES .

En dispositivos que se lanzaron con Android 11 o superior, use las siguientes propiedades:

  • ro.crypto.volume.options (nuevo en Android 11) Selecciona el formato de cifrado FBE en el almacenamiento adoptables. Tiene la misma sintaxis que el argumento de la fileencryption opción fstab, y utiliza los mismos valores por defecto. Ver las recomendaciones para fileencryption arriba para qué usar aquí.
  • ro.crypto.volume.metadata.encryption selecciona el formato de cifrado de metadatos en el almacenamiento adoptables. Consulte la documentación de cifrado de metadatos .

En dispositivos que se lanzaron con Android 10 o versiones anteriores, use las siguientes propiedades:

  • ro.crypto.volume.contents_mode selecciona el modo de cifrado de contenido. Esto es equivalente al primer campo separados por dos puntos de ro.crypto.volume.options .
  • ro.crypto.volume.filenames_mode selecciona el modo de cifrado de nombres de archivo. Esto es equivalente al segundo campo separados por dos puntos de ro.crypto.volume.options , excepto que el valor predeterminado en los dispositivos que puso en marcha con Android 10 o inferior es aes-256-heh . En la mayoría de los dispositivos, esto tiene que ser anulado explícitamente a aes-256-cts .
  • ro.crypto.fde_algorithm y ro.crypto.fde_sector_size seleccionar el formato de cifrado de metadatos en el almacenamiento adoptables. Consulte la documentación de cifrado de metadatos .

Integrarse con Keymaster

La generación de claves y la gestión del llavero del núcleo es manejado por vold . La implementación AOSP de FBE requiere que el dispositivo admita Keymaster HAL versión 1.0 o posterior. No hay soporte para versiones anteriores de Keymaster HAL.

En el primer arranque, las claves del usuario 0 se generan e instalan al principio del proceso de arranque. En el momento en el on-post-fs fase init se completa, el Keymaster debe estar preparado para manejar las peticiones. En los dispositivos de píxeles, esto es manejado por tener un bloque de script asegurar Keymaster se inicia antes /data está montado.

Política de cifrado

El cifrado basado en archivos aplica la política de cifrado a nivel de directorio. Cuando un dispositivo de userdata se crea por primera partición, las estructuras y las políticas básicas son aplicadas por los init scripts. Estos scripts desencadenarán la creación de las claves CE y DE del primer usuario (0 del usuario) y definirán qué directorios se cifrarán con estas claves. Cuando se crean usuarios y perfiles adicionales, las claves adicionales necesarias se generan y almacenan en el almacén de claves; se crean las ubicaciones de almacenamiento de sus credenciales y dispositivos y la política de cifrado vincula estas claves a esos directorios.

En Android 11 y superior, la política de cifrado ya no está codificado en una ubicación centralizada, sino que se define por los argumentos a mkdir comandos en los scripts de inicio. Directorios cifrados con el sistema DE uso clave encryption=Require , mientras que los directorios sin cifrar (o directorios cuyos subdirectorios se cifran con claves por usuario) el uso encryption=None .

En Android 10, la política de cifrado estaba codificada en esta ubicación:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

En Android 9 y versiones anteriores, la ubicación era:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

Es posible agregar excepciones para evitar que ciertos directorios se cifren en absoluto. Si las modificaciones de este tipo se hacen entonces el fabricante del dispositivo debe incluir políticas de SELinux para conceder acceso únicamente a las aplicaciones que necesitan utilizar el directorio sin cifrar. Esto debería excluir todas las aplicaciones que no sean de confianza.

El único caso de uso aceptable conocido para esto es el soporte de capacidades OTA heredadas.

Soporte de arranque directo en aplicaciones del sistema

Hacer que las aplicaciones sean compatibles con el arranque directo

Para facilitar la migración rápida de las aplicaciones del sistema, hay dos nuevos atributos que se pueden configurar en el nivel de la aplicación. El defaultToDeviceProtectedStorage atributo está disponible sólo para aplicaciones del sistema. El directBootAware atributo está disponible para todos.

<application
    android:directBootAware="true"
    android:defaultToDeviceProtectedStorage="true">

El directBootAware atributo a nivel de aplicación es la abreviatura para el marcado de todos los componentes en la aplicación como siendo cifrado conscientes.

El defaultToDeviceProtectedStorage atributo redirige la ubicación de almacenamiento de aplicación por defecto a punto en el DE de almacenamiento en lugar de señalar al almacenamiento de la CE. Las aplicaciones del sistema que usan esta marca deben auditar cuidadosamente todos los datos almacenados en la ubicación predeterminada y cambiar las rutas de los datos confidenciales para usar el almacenamiento CE. Los fabricantes de dispositivos que utilizan esta opción deben inspeccionar cuidadosamente los datos que están almacenando para asegurarse de que no contengan información personal.

Cuando se ejecuta en este modo, las siguientes API del sistema están disponibles para administrar explícitamente un contexto respaldado por almacenamiento CE cuando sea necesario, que son equivalentes a sus contrapartes con dispositivo protegido.

  • Context.createCredentialProtectedStorageContext()
  • Context.isCredentialProtectedStorage()

Apoyar a múltiples usuarios

Cada usuario en un entorno multiusuario obtiene una clave de cifrado independiente. Cada usuario obtiene dos claves: una DE y una CE. El usuario 0 debe iniciar sesión en el dispositivo primero, ya que es un usuario especial. Esto es pertinente para administración del dispositivo usos.

Aplicaciones cripto-aware interactuar con los usuarios de esta manera: INTERACT_ACROSS_USERS y INTERACT_ACROSS_USERS_FULL permiten que una aplicación para actuar en todos los usuarios en el dispositivo. Sin embargo, esas aplicaciones solo podrán acceder a directorios encriptados con CE para usuarios que ya estén desbloqueados.

Una aplicación puede interactuar libremente en las áreas de DE, pero un usuario desbloqueado no significa que todos los usuarios del dispositivo estén desbloqueados. La aplicación debe verificar este estado antes de intentar acceder a estas áreas.

Cada ID de usuario de perfil de trabajo también obtiene dos claves: DE y CE. Cuando se cumple el desafío laboral, el usuario del perfil se desbloquea y el Keymaster (en TEE) puede proporcionar la clave TEE del perfil.

Manejo de actualizaciones

La partición de recuperación no puede acceder al almacenamiento protegido por DE en la partición de datos de usuario. Dispositivos de aplicación FBE son muy recomendables para el apoyo OTA utilizando las actualizaciones del sistema A / B . Como la OTA se puede aplicar durante el funcionamiento normal, no es necesario realizar una recuperación para acceder a los datos de la unidad cifrada.

Cuando se utiliza una solución OTA legado, lo que requiere la recuperación para acceder al archivo de OTA en el userdata partición:

  1. Crear un directorio de nivel superior (por ejemplo misc_ne ) en el userdata partición.
  2. Añadir este directorio de nivel superior a la excepción de orden de cifrado (ver política de cifrado más arriba).
  3. Cree un directorio dentro del directorio de nivel superior para contener paquetes OTA.
  4. Agregue una regla SELinux y contextos de archivo para controlar el acceso a esta carpeta y su contenido. Solo el proceso o las aplicaciones que reciben actualizaciones OTA deberían poder leer y escribir en esta carpeta. Ninguna otra aplicación o proceso debería tener acceso a esta carpeta.

Validación

Para garantizar la versión en práctica de las obras de características como se pretende, en primer lugar ejecutar las muchas pruebas de cifrado CTS, como DirectBootHostTest y EncryptionTest .

Si el dispositivo ejecuta Android 11 o superior, también correr vts_kernel_encryption_test :

atest vts_kernel_encryption_test

o:

vts-tradefed run vts -m vts_kernel_encryption_test

Además, los fabricantes de dispositivos pueden realizar las siguientes pruebas manuales. En un dispositivo con FBE habilitado:

  • Compruebe que ro.crypto.state existe
    • Asegurar ro.crypto.state está cifrada
  • Compruebe que ro.crypto.type existe
    • Garantizar ro.crypto.type se establece en file

Además, los probadores pueden arrancar una userdebug ejemplo con un conjunto de pantalla de bloqueo en el usuario primario. Entonces adb shell en el dispositivo y el uso su para convertirse en raíz. Asegúrese /data/data contiene los nombres de archivos cifrados; si no es así, algo anda mal.

También se alienta a los fabricantes de dispositivos para explorar corriendo las pruebas de Linux aguas arriba de fscrypt en sus dispositivos o granos. Estas pruebas son parte del conjunto de pruebas del sistema de archivos xfstests. Sin embargo, estas pruebas ascendentes no son oficialmente compatibles con Android.

Detalles de implementación de AOSP

Esta sección proporciona detalles sobre la implementación de AOSP y describe cómo funciona el cifrado basado en archivos. No debería ser necesario que los fabricantes de dispositivos realicen cambios aquí para usar FBE y Direct Boot en sus dispositivos.

cifrado fscrypt

La implementación de AOSP utiliza el cifrado "fscrypt" (compatible con ext4 y f2fs) en el kernel y normalmente está configurado para:

  • Cifre el contenido del archivo con AES-256 en modo XTS
  • Cifre nombres de archivos con AES-256 en modo CBC-CTS

Adiantum cifrado también es compatible. Cuando el cifrado de Adiantum está habilitado, tanto el contenido de los archivos como los nombres de los archivos se cifran con Adiantum.

Para obtener más información acerca de fscrypt, consulte la documentación del núcleo aguas arriba .

Derivación de claves

Las claves de cifrado basadas en archivos, que son claves de 512 bits, se almacenan cifradas por otra clave (una clave AES-GCM de 256 bits) contenida en el TEE. Para utilizar esta llave TEE, se deben cumplir tres requisitos:

  • El token de autenticación
  • La credencial estirada
  • El "hash secdiscardable"

El auth token es un criptográficamente autenticado contador generado por el controlador de acceso cuando un usuario inicia una sesión con éxito en. El tee se negará a utilizar la clave a menos que se suministra el token de autenticación correcta. Si el usuario no tiene credenciales, no se usa ni se necesita ningún token de autenticación.

La credencial de estirado es la credencial de usuario después de la salazón y se extiende con la scrypt algoritmo. La credencial es en realidad hash una vez en servicio el bloqueo de configuración antes de ser pasado a vold para pasar a scrypt . Esto se ve obligada a criptográficamente la llave en la ETE con todas las garantías que se aplican a KM_TAG_APPLICATION_ID . Si el usuario no tiene credenciales, no se usa ni se necesita ninguna credencial extendida.

El secdiscardable hash es un 512-bit hash de un archivo de 16 KB aleatorio guardado junto con otra información utilizada para reconstruir la clave, tales como la semilla. Este archivo se elimina de forma segura cuando se elimina la clave o se cifra de una manera nueva; Esta protección adicional garantiza que un atacante deba recuperar cada parte de este archivo eliminado de forma segura para recuperar la clave. Esto se ve obligada a criptográficamente la llave en la ETE con todas las garantías que se aplican a KM_TAG_APPLICATION_ID .

En la mayoría de los casos, las claves FBE también se someten a un paso adicional de derivación de claves en el kernel para generar las subclaves que realmente se utilizan para realizar el cifrado, por ejemplo, claves por archivo o por modo. Para las políticas de cifrado de la versión 2, se utiliza HKDF-SHA512 para esto.