Cifrado basado en archivos

Android 7.0 y versiones posteriores admiten 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.

Todos los dispositivos que se inician con Android 10 y versiones posteriores deben usar cifrado basado en archivos.

Precaución : en Android 7.0–8.1, FBE no es compatible con el almacenamiento adoptable y los medios de almacenamiento externo (como una tarjeta SD) solo se pueden usar como almacenamiento tradicional . En Android 9 y versiones posteriores, FBE es compatible con el almacenamiento adoptable.

Arranque directo

El cifrado basado en archivos habilita una nueva característica introducida en Android 7.0 llamada Arranque directo . Direct Boot permite que los dispositivos encriptados arranquen directamente en la pantalla de bloqueo. Anteriormente, en dispositivos encriptados que usaban encriptación de disco completo (FDE), los usuarios debían proporcionar credenciales antes de poder acceder a los datos, lo que impedía que el teléfono realizara todas las operaciones excepto las más básicas. 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 operaciones básicas de marcación de emergencia.

Con la introducción del cifrado basado en archivos (FBE) y las nuevas API para que las aplicaciones reconozcan el cifrado, es posible que estas aplicaciones operen dentro de un contexto limitado. Esto puede ocurrir antes de que los usuarios hayan proporcionado sus credenciales mientras se sigue protegiendo 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 de Credential Encrypted (CE), que es la ubicación de almacenamiento predeterminada y solo está disponible después de que el usuario haya desbloqueado el dispositivo.
• Almacenamiento de dispositivo cifrado (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.

Nota : siempre que sea posible, los archivos deben residir en el almacenamiento de CE.

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 arranque.

La API de arranque directo permite que las aplicaciones con reconocimiento de cifrado accedan a cada una de estas áreas. Hay cambios en el ciclo de vida de la aplicación para adaptarse a la necesidad de notificar a las aplicaciones cuando el almacenamiento de CE de un usuario está desbloqueado en respuesta al primer ingreso de credenciales en la pantalla de bloqueo, o en el caso de un perfil de trabajo que presenta un desafío laboral . Los dispositivos que ejecutan Android 7.0 deben ser compatibles con 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.

Se proporciona una implementación completa de cifrado basado en archivos en los sistemas de archivos Ext4 y F2FS en el Proyecto de código abierto de Android (AOSP) y solo debe habilitarse en dispositivos que cumplan con los requisitos. Es posible que los fabricantes que opten por usar FBE 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 reconocer 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 la que vold ( system/vold ) proporciona la funcionalidad para administrar dispositivos y volúmenes de almacenamiento 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 de los cambios principales para usar las capacidades de encriptación basadas en archivos en el kernel , muchos paquetes del sistema, incluidos LockScreen y SystemUI, se han modificado para admitir las funciones FBE y Direct Boot. Éstas 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 (marcos/base/paquetes/SystemUI)*

* Aplicaciones del sistema que usan el atributo de manifiesto defaultToDeviceProtectedStorage

Se pueden encontrar más ejemplos de aplicaciones y servicios que son compatibles con el cifrado ejecutando el comando mangrep directBootAware en el directorio de marcos o paquetes del árbol fuente de AOSP.

dependencias

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

• Soporte de kernel para cifrado Ext4 o cifrado F2FS.
• Soporte Keymaster con HAL versión 1.0 o superior. No hay soporte para Keymaster 0.3, ya que no proporciona las capacidades necesarias ni garantiza una protección suficiente para las claves de cifrado.
• Keymaster/ Keystore y Gatekeeper deben implementarse en un entorno de ejecución de confianza (TEE) para brindar protección a las claves DE de modo que un sistema operativo no autorizado (sistema operativo personalizado instalado en el dispositivo) no pueda simplemente solicitar las claves DE.
• Se requiere raíz de confianza de hardware y arranque verificado vinculado a la inicialización de Keymaster para garantizar que un sistema operativo no autorizado no pueda acceder a las claves DE.

Implementación

En primer lugar, las aplicaciones como los relojes de alarma, el teléfono y las funciones de accesibilidad deben hacerse android:directBootAware de acuerdo con la documentación del desarrollador de arranque directo .

Soporte del núcleo

El soporte de 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 que es la versión 5.1 o superior, utilice:

CONFIG_FS_ENCRYPTION=y

Para kernels más antiguos, use CONFIG_EXT4_ENCRYPTION=y si el sistema de archivos userdata de su dispositivo es Ext4, o use CONFIG_F2FS_FS_ENCRYPTION=y si el sistema de archivos userdata de su dispositivo es F2FS.

Si su dispositivo admitirá el almacenamiento adoptable o utilizará el cifrado de metadatos en el almacenamiento interno, habilite también las opciones de configuración del kernel necesarias para el cifrado de metadatos como se describe en la documentación de cifrado de metadatos .

Además del soporte funcional para el cifrado Ext4 o F2FS, los fabricantes de dispositivos también deberían 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 uso de energía, los fabricantes de dispositivos también pueden considerar implementar hardware de cifrado en línea , que cifra/descifra los datos mientras se encuentran en el camino hacia/desde el dispositivo de almacenamiento. Los núcleos comunes de Android (versión 4.14 y superior) contienen un marco que permite el uso de cifrado en línea cuando el hardware y el soporte del controlador del proveedor 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 usa almacenamiento basado en UFS, habilite también:

CONFIG_SCSI_UFS_CRYPTO=y

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

CONFIG_MMC_CRYPTO=y

Habilitación del cifrado basado en archivos

Habilitar FBE en un dispositivo requiere habilitarlo 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 se habilita agregando la opción fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] a la columna fs_mgr_flags de la línea fstab para userdata . Esta opción define el formato de cifrado en el almacenamiento interno. Contiene hasta tres parámetros separados por dos puntos:

• El parámetro contents_encryption_mode define qué algoritmo criptográfico se utiliza para cifrar el contenido del archivo. Puede ser aes-256-xts o adiantum . Desde Android 11 también se puede dejar en blanco para especificar el algoritmo predeterminado, que es aes-256-xts .
• El parámetro filenames_encryption_mode define qué algoritmo criptográfico se utiliza para cifrar los nombres de los archivos. Puede ser aes-256-cts , aes-256-heh , adiantum o aes-256-hctr2 . Si no se especifica, el valor predeterminado es aes-256-cts si contents_encryption_mode es aes-256-xts o adiantum si contents_encryption_mode es adiantum .
• El parámetro flags , nuevo en Android 11, es una lista de banderas separadas por el carácter + . Se admiten las siguientes banderas:
  • El indicador v1 selecciona las políticas de cifrado de la versión 1; el indicador v2 selecciona las políticas de cifrado de la versión 2. Las políticas de cifrado de la versión 2 utilizan una función de derivación de claves más segura y flexible. El valor predeterminado es v2 si el dispositivo se lanzó en Android 11 o superior (según lo determinado por ro.product.first_api_level ), o v1 si el dispositivo se lanzó en Android 10 o inferior.
  • El indicador inlinecrypt_optimized selecciona un formato de cifrado que está optimizado para hardware de cifrado en línea que no maneja grandes cantidades de claves de manera eficiente. Lo hace derivando 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 indicador emmc_optimized es similar a inlinecrypt_optimized , pero también selecciona un método de generación de IV que limita los IV a 32 bits. Este indicador 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 cifrado en línea, use inlinecrypt_optimized en su lugar. Esta marca nunca debe usarse en almacenamiento basado en UFS; la especificación UFS permite el uso de IV de 64 bits.
  • En los dispositivos que admiten claves encapsuladas en hardware , la marca wrappedkey_v0 permite el uso de claves encapsuladas en hardware para FBE. Esto solo se puede usar en combinación con la opción de montaje inlinecrypt y el indicador inlinecrypt_optimized o emmc_optimized .

Si no utiliza hardware de cifrado en línea, la configuración recomendada para la mayoría de los dispositivos es fileencryption=aes-256-xts . Si utiliza hardware de cifrado en línea, la configuración recomendada para la mayoría de los dispositivos es fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (o equivalente fileencryption=::inlinecrypt_optimized ). En dispositivos sin ningún tipo de aceleración AES, se puede usar Adiantum en lugar de AES configurando fileencryption=adiantum .

Desde Android 14 (AOSP experimental), AES-HCTR2 es el modo preferido de cifrado de nombres de archivo para dispositivos con instrucciones de criptografía aceleradas. Sin embargo, solo los kernels de Android más nuevos son compatibles con AES-HCTR2. En una futura versión de Android, está previsto que se convierta en el modo predeterminado para el cifrado de nombres de archivo. Si su kernel es compatible con AES-HCTR2, puede habilitarse para el cifrado de nombres de archivo configurando filenames_encryption_mode en aes-256-hctr2 . En el caso más simple, esto se haría con fileencryption=aes-256-xts:aes-256-hctr2 .

En dispositivos que se lanzaron con Android 10 o anterior, también se acepta fileencryption=ice para especificar el uso del modo de cifrado de contenido de archivo FSCRYPT_MODE_PRIVATE . Los núcleos comunes de Android no implementan este modo, pero los proveedores pueden implementarlo mediante parches de núcleo 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 se debe usar un formato de cifrado estándar en su lugar.

Precaución : Dado que la opción fileencryption define el formato en el disco, una OTA no puede cambiarlo.

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 hardware de cifrado en línea, agregue también la opción de montaje inlinecrypt . Por ejemplo, una línea fstab completa podría verse así:

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

Nota :

• Las opciones de inlinecrypt y fileencryption van en columnas diferentes, ya que inlinecrypt es una opción de montaje del sistema de archivos, mientras que fileencryption es una marca para el espacio de usuario de Android.
• Si su hardware de cifrado en línea funciona correctamente y el indicador wrappedkey_v0 no está configurado, la opción de montaje inlinecrypt se puede agregar o eliminar en cualquier momento sin borrar el dispositivo. En otras palabras, a menos que las claves envueltas en hardware estén habilitadas, inlinecrypt solo debería afectar la implementación, no el formato en disco. Debe probar la eliminación inlinecrypt durante el desarrollo para verificar que su hardware de cifrado en línea funcione correctamente.

Almacenamiento adoptable

Desde Android 9, FBE y el almacenamiento adoptable se pueden usar juntos.

Especificar la opción fstab fileencryption para userdata también habilita automáticamente el cifrado de metadatos y FBE en el almacenamiento adoptable. Sin embargo, puede anular los formatos de cifrado de metadatos o FBE en el almacenamiento adoptable configurando las 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 adoptable. Tiene la misma sintaxis que el argumento de la opción fstab fileencryption y utiliza los mismos valores predeterminados. Consulte las recomendaciones para fileencryption anteriores para saber qué usar aquí.
• ro.crypto.volume.metadata.encryption selecciona el formato de cifrado de metadatos en el almacenamiento adoptable. Consulte la documentación de cifrado de metadatos .

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

• ro.crypto.volume.contents_mode selecciona el modo de cifrado de contenido. Esto es equivalente al primer campo separado 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 separado por dos puntos de ro.crypto.volume.options , excepto que el valor predeterminado en los dispositivos que se iniciaron con Android 10 o inferior es aes-256-heh . En la mayoría de los dispositivos, esto debe anularse explícitamente a aes-256-cts .
• ro.crypto.fde_algorithm y ro.crypto.fde_sector_size seleccionan el formato de cifrado de metadatos en el almacenamiento adoptable. Consulte la documentación de cifrado de metadatos .

Precaución : en los dispositivos que se lanzaron con Android 10 o versiones anteriores, el modo de cifrado de nombres de archivo predeterminado en el almacenamiento adoptable no era válido en la mayoría de los dispositivos y difería del modo predeterminado en el almacenamiento interno. Por lo tanto, en dichos dispositivos debe anularse explícitamente, generalmente a aes-256-cts .

Integración con Keymaster

Keymaster HAL debe iniciarse como parte de la clase early_hal . Esto se debe a que FBE requiere que Keymaster esté listo para manejar las solicitudes en la fase de arranque post-fs-data , que es cuando vold configura las claves iniciales.

Excluyendo directorios

init aplica la clave DE del sistema a todos los directorios de nivel superior de /data , excepto los directorios que deben estar sin cifrar: el directorio que contiene la clave DE del sistema y los directorios que contienen los directorios CE o DE del usuario. Las claves de cifrado se aplican de forma recursiva y los subdirectorios no pueden anularlas.

En Android 11 y versiones posteriores, la clave que init aplica a los directorios puede controlarse mediante el argumento encryption=<action> del comando mkdir en los scripts de inicio. Los posibles valores de <action> están documentados en el LÉAME para el idioma de inicio de Android .

En Android 10, las acciones de cifrado init se codificaron en la siguiente 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. Si se realizan modificaciones de este tipo, el fabricante del dispositivo debe incluir políticas de SELinux que solo otorguen acceso a las aplicaciones que necesitan usar 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 en apoyo de las capacidades OTA heredadas.

Compatibilidad con arranque directo en aplicaciones del sistema

Hacer que las aplicaciones sean conscientes del 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 atributo defaultToDeviceProtectedStorage solo está disponible para las aplicaciones del sistema. El atributo directBootAware está disponible para todos.

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

El atributo directBootAware en el nivel de la aplicación es una forma abreviada de marcar todos los componentes de la aplicación como compatibles con el cifrado.

El atributo defaultToDeviceProtectedStorage redirige la ubicación de almacenamiento de la aplicación predeterminada para que apunte al almacenamiento DE en lugar de apuntar al almacenamiento CE. Las aplicaciones del sistema que usan este indicador 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 usan 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 protegidas por dispositivo.

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

Soporte para múltiples usuarios

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

Las aplicaciones con reconocimiento de cifrado interactúan entre los usuarios de esta manera: INTERACT_ACROSS_USERS e INTERACT_ACROSS_USERS_FULL permiten que una aplicación actúe entre todos los usuarios del dispositivo. Sin embargo, esas aplicaciones solo podrán acceder a directorios cifrados 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 debería comprobar este estado antes de intentar acceder a estas áreas.

Cada ID de usuario del 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 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. Se recomienda encarecidamente que los dispositivos que implementan FBE admitan OTA mediante 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 en la unidad cifrada.

Al usar una solución OTA heredada, que requiere recuperación para acceder al archivo OTA en la partición userdata :

1. Cree un directorio de nivel superior (por ejemplo misc_ne ) en la partición userdata .
2. Configure este directorio de nivel superior para que no esté cifrado (consulte Exclusión de directorios ).
3. Cree un directorio dentro del directorio de nivel superior para almacenar paquetes OTA.
4. Agregue una regla de SELinux y contextos de archivo para controlar el acceso a este directorio y su contenido. Solo el proceso o las aplicaciones que reciben actualizaciones OTA deben poder leer y escribir en este directorio. Ninguna otra aplicación o proceso debe tener acceso a este directorio.

Validación

Para asegurarse de que la versión implementada de la función funcione según lo previsto, primero ejecute las numerosas pruebas de cifrado CTS, como DirectBootHostTest y EncryptionTest .

Si el dispositivo ejecuta Android 11 o superior, también ejecute 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 existe ro.crypto.state
  • Asegúrese de que ro.crypto.state esté encriptado
• Compruebe que existe ro.crypto.type
  • Asegúrese de ro.crypto.type esté configurado en file

Además, los evaluadores pueden iniciar una instancia userdebug con una pantalla de bloqueo configurada en el usuario principal. Luego adb shell en el dispositivo y use su para convertirse en root. Asegúrese de que /data/data contenga nombres de archivos cifrados; si no es así, algo anda mal.

También se alienta a los fabricantes de dispositivos a explorar la ejecución de las pruebas de Linux upstream para fscrypt en sus dispositivos o kernels. 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 ningún cambio 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 núcleo y normalmente está configurado para:

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

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

fscrypt admite dos versiones de políticas de cifrado: versión 1 y versión 2. La versión 1 está en desuso y los requisitos de CDD para dispositivos que se inician con Android 11 y versiones posteriores solo son compatibles con la versión 2. Las políticas de cifrado de la versión 2 usan HKDF-SHA512 para derivar el claves de cifrado de las claves proporcionadas por el espacio de usuario.

Para obtener más información sobre fscrypt, consulte la documentación del núcleo original .

Clases de almacenamiento

La siguiente tabla enumera las claves FBE y los directorios que protegen con más detalle:

clase de almacenamiento	Descripción	Directorios
Sistema DE	Datos encriptados del dispositivo no vinculados a un usuario en particular	/data/system , /data/app , y varios otros subdirectorios de /data
por arranque	Archivos de sistema efímeros que no necesitan sobrevivir a un reinicio	/data/per_boot
Usuario CE (interno)	Datos cifrados con credenciales por usuario en el almacenamiento interno	/data/data (alias de /data/user/0 ) /data/media/${user_id} /data/misc_ce/${user_id} /data/system_ce/${user_id} /data/user/${user_id} /data/vendor_ce/${user_id}
Usuario DE (interno)	Datos cifrados por dispositivo por usuario en el almacenamiento interno	/data/misc_de/${user_id} /data/system_de/${user_id} /data/user_de/${user_id} /data/vendor_de/${user_id}
Usuario CE (adoptable)	Datos cifrados con credenciales por usuario en almacenamiento adoptable	/mnt/expand/${volume_uuid}/media/${user_id} /mnt/expand/${volume_uuid}/misc_ce/${user_id} /mnt/expand/${volume_uuid}/user/${user_id}
Usuario DE (adoptable)	Datos cifrados por dispositivo por usuario en almacenamiento adoptable	/mnt/expand/${volume_uuid}/misc_de/${user_id} /mnt/expand/${volume_uuid}/user_de/${user_id}

Almacenamiento y protección de claves

vold administra todas las claves de FBE y se almacenan cifradas en el disco, excepto la clave por arranque, que no se almacena en absoluto. La siguiente tabla enumera las ubicaciones en las que se almacenan las distintas claves FBE:

tipo de clave	Ubicación clave	Clase de almacenamiento de ubicación clave
Clave del sistema DE	/data/unencrypted	sin cifrar
Claves de usuario CE (internas)	/data/misc/vold/user_keys/ce/${user_id}	Sistema DE
Claves de usuario DE (internas)	/data/misc/vold/user_keys/de/${user_id}	Sistema DE
Claves de usuario CE (adoptables)	/data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid}	Usuario CE (interno)
Claves de usuario DE (adoptables)	/data/misc_de/${user_id}/vold/volume_keys/${volume_uuid}	Usuario DE (interno)

Como se muestra en la tabla anterior, la mayoría de las claves de FBE se almacenan en directorios que están encriptados por otra clave de FBE. Las claves no se pueden desbloquear hasta que se haya desbloqueado la clase de almacenamiento que las contiene.

vold también aplica una capa de cifrado a todas las claves FBE. Todas las claves, además de las claves CE para el almacenamiento interno, se cifran con AES-256-GCM utilizando su propia clave Keystore que no está expuesta fuera del TEE. Esto garantiza que las claves FBE no se puedan desbloquear a menos que se haya iniciado un sistema operativo de confianza, tal como lo exige Verified Boot . La resistencia a la reversión también se solicita en la clave Keystore, lo que permite que las claves FBE se eliminen de forma segura en dispositivos donde Keymaster admite la resistencia a la reversión. Como alternativa de mejor esfuerzo para cuando la resistencia de reversión no está disponible, el hash SHA-512 de 16384 bytes aleatorios almacenados en el archivo secdiscardable almacenado junto con la clave se usa como la etiqueta de identificación de la aplicación de la clave Keystore. Todos estos bytes deben recuperarse para recuperar una clave FBE.

Las claves CE para el almacenamiento interno reciben un mayor nivel de protección que garantiza que no se puedan desbloquear sin conocer el factor de conocimiento de la pantalla de bloqueo (LSKF) del usuario (PIN, patrón o contraseña), un token de restablecimiento de código de acceso seguro o ambos del lado del cliente. y claves del lado del servidor para una operación de Resume-on-Reboot . Los tokens de restablecimiento de contraseña solo se pueden crear para perfiles de trabajo y dispositivos totalmente administrados .

Para lograr esto, vold encripta cada clave CE para el almacenamiento interno utilizando una clave AES-256-GCM derivada de la contraseña sintética del usuario. La contraseña sintética es un secreto criptográfico inmutable de alta entropía que se genera aleatoriamente para cada usuario. LockSettingsService en system_server administra la contraseña sintética y las formas en que se protege.

Para proteger la contraseña sintética con la LSKF, LockSettingsService primero extiende la LSKF pasándola a través de scrypt , con un objetivo de aproximadamente 25 ms y un uso de memoria de aproximadamente 2 MiB. Dado que los LSKF suelen ser cortos, este paso no suele proporcionar mucha seguridad. La capa principal de seguridad es el elemento seguro (SE) o límite de velocidad impuesto por TEE que se describe a continuación.

Si el dispositivo tiene un elemento seguro (SE), entonces LockSettingsService asigna el LSKF extendido a un secreto aleatorio de alta entropía almacenado en el SE usando Weaver HAL . LockSettingsService luego cifra la contraseña sintética dos veces: primero con una clave de software derivada del LSKF ampliado y el secreto de Weaver, y segundo con una clave del almacén de claves no vinculada a la autenticación. Esto proporciona una limitación de tasa impuesta por SE de conjeturas LSKF.

Si el dispositivo no tiene un SE, entonces LockSettingsService usa el LSKF ampliado como contraseña de Gatekeeper . LockSettingsService luego encripta la contraseña sintética dos veces: primero con una clave de software derivada de la LSKF ampliada y el hash de un archivo secdiscardable, y segundo con una clave Keystore que está vinculada a la autenticación de la inscripción de Gatekeeper. Esto proporciona una limitación de tasa impuesta por TEE de conjeturas LSKF.

Cuando se cambia la LSKF, LockSettingsService elimina toda la información asociada con el enlace de la contraseña sintética a la antigua LSKF. En los dispositivos que admiten Weaver o claves Keystore resistentes a la reversión, esto garantiza la eliminación segura de la vinculación anterior. Por esta razón, las protecciones descritas aquí se aplican incluso cuando el usuario no tiene una LSKF.