Android 7.0 y superior admite el cifrado basado en archivos (FBE). FBE permite cifrar diferentes archivos con diferentes claves que se pueden desbloquear de forma independiente. Estas claves se utilizan para cifrar tanto el contenido como los nombres de los archivos. Cuando se usa FBE, otra información, como diseños de directorio, tamaños de archivo, permisos y tiempos de creación / modificación, no está encriptada. En conjunto, esta otra información se conoce como metadatos del sistema de archivos.
Android 9 introdujo la compatibilidad con el cifrado de metadatos. Con el cifrado de metadatos, una sola clave presente en el momento del arranque cifra cualquier contenido que no esté cifrado por FBE. Esta clave está protegida por Keymaster, que a su vez está protegido por arranque verificado.
El cifrado de metadatos siempre está habilitado en el almacenamiento adoptable cuando FBE está habilitado. El cifrado de metadatos también se puede habilitar en el almacenamiento interno.
Implementación sobre almacenamiento interno
Puede configurar el cifrado de metadatos en el almacenamiento interno de nuevos dispositivos configurando el sistema de archivos de metadata , cambiando la secuencia de inicio y habilitando el cifrado de metadatos en el archivo fstab del dispositivo.
Prerrequisitos
El cifrado de metadatos solo se puede configurar cuando se formatea por primera vez la partición de datos. Como resultado, esta función es solo para dispositivos nuevos; esto no es algo que deba cambiar una OTA.
El cifrado de metadatos requiere que el módulo dm-default-key esté habilitado en su kernel. En Android 11 y superior, dm-default-key es compatible con los kernels comunes de Android, versión 4.14 y superior. Esta versión de dm-default-key utiliza un marco de cifrado independiente del proveedor y del hardware denominado blk-crypto .
Para habilitar dm-default-key , use:
CONFIG_BLK_INLINE_ENCRYPTION=y CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y CONFIG_DM_DEFAULT_KEY=y
dm-default-key utiliza hardware de encriptación en línea (hardware que encripta / desencripta datos mientras están en camino hacia / desde el dispositivo de almacenamiento) cuando está disponible. Si no va a utilizar el hardware de encriptación en línea, sino que también es necesaria para permitir un retroceso a la API de criptografía del núcleo:
CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y
Cuando no utilice hardware de cifrado en línea, también debe habilitar cualquier aceleración basada en CPU disponible como se recomienda en la documentación de FBE .
En Android 10 y versiones anteriores, dm-default-key no era compatible con el kernel común de Android. Por lo tanto, dependía de los proveedores implementar dm-default-key .
Configurar el sistema de archivos de metadatos
Debido a que no se puede leer nada en la partición de datos de usuario hasta que esté presente la clave de cifrado de metadatos, la tabla de particiones debe reservar una partición separada llamada "partición de metadatos" para almacenar los blobs de keymaster que protegen esta clave. La partición de metadatos debe ser de 16 MB.
fstab.hardware debe incluir una entrada para el sistema de archivos de metadatos que reside en esa partición y montarlo en /metadata , incluida la formattable para garantizar que esté formateado en el momento del arranque. El sistema de archivos f2fs no funciona en particiones más pequeñas; recomendamos usar ext4 en su lugar. Por ejemplo:
/dev/block/bootdevice/by-name/metadata /metadata ext4 noatime,nosuid,nodev,discard wait,check,formattable
Para asegurarse de que exista el punto de montaje /metadata , agregue la siguiente línea a BoardConfig-common.mk :
BOARD_USES_METADATA_PARTITION := true
Cambios en la secuencia de inicio
Cuando se utiliza el cifrado de metadatos, vold debe estar ejecutándose antes de que se vold /data . Para asegurarse de que se inicie con la suficiente antelación, agregue la siguiente estrofa a init.hardware.rc :
# We need vold early for metadata encryption
on early-fs
start vold Keymaster debe estar ejecutándose y listo antes de que init intente montar /data .
init.hardware.rc ya debería contener una instrucción mount_all que se monta /data en la estrofa on late-fs . Antes de esta línea, agregue la directiva para wait_for_keymaster servicio wait_for_keymaster :
on late-fs
…
# Wait for keymaster
exec_start wait_for_keymaster
# Mount RW partitions which need run fsck
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --lateActivar el cifrado de metadatos
Finalmente, agregue keydirectory=/metadata/vold/metadata_encryption a la columna fs_mgr_flags de la entrada fstab para userdata . Por ejemplo, una línea fstab completa podría verse así:
/dev/block/bootdevice/by-name/userdata /data f2fs noatime,nosuid,nodev,discard,inlinecrypt latemount,wait,check,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized,keydirectory=/metadata/vold/metadata_encryption,quota,formattable
De forma predeterminada, el algoritmo de cifrado de metadatos en el almacenamiento interno es AES-256-XTS. Esto se puede anular configurando la opción metadata_encryption , también en la columna fs_mgr_flags :
- En dispositivos que carecen de aceleración AES, el cifrado Adiantum se puede habilitar configurando
metadata_encryption=adiantum. - En los dispositivos que admiten claves empaquetadas por hardware que se aprovisionan directamente al hardware de cifrado en línea, la clave de cifrado de metadatos se puede hacer empaquetada por hardware configurando
metadata_encryption=aes-256-xts:wrappedkey_v0. Consulte la documentación de FBE para obtener más información sobre las claves envueltas en hardware y sus requisitos previos.
Debido a que la interfaz del kernel a dm-default-key cambió en Android 11, también debe asegurarse de haber configurado el valor correcto para PRODUCT_SHIPPING_API_LEVEL en device.mk . Por ejemplo, si su dispositivo se inicia con Android 11 (nivel de API 30), device.mk debe contener:
PRODUCT_SHIPPING_API_LEVEL := 30
También puede configurar la siguiente propiedad del sistema para forzar el uso de la nueva API dm-default-key independientemente del nivel de API de envío:
PRODUCT_PROPERTY_OVERRIDES += \
ro.crypto.dm_default_key.options_format.version=2
Validación
Para verificar que el cifrado de metadatos esté habilitado y funcione correctamente, ejecute las pruebas que se describen a continuación. También tenga en cuenta los problemas comunes que se describen a continuación.
Pruebas
Comience ejecutando el siguiente comando para verificar que el cifrado de metadatos esté habilitado en el almacenamiento interno:
adb rootadb shell dmctl table userdata
La salida debe ser similar a:
Targets in the device-mapper table for userdata: 0-4194304: default-key, aes-xts-plain64 - 0 252:2 0 3 allow_discards sector_size:4096 iv_large_sectors
Si anula la configuración de cifrado predeterminada estableciendo la opción metadata_encryption en la fstab del dispositivo, la salida será ligeramente diferente a la anterior. Por ejemplo, si habilitó el cifrado Adiantum , el tercer campo será xchacha12,aes-adiantum-plain64 lugar de aes-xts-plain64 .
A continuación, ejecute vts_kernel_encryption_test para verificar la exactitud del cifrado de metadatos y FBE:
atest vts_kernel_encryption_test
o:
vts-tradefed run vts -m vts_kernel_encryption_test
Problemas comunes
Durante la llamada a mount_all , que monta la partición de /data cifrada con metadatos, init ejecuta la herramienta vdc. La herramienta vdc se conecta a vold over binder para configurar el dispositivo cifrado con metadatos y montar la partición. Mientras dure esta llamada, init está bloqueado y los intentos de leer o establecer las propiedades de init se bloquearán hasta que mount_all finalice. Si, en esta etapa, cualquier parte del vold de vold se bloquea directa o indirectamente al leer o configurar una propiedad, se producirá un punto muerto. Es importante asegurarse de que vold pueda completar el trabajo de leer las claves, interactuar con Keymaster y montar el directorio de datos sin interactuar más con init .
Si Keymaster no se inicia completamente cuando se ejecuta mount_all , no responderá a vold hasta que haya leído ciertas propiedades de init , resultando exactamente en el punto muerto descrito. Colocar exec_start wait_for_keymaster encima de la invocación mount_all relevante, como se establece, asegura que Keymaster se esté ejecutando completamente con anticipación y, por lo tanto, evita este punto muerto.
Configuración de almacenamiento adoptable
Desde Android 9, una forma de cifrado de metadatos siempre está habilitada en el almacenamiento adoptable siempre que FBE está habilitado, incluso cuando el cifrado de metadatos no está habilitado en el almacenamiento interno.
En AOSP, hay dos implementaciones de cifrado de metadatos en el almacenamiento adoptable: una obsoleta basada en dm-crypt y una más nueva basada en dm-default-key . Para asegurarse de que se selecciona la implementación correcta para su dispositivo, asegúrese de haber configurado el valor correcto para PRODUCT_SHIPPING_API_LEVEL en device.mk . Por ejemplo, si su dispositivo se inicia con Android 11 (nivel de API 30), device.mk debe contener:
PRODUCT_SHIPPING_API_LEVEL := 30
También puede configurar las siguientes propiedades del sistema para forzar el uso del nuevo método de cifrado de metadatos de volumen (y la nueva versión predeterminada de la política FBE) independientemente del nivel de API de envío:
PRODUCT_PROPERTY_OVERRIDES += \
ro.crypto.volume.metadata.method=dm-default-key \
ro.crypto.dm_default_key.options_format.version=2 \
ro.crypto.volume.options=::v2
Método actual
En dispositivos que se inician con Android 11 o superior, el cifrado de metadatos en el almacenamiento adoptable utiliza el módulo de kernel dm-default-key , al igual que en el almacenamiento interno. Consulte los requisitos previos anteriores para saber qué opciones de configuración del kernel habilitar. Tenga en cuenta que el hardware de cifrado en línea que funciona en el almacenamiento interno del dispositivo puede no estar disponible en el almacenamiento adoptable y, por lo tanto, CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y puede ser necesario.
De forma predeterminada, el método de cifrado de metadatos de volumen dm-default-key utiliza el algoritmo de cifrado AES-256-XTS con sectores de cifrado de 4096 bytes. El algoritmo se puede anular configurando la propiedad del sistema ro.crypto.volume.metadata.encryption . El valor de esta propiedad tiene la misma sintaxis que la opción fstab metadata_encryption descrita anteriormente. Por ejemplo, en dispositivos que carecen de aceleración AES, el cifrado Adiantum se puede habilitar configurando ro.crypto.volume.metadata.encryption=adiantum .
Método heredado
En los dispositivos que se inician con Android 10 o versiones anteriores, el cifrado de metadatos en el almacenamiento adoptable utiliza el módulo de kernel dm-crypt lugar de dm-default-key :
CONFIG_DM_CRYPT=y
A diferencia del método dm-default-key , el método dm-crypt hace que el contenido del archivo se cifre dos veces: una vez con una clave FBE y otra con la clave de cifrado de metadatos. Este doble cifrado reduce el rendimiento y no es necesario para lograr los objetivos de seguridad del cifrado de metadatos, ya que Android garantiza que las claves FBE sean al menos tan difíciles de comprometer como la clave de cifrado de metadatos. Los proveedores pueden realizar personalizaciones del kernel para evitar el doble cifrado, en particular implementando la opción allow_encrypt_override , que Android pasará a dm-crypt cuando la propiedad del sistema ro.crypto.allow_encrypt_override se establezca en true . Estas personalizaciones no son compatibles con el kernel común de Android.
De forma predeterminada, el método de cifrado de metadatos de volumen dm-crypt utiliza el algoritmo de cifrado AES-128-CBC con ESSIV y sectores de cifrado de 512 bytes. Esto se puede anular configurando las siguientes propiedades del sistema (que también se utilizan para FDE):
-
ro.crypto.fde_algorithmselecciona el algoritmo de cifrado de metadatos. Las opciones sonaes-128-cbcyadiantum. Adiantum solo se puede utilizar si el dispositivo carece de aceleración AES. -
ro.crypto.fde_sector_sizeselecciona el tamaño del sector criptográfico. Las opciones son 512, 1024, 2048 y 4096. Para el cifrado Adiantum, use 4096.