Google se compromete a promover la equidad racial para las comunidades negras. Ver cómo.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Cifrado basado en archivos

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

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

Arranque directo

El cifrado basado en archivos habilita una nueva característica introducida en Android 7.0 llamada Direct Boot . Direct Boot permite que los dispositivos cifrados se inicien directamente en la pantalla de bloqueo. Anteriormente, en dispositivos cifrados que usaban cifrado de disco completo (FDE), los usuarios necesitaban proporcionar credenciales antes de que se pudiera acceder a los datos, lo que evitaba 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 las operaciones básicas del marcador de emergencia.

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

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

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

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

La API de arranque directo permite que las aplicaciones con cifrado accedan a cada una de estas áreas. Hay cambios en el ciclo de vida de la aplicación para adaptarse a la necesidad de notificar a las aplicaciones cuando el almacenamiento CE de un usuario se desbloquea en respuesta a la primera entrada de credenciales en la pantalla de bloqueo, o en el caso de que el perfil de trabajo proporcione 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 del cifrado basado en archivos en los sistemas de archivos Ext4 y F2FS y solo debe habilitarse en dispositivos que cumplan con los requisitos. Los fabricantes que elijan utilizar FBE tal vez deseen explorar formas de optimizar la función en función del sistema en chip (SoC) utilizado.

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

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

Ejemplos y fuente

Android proporciona una implementación de referencia de cifrado basado en archivos, en la que vold ( system / vold ) proporciona la funcionalidad para administrar los dispositivos de almacenamiento y los volúmenes en Android. La adición de FBE proporciona a vold varios comandos nuevos para admitir la administración de claves para las claves CE y DE de múltiples usuarios. Además de los cambios principales para usar las capacidades de cifrado basadas en archivos en el kernel, muchos paquetes del sistema, incluida la pantalla de bloqueo y SystemUI, se han modificado para admitir las funciones FBE y Direct Boot. Éstos incluyen:

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

* Aplicaciones del sistema que utilizan 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 de origen 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 una versión HAL 1.0 o 2.0. No hay soporte para Keymaster 0.3 ya que no proporciona las capacidades necesarias ni asegura una protección suficiente para las claves de cifrado.
  • Keymaster / Keystore y Gatekeeper deben implementarse en un Trusted Execution Environment (TEE) para brindar protección a las claves DE, de modo que un SO no autorizado (SO personalizado flasheado en el dispositivo) no pueda simplemente solicitar las claves DE.
  • Se requiere la raíz de confianza de hardware y el arranque verificado vinculados a la inicialización del keymaster para garantizar que un sistema operativo no autorizado no pueda acceder a las credenciales de cifrado del dispositivo.

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

Implementación

En primer lugar, las aplicaciones como los relojes de alarma, el teléfono y las funciones de accesibilidad deben ser Android: directBootAware de acuerdo con la documentación para desarrolladores de Direct Boot .

Soporte de kernel

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 de 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 de datos de userdata su dispositivo es Ext4, o use CONFIG_F2FS_FS_ENCRYPTION=y si el sistema de archivos de datos de userdata su dispositivo es F2FS.

Si su dispositivo admite 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 deben habilitar la aceleración criptográfica para acelerar el cifrado basado en archivos y mejorar la experiencia del usuario. Por ejemplo, en dispositivos basados ​​en ARM64, la aceleración ARMv8 CE (Cryptography Extensions) se puede habilitar configurando las siguientes opciones de configuración del kernel:

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

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

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

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

CONFIG_SCSI_UFS_CRYPTO=y

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

CONFIG_MMC_CRYPTO=y

Habilitación del cifrado basado en archivos

Habilitar FBE en un dispositivo requiere habilitarlo en el almacenamiento interno (datos de userdata ). Esto también habilita automáticamente FBE en almacenamiento adoptable; sin embargo, el formato de cifrado en el almacenamiento adoptable se puede anular 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 de 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 .
  • 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 o adiantum . 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 R, 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 inició en Android R o superior (según lo determinado por ro.product.first_api_level ), o v1 si el dispositivo se inició en 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, deriva solo una clave de cifrado de contenido de archivo por clave CE o DE, en lugar de una por archivo. La generación de IV (vectores de inicialización) se ajusta en consecuencia.
    • El 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. Esta marca solo debe usarse en hardware de cifrado en línea que cumpla con la especificación JEDEC eMMC v5.2 y, por lo tanto, solo admita IV de 32 bits. En otro hardware de cifrado en línea, utilice inlinecrypt_optimized en inlinecrypt_optimized lugar. Esta bandera nunca debe usarse en almacenamiento basado en UFS; la especificación UFS permite el uso de IV de 64 bits.
    • El indicador wrappedkey_v0 habilita el uso de claves envueltas en hardware. Cuando está habilitado, las claves FBE no son generadas por software, sino que son generadas por Keymaster usando la etiqueta STORAGE_KEY . Luego, cada clave FBE realmente proporcionada al kernel es la clave STORAGE_KEY exportada desde Keymaster, lo que hace que se envuelva con una clave efímera por arranque. Luego, el kernel proporciona las claves envueltas directamente al hardware de cifrado en línea. Cuando se implementa correctamente, las claves no envueltas nunca están presentes en la memoria del sistema y una clave envuelta comprometida no se puede utilizar después de un reinicio. Este indicador requiere soporte de hardware, soporte de Keymaster para STORAGE_KEY , soporte de controlador de kernel, la opción de montaje inlinecrypt y los inlinecrypt_optimized o emmc_optimized .

Si no está utilizando hardware de cifrado en línea, la configuración recomendada para la mayoría de los dispositivos es fileencryption=aes-256-xts . Si está utilizando 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 . En dispositivos sin ningún tipo de aceleración AES, Adiantum puede usarse en lugar de AES configurando fileencryption=adiantum .

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

De forma predeterminada, el cifrado del contenido de los archivos se realiza mediante la API de criptografía del kernel de Linux. Si desea utilizar el cifrado de hardware en línea en lugar, también añadir el inlinecrypt opción de montaje. Por ejemplo, una 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

Almacenamiento adoptable

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

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

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

  • ro.crypto.volume.options (nuevo en Android R) 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 de fileencryption de 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 versiones anteriores, 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 lanzaron con Android 10 o aes-256-heh 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 .

Integrarse con Keymaster

La generación de claves y la gestión del vold de claves del kernel está a cargo de vold . La implementación AOSP de FBE requiere que el dispositivo admita Keymaster HAL versión 1.0 o posterior. No hay soporte para versiones anteriores de Keymaster HAL.

En el primer arranque, las claves del usuario 0 se generan e instalan al principio del proceso de arranque. Para cuando finalice la fase on-post-fs de init , el Keymaster debe estar listo para manejar las solicitudes. En los dispositivos Pixel, esto se maneja con un bloque de script que asegura que Keymaster se inicie antes de que se monten los /data .

Política de cifrado

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

En Android R y versiones posteriores, la política de cifrado ya no está codificada en una ubicación centralizada, sino que se define mediante argumentos a los comandos mkdir en los scripts de inicio. Los directorios cifrados con la clave DE del sistema usan encryption=Require , mientras que los directorios no cifrados (o directorios cuyos subdirectorios están cifrados con claves por usuario) utilizan encryption=None .

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

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

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

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

Es posible agregar excepciones para evitar que ciertos directorios se cifren en absoluto. Si 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 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.

Soporte de arranque directo en aplicaciones del sistema

Hacer que las aplicaciones sean compatibles con el arranque directo

Para facilitar la migración rápida de las aplicaciones del sistema, hay dos nuevos atributos que se pueden configurar en el nivel de la aplicación. El atributo defaultToDeviceProtectedStorage está disponible solo para 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 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 apuntar al almacenamiento DE en lugar de apuntar al almacenamiento CE. Las aplicaciones del sistema que usan esta marca deben auditar cuidadosamente todos los datos almacenados en la ubicación predeterminada y cambiar las rutas de los datos confidenciales para usar el almacenamiento CE. Los fabricantes de dispositivos que utilizan esta opción deben inspeccionar cuidadosamente los datos que están almacenando para asegurarse de que no contengan información personal.

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

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

Apoyar a múltiples usuarios

Cada usuario en un entorno multiusuario obtiene una clave de cifrado independiente. Cada usuario obtiene dos claves: una DE y una CE. El usuario 0 debe iniciar sesión primero en el dispositivo, ya que es un usuario especial. Esto es pertinente para los usos de la 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 encriptados con CE para usuarios que ya estén desbloqueados.

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

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

Manejo de actualizaciones

La partición de recuperación no puede acceder al almacenamiento protegido por DE en la partición de datos de usuario. 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 de datos de userdata :

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

Validación

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

Si el dispositivo ejecuta Android R 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 que ro.crypto.type esté configurado en file

Además, los evaluadores pueden iniciar una instancia de 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 archivo cifrados; si no es así, algo anda mal.

También se anima a los fabricantes de dispositivos a explorar la ejecución de las pruebas de Linux ascendentes para fscrypt en sus dispositivos o kernels. Estas pruebas son parte del conjunto de pruebas del sistema de archivos xfstests. Sin embargo, Android no admite oficialmente estas pruebas ascendentes.

Detalles de implementación de AOSP

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

cifrado fscrypt

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

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

También se admite el cifrado Adiantum . Cuando el cifrado de Adiantum está habilitado, tanto el contenido como los nombres de archivo se cifran con Adiantum.

Para obtener más información sobre fscrypt, consulte la documentación del kernel ascendente .

Derivación de claves

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

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

El token de autenticación es un token autenticado criptográficamente generado por Gatekeeper cuando un usuario inicia sesión correctamente. El TEE se negará a utilizar la clave a menos que se proporcione el token de autenticación correcto. Si el usuario no tiene credenciales, no se usa ni se necesita ningún token de autenticación.

La credencial estirada es la credencial del usuario después de salar y estirar con el algoritmo scrypt . La credencial es realmente hash una vez en el servicio de configuración de bloqueo antes de pasar a vold para pasar a scrypt . Esto está vinculado criptográficamente a la clave en el TEE con todas las garantías que se aplican a KM_TAG_APPLICATION_ID . Si el usuario no tiene credenciales, no se usa ni se necesita ninguna credencial extendida.

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

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