Android 7.0 y soportes superiores cifrado de 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.
Cifrado de metadatos siempre está habilitado en el almacenamiento adoptables cada vez que se habilita la FBE. 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 sobre almacenamiento interno
Puede configurar el cifrado de metadatos en el almacenamiento interno de nuevos dispositivos mediante la creación de la metadata del sistema de archivos, cambiar la secuencia de inicio, y que permite 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.
Cifrado de metadatos requiere que la dm-default-key módulo de ser activado en su núcleo. En Android 11 y superior, dm-default-key es apoyado por los núcleos comunes para Android, versión 4.14 y superiores. Esta versión del dm-default-key utiliza un hardware y el marco de cifrado independiente del proveedor llamada negro-cripto.
Para habilitar dm-default-key , utilice:
CONFIG_BLK_INLINE_ENCRYPTION=y CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y CONFIG_DM_DEFAULT_KEY=y
dm-default-key usos en línea de hardware de encriptación (hardware que cifra / descifra los datos mientras se encuentra en el camino a / 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 el cifrado de hardware en línea también debe permitir a cualquier aceleración basada en CPU disponibles como se recomienda en la documentación de la FBE .
En Android 10 e inferiores, dm-default-key no fue apoyada por el núcleo común de Android. Por lo tanto, era hasta vendedores para 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 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 ficheros de metadatos que vive en esa partición montarlo en /metadata , incluyendo el formattable bandera para asegurarse de que está formateado en el 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 asegurar el /metadata de montaje existe punto, añadir la siguiente línea al BoardConfig-common.mk :
BOARD_USES_METADATA_PARTITION := true
Cambios en la secuencia de inicio
Cuando se utiliza el cifrado de metadatos, vold debe ejecutar antes de /data está montado. Para asegurarse de que se comienza a tiempo, añada las siguientes líneas a init.hardware.rc :
# We need vold early for metadata encryption
on early-fs
start vold Keymaster debe estar en ejecución y listo antes de intentos de inicio al montaje /data .
init.hardware.rc ya debe contener un mount_all de instrucciones que se monta /data sí mismo en el on late-fs estrofa. Antes de esta línea, añada la directiva a exec con el wait_for_keymaster servicio:
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 añadir keydirectory=/metadata/vold/metadata_encryption a la columna de fs_mgr_flags del fstab entrada 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 mediante el establecimiento de la metadata_encryption opción, también en la columna de la fs_mgr_flags:
- En los dispositivos que carecen de AES aceleración, cifrado Adiantum puede habilitarse estableciendo
metadata_encryption=adiantum. - En dispositivos que admiten teclas de hardware-envuelta , la clave de cifrado de metadatos pueden hacerse por hardware envuelto configurando
metadata_encryption=aes-256-xts:wrappedkey_v0(o equivalentementemetadata_encryption=:wrappedkey_v0, comoaes-256-xtses el algoritmo predeterminado).
Debido a que la interfaz del núcleo a dm-default-key cambió en Android 11, también hay que asegurarse de que ha establecido el valor correcto para PRODUCT_SHIPPING_API_LEVEL en device.mk . Por ejemplo, si sus lanzamientos de dispositivos con Android 11 (API nivel 30), device.mk deben contener:
PRODUCT_SHIPPING_API_LEVEL := 30
También puede establecer la siguiente propiedad del sistema para forzar el uso de la nueva dm-default-key API independientemente de envío a nivel de 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 ser conscientes de 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 sustituimos los valores de cifrado por defecto mediante el metadata_encryption opción en el dispositivo de fstab , entonces la salida diferirá ligeramente de la anterior. Por ejemplo, si se habilita el cifrado Adiantum , entonces el tercer campo será xchacha12,aes-adiantum-plain64 en lugar de aes-xts-plain64 .
A continuación, ejecutar vts_kernel_encryption_test para verificar la exactitud de 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 los metadatos encriptados /data la partición, init ejecuta la herramienta VCC. Las Conexiones herramienta vdc a vold sobre binder para configurar el dispositivo de metadatos cifrado y montar la partición. Durante la duración de la llamada, init se bloquea, y los intentos de leer ni conjunto init propiedades se bloqueará hasta mount_all acabados. Si, en esta etapa, cualquier parte de vold trabajo 's está directa o indirectamente bloqueado en la lectura o la creación de una propiedad, estancamiento resultará. Es importante asegurarse de que vold puede completar el trabajo de la lectura de las teclas, interactuando con Keymaster, y montar el directorio de datos sin interactuar más con init .
Si no está completamente Keymaster comenzó cuando mount_all se ejecute, no responde a vold hasta que ha leído ciertas propiedades de init , lo que resulta en exactamente el punto muerto descrito. La colocación de exec_start wait_for_keymaster por encima de la correspondiente mount_all invocación como establecidos asegura que Keymaster está totalmente funcionando con antelación y así evita este punto muerto.
Configuración de almacenamiento adoptable
Dado que Android 9, una forma de encriptación metadatos siempre está habilitado en el almacenamiento adoptables cada vez que se activa FBE, incluso cuando el cifrado de metadatos no está habilitada en el almacenamiento interno.
En AOSP, hay dos implementaciones de cifrado en el almacenamiento de metadatos adoptables: una obsoleta basada en dm-crypt , y una más reciente basan en dm-default-key . Para garantizar que la aplicación correcta es seleccionado para el dispositivo, asegúrese de que ha establecido el valor correcto para PRODUCT_SHIPPING_API_LEVEL en device.mk . Por ejemplo, si sus lanzamientos de dispositivos con Android 11 (API nivel 30), device.mk deben 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 la 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 los dispositivos de puesta a flote con Android 11 o superior, cifrado en el almacenamiento de metadatos adoptables utiliza la dm-default-key módulo del núcleo, al igual que en el almacenamiento interno. Ver los requisitos anteriores para los que las opciones de configuración del kernel para habilitar. Tenga en cuenta que el hardware de encriptación en línea que funciona en el almacenamiento interno del dispositivo pueden no estar disponibles en el almacenamiento adoptables, y por lo tanto CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y puede ser necesaria.
Por defecto, la dm-default-key método de cifrado de volumen de metadatos utiliza el algoritmo de cifrado AES-256-XTS con sectores de cifrado 4096 bytes. El algoritmo puede ser anulado por el establecimiento de la ro.crypto.volume.metadata.encryption propiedad del sistema. El valor de esta propiedad tiene la misma sintaxis que la metadata_encryption opción fstab descrito anteriormente. Por ejemplo, en los dispositivos que carecen de AES aceleración, cifrado Adiantum se puede activar mediante el establecimiento de ro.crypto.volume.metadata.encryption=adiantum .
Método heredado
En los dispositivos de puesta a flote con Android 10 o inferior, cifrado en el almacenamiento de metadatos adoptables utiliza el dm-crypt módulo del núcleo en lugar de dm-default-key :
CONFIG_DM_CRYPT=y
A diferencia de la dm-default-key método, el dm-crypt método hace que el contenido del archivo a cifrar dos veces: una vez con una clave FBE y una vez 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 núcleo para evitar la doble encriptación, en particular, aplicando el allow_encrypt_override opción del cual pasará a Android dm-crypt cuando la propiedad del sistema ro.crypto.allow_encrypt_override se establece en true . Estas personalizaciones no son compatibles con el kernel común de Android.
Por defecto, el dm-crypt método de cifrado metadatos volumen utiliza el algoritmo de cifrado AES-128-CBC con los sectores de cifrado de 512 bytes y ESSIV. 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 puede utilizarse sólo si el dispositivo carece de AES aceleración. -
ro.crypto.fde_sector_sizeselecciona el tamaño de sector crypto. Las opciones son 512, 1024, 2048 y 4096. Para el cifrado Adiantum, use 4096.