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
oadiantum
. Desde que se lanzó Android 11 También puede dejarse vacío para especificar la el algoritmo predeterminado, que esaes-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
oaes-256-hctr2
. Si no se especifica, el valor predeterminado esaes-256-cts
sicontents_encryption_mode
esaes-256-xts
o aadiantum
sicontents_encryption_mode
esadiantum
. - 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 marcav2
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 determinero.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 ainlinecrypt_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, usainlinecrypt_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óninlinecrypt
y elinlinecrypt_optimized
oemmc_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.
- La marca
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 fstabfileencryption
y usa los mismos valores predeterminados. Consulta las recomendaciones anteriores sobrefileencryption
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 dero.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 dero.crypto.volume.options
, excepto que la configuración predeterminada en los dispositivos que se lanzó con Android 10 o versiones anterioresaes-256-heh
En la mayoría de los dispositivos, esto debe ser explícitamente se anula poraes-256-cts
.ro.crypto.fde_algorithm
yro.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:
- Crea un directorio de nivel superior (por ejemplo,
misc_ne
) en lauserdata
. - Configura este directorio de nivel superior para que no esté encriptado (consulta Cómo excluir directorios).
- Crea un directorio dentro del directorio de nivel superior para guardar paquetes inalámbricos.
- 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
- Asegúrate de que
- Comprueba que
ro.crypto.type
exista- Asegúrate de que
ro.crypto.type
esté configurado comofile
.
- Asegúrate de que
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: |
|
Sistema DE | Datos encriptados por el dispositivo no vinculados a un usuario en particular |
|
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 |
|
DE del usuario (interno) | Datos del dispositivo encriptados por usuario en el almacenamiento interno |
|
CE del usuario (adoptable) | Datos encriptados por credenciales por usuario en almacenamiento adoptable |
|
Usuario DE (adoptable) | Datos encriptados por el dispositivo por usuario en almacenamiento adoptable |
|
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.