Cifrado basado en archivos

Android 7.0 y versiones posteriores admiten 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 dispositivos nuevos 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 utilizar 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 externos (como una tarjeta SD) solo se pueden usar como almacenamiento tradicional . En Android 9 y superiores, FBE es compatible con almacenamiento adoptable.

Arranque directo

El cifrado basado en archivos habilita una nueva característica introducida en Android 7.0 llamada Arranque directo . El arranque directo permite que los dispositivos cifrados se inicien directamente en la pantalla de bloqueo. Anteriormente, en dispositivos cifrados que utilizaban cifrado de disco completo (FDE), los usuarios debían proporcionar credenciales antes de poder acceder a cualquier dato, 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, sino que se limitaban únicamente a operaciones básicas de marcador de emergencia.

Con la introducción del cifrado basado en archivos (FBE) y nuevas API para que las aplicaciones sean conscientes del cifrado, es posible que estas aplicaciones funcionen dentro de un contexto limitado. Esto puede suceder antes de que los usuarios hayan proporcionado sus credenciales y al mismo tiempo proteger 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 cifrado de dispositivo (DE), que es una ubicación de almacenamiento disponible tanto durante el modo de inicio directo como después de que el usuario haya desbloqueado el dispositivo.

Nota : Siempre que sea posible, los archivos deben residir en el almacenamiento 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 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 la aplicación para adaptarse a la necesidad de notificar a las aplicaciones cuando el almacenamiento CE de un usuario se desbloquea en respuesta al ingreso inicial 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 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 de cifrado basado en archivos en los sistemas de archivos Ext4 y F2FS y solo debe habilitarse en dispositivos que cumplan con los requisitos. Es posible que los fabricantes que opten por utilizar 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 que admitan 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 proporcionen 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 incorporación de FBE proporciona a vold varios comandos nuevos para admitir la administración de claves CE y DE de múltiples usuarios. Además de los cambios principales para utilizar las capacidades de cifrado basado 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 utilizan el atributo de manifiesto defaultToDeviceProtectedStorage

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

Dependencias

Para utilizar 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 de 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 confiable (TEE) para brindar protección a las claves DE, de modo que un sistema operativo no autorizado (SO personalizado instalado en el dispositivo) no pueda simplemente solicitar las claves DE.
• Se requiere raíz de confianza de hardware y arranque verificado vinculados 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 despertadores, teléfonos y funciones de accesibilidad deben crearse como android:directBootAware de acuerdo con la documentación para desarrolladores de Direct Boot .

Soporte del núcleo

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

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á almacenamiento adoptable o utilizará 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 (Extensiones de criptografía) 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 están en camino hacia/desde el dispositivo de almacenamiento. Los núcleos comunes de Android (versión 4.14 y superiores) contienen un marco que permite utilizar el cifrado en línea cuando está disponible el soporte de hardware y controladores del proveedor. 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

Habilitar el cifrado basado en archivos

Para habilitar FBE en un dispositivo es necesario 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 vacío 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 flags separadas por el carácter + . Se admiten las siguientes banderas:
  • La bandera v1 selecciona 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 inició con Android 11 o superior (según lo determinado por ro.product.first_api_level ), o v1 si el dispositivo se inició con Android 10 o inferior.
  • El indicador inlinecrypt_optimized selecciona un formato de cifrado optimizado para hardware de cifrado en línea que no maneja grandes cantidades de claves de manera eficiente. Para ello, obtiene solo una clave de cifrado del contenido del 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, utilice 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 dispositivos que admiten claves empaquetadas en hardware , el indicador wrappedkey_v0 permite el uso de claves empaquetadas 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 .
  • El indicador dusize_4k fuerza que el tamaño de la unidad de datos de cifrado sea de 4096 bytes incluso cuando el tamaño del bloque del sistema de archivos no sea de 4096 bytes. El tamaño de la unidad de datos de cifrado es la granularidad del cifrado del contenido del archivo. Esta bandera está disponible desde Android 15 (AOSP experimental). Este indicador solo debe usarse para habilitar el uso de hardware de cifrado en línea que no admita unidades de datos mayores a 4096 bytes, en un dispositivo que use un tamaño de página mayor a 4096 bytes y que use el sistema de archivos f2fs.

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 equivalentemente 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, AES-HCTR2 es el modo preferido de cifrado de nombres de archivos para dispositivos con instrucciones de criptografía acelerada. Sin embargo, sólo 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 archivos. Si su kernel es compatible con AES-HCTR2, puede habilitarlo para el cifrado de nombres de archivos 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 iniciaron con Android 10 o inferior, también se acepta fileencryption=ice para especificar el uso del modo de cifrado del contenido del archivo FSCRYPT_MODE_PRIVATE . Este modo no está implementado en 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 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.

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 del archivo 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 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 bandera 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 empaquetadas en hardware estén habilitadas, inlinecrypt solo debería afectar la implementación, no el formato en el disco. Debe probar la eliminación inlinecrypt durante el desarrollo para verificar que su hardware de cifrado en línea esté funcionando correctamente.

Almacenamiento adoptable

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

Al especificar la opción fstab fileencryption para userdata , también se habilita automáticamente el cifrado de metadatos y FBE en el almacenamiento adoptable. Sin embargo, puede anular los formatos de cifrado de metadatos y/o FBE en el almacenamiento adoptable estableciendo propiedades en PRODUCT_PROPERTY_OVERRIDES .

En dispositivos que se iniciaron 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 anteriores para fileencryption 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 sobre cifrado de metadatos .

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

• ro.crypto.volume.contents_mode selecciona el modo de cifrado de contenidos. 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 archivos. Esto es equivalente al segundo campo separado por dos puntos de ro.crypto.volume.options , excepto que el valor predeterminado en 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 sobre cifrado de metadatos .

Precaución : en dispositivos que se iniciaron con Android 10 o versiones anteriores, el modo de cifrado de nombres de archivos 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 se debe anular 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 inicio 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 a los directorios que no deben estar cifrados, como el directorio que contiene la clave DE del sistema y los directorios que contienen directorios CE o DE de 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 se puede controlar mediante el argumento encryption=<action> del comando mkdir en los scripts de inicio. Los posibles valores de <action> están documentados en el archivo README del lenguaje de inicio de Android .

En Android 10, las acciones de cifrado init estaban codificadas 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, entonces el fabricante del dispositivo debe incluir políticas SELinux que solo otorguen acceso a las aplicaciones que necesitan usar el directorio no cifrado. 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.

Admite 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 atributo defaultToDeviceProtectedStorage solo está disponible para aplicaciones del sistema. El atributo directBootAware está disponible para todos.

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

El atributo directBootAware a nivel de aplicación es una abreviatura para marcar todos los componentes de la aplicación como compatibles con el cifrado.

El atributo defaultToDeviceProtectedStorage redirige la ubicación de almacenamiento predeterminada de la aplicación para que apunte al almacenamiento DE en lugar de apuntar al almacenamiento CE. Las aplicaciones del sistema que utilizan este indicador deben auditar cuidadosamente todos los datos almacenados en la ubicación predeterminada y cambiar las rutas de los datos confidenciales para utilizar el almacenamiento CE. Los fabricantes de dispositivos que utilizan esta opción deben inspeccionar cuidadosamente los datos que almacenan 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()

Soportando múltiples usuarios

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

Las aplicaciones criptográficas 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 sólo podrán acceder a directorios cifrados con CE para usuarios que ya estén desbloqueados.

Es posible que una aplicación pueda interactuar libremente en las áreas DE, pero que un usuario esté desbloqueado no significa que todos los usuarios del dispositivo estén desbloqueados. La aplicación debe 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 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 DE en la partición de datos del 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 de la unidad cifrada.

Cuando se utiliza 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 contener paquetes OTA.
4. Agregue una regla SELinux y contextos de archivos para controlar el acceso a este directorio y su contenido. Solo el proceso o las aplicaciones que reciben actualizaciones OTA deberían poder leer y escribir en este directorio. Ninguna otra aplicación o proceso debería tener acceso a este directorio.

Validación

Para garantizar 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, ejecute también 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 exista ro.crypto.state
  • Asegúrese de que ro.crypto.state esté cifrado
• Compruebe que exista ro.crypto.type
  • Asegúrese de ro.crypto.type esté configurado como file

Además, los evaluadores pueden verificar que el almacenamiento CE esté bloqueado antes de que el dispositivo se desbloquee por primera vez desde el inicio. Para hacer esto, use una compilación userdebug o eng , establezca un PIN, patrón o contraseña en el usuario principal y reinicie el dispositivo. Antes de desbloquear el dispositivo, ejecute el siguiente comando para verificar el almacenamiento CE del usuario principal. Si el dispositivo utiliza el modo de usuario del sistema sin cabeza (la mayoría de los dispositivos automotrices), el usuario principal es el usuario 10, así que ejecute:

adb root; adb shell ls /data/user/10

En otros dispositivos (la mayoría de los dispositivos que no son automotrices), el usuario principal es el usuario 0, así que ejecute:

adb root; adb shell ls /data/user/0

Verifique que los nombres de archivos enumerados estén codificados en Base64, lo que indica que los nombres de archivos están cifrados y que la clave para descifrarlos aún no está disponible. Si los nombres de los archivos aparecen en texto sin formato, algo anda mal.

También se anima a los fabricantes de dispositivos a que exploren la ejecución de pruebas de Linux 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 compatibles oficialmente 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 cifrado "fscrypt" (compatible con ext4 y f2fs) en el kernel y normalmente está configurada para:

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

También se admite el cifrado Adiantum . Cuando el cifrado 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á obsoleta 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 utilizan HKDF-SHA512 para derivar la versión real. 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 kernel anterior .

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
Sin cifrar	Directorios en /data que no pueden o no necesitan ser protegidos por FBE. En los dispositivos que utilizan cifrado de metadatos , estos directorios no están realmente sin cifrar, sino que están protegidos por la clave de cifrado de metadatos que es equivalente al Sistema DE.	/data/apex , excluyendo /data/apex/decompressed y /data/apex/ota_reserved que son sistema DE /data/lost+found /data/preloads /data/unencrypted Todos los directorios cuyos subdirectorios utilizan diferentes claves FBE. Por ejemplo, dado que cada directorio /data/user/${user_id} usa una clave por usuario, /data/user no usa ninguna clave.
Sistema DE	Datos cifrados en el dispositivo no vinculados a un usuario en particular	/data/apex/decompressed /data/apex/ota_reserved /data/app /data/misc /data/system /data/vendor Todos los demás subdirectorios de /data que esta tabla no menciona como de clase diferente
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 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 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

Todas las claves FBE son administradas por vold 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
Tecla DE del sistema	/data/unencrypted	Sin cifrar
Claves CE de usuario (internas)	/data/misc/vold/user_keys/ce/${user_id}	Sistema DE
Teclas DE (internas) de usuario	/data/misc/vold/user_keys/de/${user_id}	Sistema DE
Claves CE de usuario (adoptables)	/data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid}	Usuario CE (interno)
Claves DE usuario (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 FBE se almacenan en directorios cifrados por otra clave 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. Cada clave, además de las claves CE para almacenamiento interno, se cifra con AES-256-GCM utilizando su propia clave de almacén de claves 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 confiable, como lo exige Verified Boot . También se solicita resistencia a la reversión en la clave Keystore, lo que permite que las claves FBE se eliminen de forma segura en dispositivos donde Keymaster admite resistencia a la reversión. Como alternativa de mejor esfuerzo para cuando la resistencia a la reversión no está disponible, el hash SHA-512 de 16384 bytes aleatorios almacenados en el archivo secdiscardable almacenado junto a la clave se utiliza como etiqueta de identificación de la aplicación de la clave del almacén de claves. Todos estos bytes deben recuperarse para recuperar una clave FBE.

Las claves CE para 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 contraseña seguro o ambos del lado del cliente. y claves del lado del servidor para una operación de reanudación al reiniciar . Solo se permite la creación de tokens de restablecimiento de contraseña para perfiles de trabajo y dispositivos totalmente administrados .

Para lograr esto, vold cifra 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 está protegida.

Para proteger la contraseña sintética con LSKF, LockSettingsService primero extiende el LSKF pasándolo a través de scrypt , apuntando a un tiempo de aproximadamente 25 ms y un uso de memoria de aproximadamente 2 MiB. Dado que los LSKF suelen ser cortos, este paso no suele ofrecer mucha seguridad. La capa principal de seguridad es el Elemento Seguro (SE) o limitación de velocidad aplicada por TEE que se describe a continuación.

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

Si el dispositivo no tiene un SE, LockSettingsService utiliza el LSKF extendido como contraseña de Gatekeeper . LockSettingsService luego cifra la contraseña sintética dos veces: primero con una clave de software derivada del LSKF extendido y el hash de un archivo secdescartable, y segundo con una clave de almacén de claves que está vinculada con la autenticación a la inscripción de Gatekeeper. Esto proporciona una limitación de tasa de conjeturas LSKF aplicada por TEE.

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