Android 7.0 y versiones posteriores admiten 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 utiliza FBE, otra información, como diseños de directorios, tamaños de archivos, permisos y tiempos de creación/modificación, no se cifra. En conjunto, esta otra información se conoce como metadatos del sistema de archivos.
Android 9 introdujo soporte para el cifrado de metadatos. Con el cifrado de metadatos, una única 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á protegida por un arranque verificado.
El cifrado de metadatos siempre está habilitado en el almacenamiento adoptable siempre que FBE esté habilitado. El cifrado de metadatos también se puede habilitar en el almacenamiento interno. Los dispositivos lanzados con Android 11 o superior deben tener habilitado el cifrado de metadatos en el almacenamiento interno.
Implementación en almacenamiento interno.
Puede configurar el cifrado de metadatos en el almacenamiento interno de nuevos dispositivos configurando el sistema de archivos metadata , cambiando la secuencia de inicio y habilitando el cifrado de metadatos en el archivo fstab del dispositivo.
Requisitos previos
El cifrado de metadatos solo se puede configurar cuando se formatea la partición de datos por primera vez. Como resultado, esta función es sólo para dispositivos nuevos; Esto no es algo que una OTA deba cambiar.
El cifrado de metadatos requiere que el módulo dm-default-key esté habilitado en su kernel. En Android 11 y superiores, dm-default-key es compatible con los kernels comunes de Android, versión 4.14 y superiores. Esta versión de dm-default-key utiliza un marco de cifrado independiente del proveedor y del hardware llamado 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 cifrado en línea (hardware que cifra/descifra datos mientras están en camino hacia/desde el dispositivo de almacenamiento) cuando está disponible. Si no va a utilizar hardware de cifrado en línea, también es necesario habilitar un respaldo a la API de criptografía del kernel:
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, el kernel común de Android no admitía dm-default-key . 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 la clave de cifrado de metadatos esté presente, la tabla de particiones debe reservar una partición separada llamada "partición de metadatos" para almacenar los blobs maestros de claves 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 montándolo en /metadata , incluido el indicador 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 montar /data . Para asegurarse de que se inicie con 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 monta /data en la estrofa on late-fs . Antes de esta línea, agregue la directiva para ejecutar el 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 dispositivos que admiten claves empaquetadas por hardware , la clave de cifrado de metadatos se puede empaquetar por hardware configurando
metadata_encryption=aes-256-xts:wrappedkey_v0(o de manera equivalentemetadata_encryption=:wrappedkey_v0, ya queaes-256-xtses el algoritmo predeterminado).
Debido a que la interfaz del kernel para 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 envío de la API:
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 debería 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 anuló la configuración de cifrado predeterminada configurando la opción metadata_encryption en el fstab del dispositivo, el resultado será ligeramente diferente al anterior. Por ejemplo, si habilitó el cifrado Adiantum , el tercer campo será xchacha12,aes-adiantum-plain64 en 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 /data cifrada con metadatos, init ejecuta la herramienta vdc. La herramienta vdc se conecta a vold over binder para configurar el dispositivo cifrado de metadatos y montar la partición. Mientras dure esta llamada, init está bloqueado y los intentos de leer o establecer propiedades init se bloquearán hasta que finalice mount_all . Si, en esta etapa, cualquier parte del trabajo 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 , lo que resultará exactamente en el punto muerto descrito. Colocar exec_start wait_for_keymaster encima de la invocación mount_all relevante como se establece garantiza que Keymaster se esté ejecutando completamente por adelantado y, por lo tanto, evita este punto muerto.
Configuración en almacenamiento adoptable
Desde Android 9, siempre se habilita una forma de cifrado de metadatos 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 seleccionar 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 de política FBE predeterminada) 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 del 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, es posible que se requiera CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y .
De forma predeterminada, el método de cifrado de metadatos del volumen dm-default-key utiliza el algoritmo de cifrado AES-256-XTS con sectores criptográficos 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 dispositivos que se inician con Android 10 o versiones anteriores, el cifrado de metadatos en el almacenamiento adoptable utiliza el módulo del kernel dm-crypt en 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 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 esté configurada 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 sectores criptográficos ESSIV y 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 sólo 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, utilice 4096.