Encriptación basada en archivos

Android 7.0 y versiones posteriores son compatibles con la encriptación basada en archivos (FBE). La encriptación basada en archivos permite encriptar diferentes archivos con claves diferentes que pueden desbloquearse de forma independiente.

En este artículo, se describe cómo habilitar la encriptación basada en archivos en dispositivos nuevos y cómo las aplicaciones de sistema pueden usar las APIs de inicio directo para ofrecer a los usuarios la mejor experiencia y la más segura posible.

Todos los dispositivos que se lanzan con Android 10 y versiones posteriores tienen necesarias para usar la encriptación basada en archivos.

Inicio directo

La encriptación basada en archivos habilita una función nueva en Android 7.0 llamada Direct Arranque. El inicio directo permite que los dispositivos encriptados se inicien directamente desde el bloqueo en la pantalla. Anteriormente, en dispositivos encriptados con disco completo encriptación segura (FDE), los usuarios debían proporcionar credenciales antes de que los datos lo que evita que el teléfono realice todas las tareas las operaciones. Por ejemplo, las alarmas no se pudieron funcionar, los servicios de accesibilidad disponible, y los teléfonos no podían recibir llamadas, pero estaban limitados solo a los servicios básicos las operaciones del marcador de emergencia.

Con la introducción de la encriptación basada en archivos (FBE) y las nuevas APIs a las aplicaciones conscientes de la encriptación, estas pueden funcionar en un contexto limitado. Esto puede ocurrir antes de que los usuarios proporcionen su las credenciales y, al mismo tiempo, proteger la información privada del usuario.

En los dispositivos compatibles con FBE, cada usuario del dispositivo tiene dos ubicaciones de almacenamiento disponibles para las aplicaciones:

  • Almacenamiento encriptado por credenciales (CE), que es la ubicación de almacenamiento predeterminada y solo está disponible después de que el usuario desbloquea el dispositivo.
  • Almacenamiento encriptado por dispositivo (DE), que es una ubicación de almacenamiento disponible durante el modo de inicio directo y después de que el usuario desbloquee el dispositivo.

Esta separación hace que los perfiles de trabajo sean más seguros, ya que permite que haya más de un usuario estén protegidos en un momento dado, ya que la encriptación ya no se basa únicamente en un y la contraseña de inicio de sesión.

La API de inicio directo permite que las aplicaciones con reconocimiento de encriptación accedan a cada uno de estos en esas áreas. Hay cambios en el ciclo de vida de la aplicación para adaptarse a la necesidad notificar a las aplicaciones cuando el almacenamiento CE de un usuario se desbloquea en respuesta a ingresando las credenciales en la pantalla de bloqueo o, en el caso de un perfil de trabajo, con un trabajo desafío. Los dispositivos con Android 7.0 deben ser compatibles con estas nuevas API y sin importar si implementan o no el FBE. Sin embargo, sin El almacenamiento de FBE, DE y CE siempre estará desbloqueado.

Una implementación completa de la encriptación basada en archivos en los archivos Ext4 y F2FS se proporcionan en el Proyecto de código abierto de Android (AOSP) y solo se deben habilitar en dispositivos que cumplen los requisitos. Fabricantes que eligen usar FBE es posible que desees explorar formas de optimizar la función según el sistema en chip (SoC) utilizado.

Se actualizaron todos los paquetes necesarios en AOSP para que reconozcan el inicio directo. Sin embargo, cuando los fabricantes de dispositivos usan versiones personalizadas de estas apps, querrá garantizar, como mínimo, que haya paquetes con reconocimiento de inicio 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 encriptación basada en archivos, en la que vold (system/vold) proporciona la funcionalidad para administrar dispositivos de almacenamiento y volúmenes en Android. La adición del FBE proporciona vold con varios comandos nuevos para admitir la administración de claves CE y DE de varios usuarios. Además, en los principales cambios para usar la biblioteca de encriptación en el kernel, muchos paquetes del sistema, incluido el de la pantalla de bloqueo y SystemUI se modificaron para admitir el FBE y Funciones de inicio Por ejemplo:

  • Teléfono del AOSP (paquetes/apps/Teléfono)
  • Reloj de escritorio (paquetes/apps/Reloj de escritorio)
  • LatinIME (paquetes/métodos de entrada/latino)*
  • App de Configuración (paquetes/apps/configuración)*
  • SystemUI (frameworks/base/paquetes/SystemUI)*

* Las aplicaciones del sistema que usan defaultToDeviceProtectedStorage atributo del manifiesto

Puedes encontrar más ejemplos de aplicaciones y servicios con reconocimiento de encriptación que puedes encontrar ejecutando el comando mangrep directBootAware en de código abierto o de paquetes del AOSP árbol de fuentes.

Dependencias

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

  • Compatibilidad con kernel para la encriptación Ext4 o F2FS.
  • Keymaster Compatibilidad con la versión 1.0 o posterior de HAL. No se admite Keymaster 0.3 no proporciona las capacidades necesarias ni garantiza una protección suficiente para las claves de encriptación.
  • Keymaster/Keystore y El recepcionista debe implementarse en una ejecución confiable. de entorno (TEE) para proteger las claves DE de modo que se pueda no autorizado (SO personalizado en la memoria flash del dispositivo) no puede simplemente solicitar el DE.
  • Raíz de confianza del hardware e inicio verificado vinculado a la inicialización de Keymaster se requiere para garantizar que las claves DE no que un sistema operativo no autorizado pueda acceder.

Implementación

Primero y principal, apps como despertadores, teléfonos y funciones de accesibilidad debe convertirse en android:directBootAware de acuerdo con la Especificación Inicia la documentación para desarrolladores.

Compatibilidad con kernel

La compatibilidad de kernel para la encriptación Ext4 y F2FS está disponible en la versión común de Android kernels, versión 3.18 y posteriores. Habilitarlo en un kernel con la versión 5.1 o una superior, usa: 

CONFIG_FS_ENCRYPTION=y

Para kernels más antiguos, usa CONFIG_EXT4_ENCRYPTION=y si el El sistema de archivos userdata es Ext4, o usa CONFIG_F2FS_FS_ENCRYPTION=y si userdata de tu dispositivo del sistema de archivos es F2FS.

Si tu dispositivo es compatible con adoptable Storage o usará metadatos encriptación en el almacenamiento interno; también se habilitan las opciones de configuración del kernel necesarios para la encriptación de metadatos, como se describe en la documentación de encriptación de metadatos.

Además de la compatibilidad funcional con la encriptación Ext4 o F2FS, el dispositivo los fabricantes también deberían habilitar la aceleración criptográfica la encriptación basada en archivos y mejorar la experiencia del usuario. Por ejemplo, en En los dispositivos basados en ARM64, la aceleración de ARMv8 CE (extensiones de criptografía) se puede habilitando 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 considera también implementar hardware de encriptación intercalada, que encripta/desencripta los datos mientras se dirigen al dispositivo de almacenamiento o sale de él. Los kernels comunes de Android (versión 4.14 y posteriores) contienen un framework que permite usar la encriptación integrada cuando la compatibilidad con el hardware y los controladores del proveedor disponibles. El framework de encriptación intercalada se puede habilitar estableciendo las siguientes opciones de configuración del kernel: 

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

Si tu dispositivo usa almacenamiento basado en UFS, también habilita lo siguiente: 

CONFIG_SCSI_UFS_CRYPTO=y

Si tu dispositivo usa almacenamiento basado en eMMC, también habilita lo siguiente: 

CONFIG_MMC_CRYPTO=y

Habilita la encriptación basada en archivos

Para habilitar el FBE en un dispositivo, es necesario habilitarlo en el almacenamiento interno (userdata). Esto también habilita automáticamente el FBE el almacenamiento Sin embargo, se puede anular el formato de encriptación del almacenamiento para dispositivos adoptables si es necesario.

Almacenamiento interno

El 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 encriptación y almacenamiento de los datos. Contiene hasta tres parámetros separados por dos puntos:

  • El parámetro contents_encryption_mode define qué se usa para encriptar el contenido de los archivos. Puede ser una de las siguientes opciones: aes-256-xts o adiantum. Desde que se lanzó Android 11 También puede dejarse vacío para especificar la el algoritmo predeterminado, que es aes-256-xts.
  • El parámetro filenames_encryption_mode define qué se usa para encriptar nombres de archivos. Puede ser una de las siguientes opciones: 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 a adiantum si contents_encryption_mode es adiantum.
  • El parámetro flags, nuevo en Android 11, es una lista de marcas separadas por el prefijo + carácter. Se admiten las siguientes marcas:
    • La marca v1 selecciona las políticas de encriptación de la versión 1. el La marca v2 selecciona las políticas de encriptación de la versión 2. Versión 2 políticas de encriptación usan una función de derivación de claves más segura y flexible. El valor predeterminado es v2 si Que el dispositivo se haya iniciado con Android 11 o una versión posterior (según lo determine ro.product.first_api_level) o v1 si que el dispositivo se inicie con Android 10 menor.
    • La marca inlinecrypt_optimized selecciona una encriptación optimizado para hardware de encriptación integrada que no administrar grandes cantidades de claves de manera eficiente. Para ello, obtiene solo una clave de encriptación de contenido de archivo por clave CE o DE, en lugar de una por archivo. La generación de IV (vectores de inicialización) es y ajustarlo según corresponda.
    • La marca emmc_optimized es similar a inlinecrypt_optimized, pero también selecciona un IV de generación de tráfico que limita los IV a 32 bits. Esta marca solo debe usarse en un hardware de encriptación en línea que cumpla con las la especificación JEDEC eMMC v5.2; por lo tanto, solo es compatible con IV. En otro hardware de encriptación intercalada, usa inlinecrypt_optimized en su lugar. Esta marca nunca debe usarse en almacenamientos basados en UFS; la especificación UFS permite que se use de IV de 64 bits.
    • En dispositivos que admiten unión de hardware de servicio, la marca wrappedkey_v0 permite usar unidas por hardware para FBE. Solo pueden usarse de forma conjunta con la opción de activación inlinecrypt y el inlinecrypt_optimized o emmc_optimized marca.
    • La marca dusize_4k fuerza el tamaño de la unidad de datos de encriptación sea de 4,096 bytes, incluso cuando el tamaño del bloque del sistema de archivos no sea de 4,096 bytes. El tamaño de la unidad de datos de encriptación es el nivel de detalle del archivo la encriptación de contenido. Este indicador está disponible desde la 15 (experimental de AOSP). Esta marca solo debe usarse para habilitar el uso de hardware de encriptación intercalada que no admite datos unidades superiores a 4, 096 bytes en un dispositivo que utiliza un tamaño de página mayor que 4,096 bytes y usa el sistema de archivos f2fs.

Si no usas hardware de encriptación intercalada, la configuración recomendada para la mayoría de dispositivos es fileencryption=aes-256-xts. Si usas intercalado hardware de encriptación. La configuración recomendada para la mayoría de los dispositivos es fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (o el equivalente a fileencryption=::inlinecrypt_optimized). Activada sin ninguna forma de aceleración AES, se puede usar Adiantum en lugar de AES configurando fileencryption=adiantum.

A partir de Android 14, AES-HCTR2 es el modo preferido de encriptación de nombres de archivo. para dispositivos con instrucciones de criptografía acelerada. Sin embargo, solo los kernels de Android más recientes son compatibles AES-HCTR2 En una próxima versión de Android, se planea que se convierta en el modo predeterminado para los nombres de archivo. encriptación. Si tu kernel es compatible con AES-HCTR2, puede habilitarse para la encriptación de nombres de archivo por estableciendo filenames_encryption_mode en aes-256-hctr2. En el caso más sencillo esto se haría con fileencryption=aes-256-xts:aes-256-hctr2.

En los dispositivos que se lanzaron con Android 10 o versiones anteriores, haz lo siguiente: También se acepta fileencryption=ice para especificar el uso del elemento Modo de encriptación de contenido de archivos FSCRYPT_MODE_PRIVATE. Este modo es no implementado por los kernels comunes de Android, pero podría implementarse con parches de kernel personalizados. El formato en disco que produce este modo. era específica del proveedor. En dispositivos que se lanzan con Android 11 o versiones posteriores, ya no se permite este modo, y una el formato de encriptación estándar.

De forma predeterminada, la encriptación del contenido del archivo se realiza mediante la biblioteca API de criptografía. Si quieres usar hardware de encriptación intercalada, también Agrega la opción de activación inlinecrypt. Por ejemplo, una lista completa La línea fstab podría verse de la siguiente manera: 

/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

A partir de Android 9, FBE y almacenamiento adoptable pueden usarse en conjunto.

Especificando la opción fstab fileencryption para userdata también habilita automáticamente el FBE y la encriptación de metadatos en dispositivos y almacenamiento de los datos. Sin embargo, puedes anular los formatos de encriptación de metadatos o FBE en el almacenamiento adoptable estableciendo propiedades PRODUCT_PROPERTY_OVERRIDES

En los dispositivos que se lanzaron con Android 11 o versiones posteriores, usa las siguientes propiedades:

  • ro.crypto.volume.options (nuevo en Android) 11) selecciona el formato de encriptación FBE en y el almacenamiento adoptable. Tiene la misma sintaxis que el argumento para la la opción fstab fileencryption y usa los mismos valores predeterminados. Consulta las recomendaciones anteriores sobre fileencryption para saber qué debes hacer usar aquí.
  • ro.crypto.volume.metadata.encryption selecciona los metadatos. de encriptación en el almacenamiento adoptable. Consulta los metadatos documentación de encriptación.

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

  • ro.crypto.volume.contents_mode selecciona el contenido. el modo de encriptación. Esto equivale al primer campo separado por dos puntos de ro.crypto.volume.options
  • ro.crypto.volume.filenames_mode selecciona los nombres de archivo. el modo de encriptación. Esto equivale al segundo campo separado por dos puntos de ro.crypto.volume.options, excepto que la configuración predeterminada en los dispositivos que se lanzó con Android 10 o versiones anteriores aes-256-heh En la mayoría de los dispositivos, esto debe ser explícitamente se anula por aes-256-cts.
  • ro.crypto.fde_algorithm y ro.crypto.fde_sector_size selecciona la encriptación de metadatos en almacenamiento adoptable. Consulta los metadatos documentación de encriptación.

Integración con Keymaster

La HAL de Keymaster debe iniciarse como parte de la clase early_hal. Esto se debe a que el FBE requiere que Keymaster esté listo para controlar las solicitudes del Fase de inicio post-fs-data, que ocurre cuando se configura vold las claves iniciales.

Exclusión de directorios

init aplica la clave DE del sistema para lo siguiente: todos los directorios de nivel superior de /data, excepto los directorios que no deben estar encriptados, como el directorio que contiene la clave DE del sistema y a los directorios que contienen los directorios CE o DE de usuarios. Claves de encriptación se aplican de forma recursiva y los subdirectorios no pueden anularlos.

En Android 11 y versiones posteriores, la clave que init se aplica a los directorios que puede controlarse mediante Argumento de encryption=<action> a mkdir en las secuencias de comandos init. Los valores posibles de <action> son los siguientes: según se documenta en el README para el lenguaje init de Android

En Android 10, las acciones de encriptación de 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 la siguiente: 

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

Es posible agregar excepciones para evitar que ciertos directorios o encriptado en absoluto. Si se realizan modificaciones de este tipo, el dispositivo el fabricante debe incluir políticas de SELinux que solo otorguen acceso al aplicaciones que necesitan usar el directorio sin encriptar. Se deberían excluir todos aplicaciones que no son de confianza.

El único caso de uso aceptable conocido para esto es compatibilidad con OTA heredada capacidades de integración.

Compatibilidad con el inicio directo en aplicaciones del sistema

Cómo hacer que las aplicaciones reconozcan el inicio directo

Para facilitar la migración rápida de las apps del sistema, hay dos atributos nuevos que se puede configurar a nivel de la aplicación. El El atributo defaultToDeviceProtectedStorage solo está disponible para apps del sistema. El atributo directBootAware está disponible para todos los usuarios. 

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

El atributo directBootAware a nivel de la aplicación es una abreviatura para marcar que todos los componentes de la app reconocen la encriptación.

El atributo defaultToDeviceProtectedStorage redirecciona el valor predeterminado la ubicación de almacenamiento de la app para que apunte al almacenamiento de DE, en lugar de apuntar al de CE. Las aplicaciones del sistema que usan esta marca deben auditar cuidadosamente todos los datos almacenados en la y cambiar las rutas de los datos sensibles para usar el almacenamiento CE. Dispositivo y los fabricantes que usan esta opción deben inspeccionar cuidadosamente los datos para garantizar que no contengan información personal.

Cuando se ejecutan en este modo, las siguientes APIs del sistema se está disponible para administrar de forma explícita un contexto respaldado por el almacenamiento de CE cuando sea necesario, lo que son equivalentes a sus contrapartes protegidas por dispositivo.

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

Compatibilidad con múltiples usuarios

Cada usuario en un entorno multiusuario obtiene una clave de encriptación distinta. Todos los usuarios recibe dos claves: una DE y una CE. El usuario 0 primero debe acceder al dispositivo tal como está un usuario especial. Esto es pertinente para Device Administración.

Las aplicaciones con reconocimiento de criptomonedas interactúan entre los usuarios de la siguiente manera: INTERACT_ACROSS_USERS y INTERACT_ACROSS_USERS_FULL permiten que una aplicación actúe en todos los usuarios del dispositivo. Sin embargo, esos aplicaciones solo podrán acceder a directorios con encriptación CE para los usuarios que ya está desbloqueado.

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. El aplicación debería verificar este estado antes de intentar acceder a esas áreas.

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

Cómo controlar las actualizaciones

La partición de recuperación no puede acceder al almacenamiento protegido por DE en el userdata. Se recomienda que los dispositivos que implementan el FBE sean compatibles OTA mediante actualizaciones del sistema A/B Como se puede aplicar la OTA durante el funcionamiento normal. No es necesario recuperar acceder a los datos de la unidad encriptada.

Cuando se usa una solución inalámbrica heredada, que requiere recuperación para acceder al archivo inalámbrico En la partición userdata, haz lo siguiente:

  1. Crea un directorio de nivel superior (por ejemplo, misc_ne) en la userdata.
  2. Configura este directorio de nivel superior para que no esté encriptado (consulta Cómo excluir directorios).
  3. Crea un directorio dentro del directorio de nivel superior para guardar paquetes inalámbricos.
  4. Agrega una regla de SELinux y contextos de archivos para controlar el acceso a este directorio y el contenido. Solo el proceso o las aplicaciones que reciben actualizaciones OTA deben puedan leer y escribir en este directorio. No hay otra aplicación o proceso debería tener acceso a este directorio.

Validación

Para asegurarte de que la versión implementada de la función se ejecute según lo previsto, primero ejecuta muchas pruebas de encriptación del CTS, como DirectBootHostTest (Prueba de inicio directo) y EncryptionTest.

Si el dispositivo ejecuta Android 11 o una versión posterior, también vts_kernel_encryption_test: 

atest vts_kernel_encryption_test

O bien:

vts-tradefed run vts -m vts_kernel_encryption_test

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

  • Comprueba que ro.crypto.state exista
    • Asegúrate de que ro.crypto.state esté encriptado
  • Comprueba que ro.crypto.type exista
    • Asegúrate de que ro.crypto.type esté configurado como file.

Además, los verificadores pueden verificar que el almacenamiento CE esté bloqueado antes de que el se haya desbloqueado por primera vez desde el inicio. Para hacerlo, usa un Crea userdebug o eng, establece un PIN, un patrón o usuario principal y reinicia el dispositivo. Antes de desbloquear el dispositivo, Ejecuta el siguiente comando para verificar el almacenamiento de CE del usuario principal. Si el botón El dispositivo utiliza el sistema sin interfaz gráfica Modo de usuario (la mayoría de los dispositivos Automotive), el usuario principal es el usuario 10, por lo que debes ejecutar lo siguiente: 

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

En otros dispositivos (la mayoría de los dispositivos no automotores), el usuario principal es el usuario 0, por lo que ejecuta lo siguiente:

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

Verifica que los nombres de archivo indicados estén codificados en Base64, lo que indica que el los nombres de archivo están encriptados y la clave para desencriptarlos aún no está disponible. Si los nombres de archivo se muestran en texto simple, significa que hay un problema.

También se recomienda que los fabricantes de dispositivos exploren la ejecución de pruebas de Linux ascendentes para fscrypt en sus dispositivos o kernels. Estas pruebas forman parte del conjunto de pruebas del sistema de archivos xfstests. Sin embargo, Estas pruebas ascendentes no son compatibles oficialmente con Android.

Detalles de la implementación del AOSP

En esta sección, se proporcionan detalles sobre la implementación del AOSP y se describe cómo cómo funciona la encriptación basada en archivos. No debería ser necesaria para los fabricantes de dispositivos para usar el FBE y el inicio directo en sus dispositivos.

encriptación de fscrypt

La implementación de AOSP usa "fscrypt" encriptación (compatible con ext4 y f2fs) en el kernel y, normalmente, se configura para lo siguiente:

  • Encriptar el contenido de archivos con AES-256 en modo XTS
  • Encriptar nombres de archivos con AES-256 en modo CBC-CTS

La encriptación Adiantum también es no es compatible. Cuando se habilita la encriptación Adiantum, tanto el contenido como los nombres de los archivos están encriptados con Adiantum.

fscrypt admite dos versiones de políticas de encriptación: versión 1 y versión 2. La versión 1 es obsoleta. Los requisitos del CDD para dispositivos que se lanzan con Android 11 y las versiones posteriores solo son compatibles con la versión 2) Las políticas de encriptación de la versión 2 usan HKDF-SHA512 para derivar las claves de encriptación reales de las claves suministradas por el espacio de usuario.

Para obtener más información acerca de fscrypt, consulta la documentación del kernel ascendente.

Clases de almacenamiento

En la siguiente tabla, se enumeran las claves de FBE y los directorios que protegen en más detalle:

Clase de almacenamiento Descripción Directorios
Sin encriptación Directorios de /data que no pueden o no deberían serlo cuentan con la protección de FBE. En dispositivos que usan metadatos encriptación, estos directorios no están encriptados, sino que están protegidos por la clave de encriptación de metadatos, que es equivalente a System DE:
  • /data/apex, sin incluir /data/apex/decompressed y /data/apex/ota_reserved, que son DE del sistema
  • /data/lost+found
  • /data/preloads
  • /data/unencrypted
  • Todos los directorios cuyos subdirectorios usan claves FBE diferentes. Para ejemplo, ya que cada directorio /data/user/${user_id} usa una clave por usuario, /data/user no usa una clave a sí mismo.
Sistema DE Datos encriptados por 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 aparecen en esta tabla no menciona que tienes una clase diferente
Por inicio Archivos efímeros del sistema que no necesitan sobrevivir a un reinicio /data/per_boot
CE del usuario (interno) Datos encriptados por 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}
DE del usuario (interno) Datos del dispositivo encriptados 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}
CE del usuario (adoptable) Datos encriptados por 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 encriptados por el 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 FBE y se almacenan encriptadas en el disco. excepto la clave por inicio, que no se almacena en absoluto. La siguiente tabla enumera las ubicaciones en las que se almacenan las diversas claves de FBE:

Tipo de clave Ubicación de la clave Clase de almacenamiento de la ubicación de la clave
Tecla DE del sistema /data/unencrypted Sin encriptación
Claves CE (internas) del usuario /data/misc/vold/user_keys/ce/${user_id} Sistema DE
Claves DE (internas) del usuario /data/misc/vold/user_keys/de/${user_id} Sistema DE
Claves de CE del usuario (adoptable) /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} CE del usuario (interno)
Claves DE del usuario (adoptable) /data/misc_de/${user_id}/vold/volume_keys/${volume_uuid} DE del usuario (interno)

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

vold también aplica una capa de encriptación a todas las claves FBE. Todas las claves además de las claves CE para el almacenamiento interno, se encriptan con AES-256-GCM con su propio Keystore que no es fuera del TEE. Esto garantiza que las claves FBE no se puedan desbloquear a menos que un se inició un sistema operativo de confianza, como lo aplica el inicio verificado. Reversión en la clave del almacén de claves, lo que permite que las claves de FBE borrar de forma segura en los dispositivos en los que Keymaster admita la resistencia a la reversión. Como como un resguardo de mejor esfuerzo cuando la resistencia a la reversión no esté disponible, el estándar SHA-512 hash de 16,384 bytes aleatorios almacenados en el archivo secdiscardable almacenado junto a la clave se utiliza como el ID de aplicación de la clave del almacén de claves. Se deben recuperar todos estos bytes para recuperar un Tecla FBE.

Las claves CE para el almacenamiento interno reciben un nivel de protección más sólido que garantiza no se pueden desbloquear sin conocer la pantalla de bloqueo del usuario Factor de conocimiento (LSKF) (PIN, patrón o contraseña), un tipo el token de restablecimiento de la contraseña o las claves del cliente y del servidor de un Operación de reanudación en el reinicio. Solo se pueden crear tokens de restablecimiento de contraseña para perfiles de trabajo y por completo dispositivos administrados.

Para lograrlo, vold encripta cada clave CE para el almacenamiento interno. con una clave AES-256-GCM derivada de la contraseña sintética del usuario. La contraseña sintética es un secreto criptográfico de alta entropía inmutable que se generados de forma aleatoria para cada usuario. LockSettingsService in system_server administra la contraseña sintética y las formas en que de su protección.

Para proteger la contraseña sintética con el LSKF, LockSettingsService primero estira el LSKF pasándolo por scrypt, con orientación para un tiempo de alrededor de 25 ms y una uso de memoria de aproximadamente 2 MiB. Dado que los LSKF suelen ser cortos, este paso suele no proporciona mucha seguridad. La capa principal de seguridad es el protocolo Secure Elemento (SE) o límite de frecuencia aplicado por el TEE que se describe a continuación.

Si el dispositivo tiene un Elemento seguro (SE), LockSettingsService. asigna el LSKF estirado a un secreto aleatorio de alta entropía almacenado en el SE mediante la HAL de Weaver. Luego, LockSettingsService encripta dos veces la contraseña sintética: primero con una clave de software derivada del LSKF estirado y el secreto de Weaver, y el segundo con un almacén de claves no vinculado a la autenticación . Esto proporciona un límite de frecuencia aplicado por el SE de las suposiciones de LSKF.

Si el dispositivo no tiene un SE, LockSettingsService en su lugar usa el LSKF estirado como recepcionista contraseña. LockSettingsService luego encripta la contraseña sintética dos veces: primero con una clave de software derivada del LSKF estirado y el hash de un archivo secdiscardable y, luego, una clave de almacén de claves que está vinculada a la autenticación Inscripción del recepcionista. Esto proporciona un límite de frecuencia aplicado por el TEE de las suposiciones de LSKF.

Cuando se cambia el LSKF, LockSettingsService borra todo asociada con la vinculación de la contraseña sintética con la contraseña antigua el LSKF. En los dispositivos que admiten claves de Weaver o de almacén de claves resistentes a la reversión, esta garantiza la eliminación segura de la vinculación anterior. Por este motivo, las protecciones que se describen aquí se aplican incluso cuando el usuario no tiene un LSKF.