Como la mayoría de los software de encriptación de archivos y discos, la encriptación de almacenamiento de Android tradicionalmente depende de que las claves de encriptación sin procesar estén presentes en la memoria del sistema para poder encriptar datos. Incluso cuando la encriptación se realiza con hardware dedicado en lugar de software, este generalmente aún debe administrar las claves de encriptación sin procesar.
Tradicionalmente, esto no se considera un problema porque las claves no estarán presentes durante un ataque sin conexión, que es el tipo de ataque principal contra el que se diseñó la encriptación del almacenamiento. Sin embargo, existe el deseo de ofrecer Mayor protección contra otros tipos de ataques, como el inicio en frío ataques en línea y ataques en línea en los que un atacante podría filtrar el sistema memoria sin comprometer por completo el dispositivo.
Para resolver este problema, Android 11 introdujo la compatibilidad para llaves unidas en hardware, en las que existe compatibilidad de hardware Las claves unidas en hardware son claves de almacenamiento que solo se conocen sin procesar para el hardware dedicado; el software solo ve y funciona con estas claves dentro (encriptado). Este hardware debe ser capaz de generar e importar claves de almacenamiento, unir claves de almacenamiento en formas efímeras y a largo plazo, derivar subclaves, programar directamente una subclave en un motor de criptografía intercalado y mostrar una subclave independiente al software.
Nota: Un motor criptográfico intercalado (o intercalado) hardware de encriptación) se refiere al hardware que encripta/desencripta datos mientras cuando está en camino hacia o desde el dispositivo de almacenamiento. Por lo general, es un host de UFS o eMMC controlador que implemente las extensiones criptográficas definidas por el servicio correspondiente JEDEC.
Diseño
En esta sección, se presenta el diseño de la función de claves empaquetadas en hardware, incluida la compatibilidad de hardware necesaria para ella. Este análisis se enfoca en la encriptación basada en archivos (FBE), pero la solución también se aplica a la encriptación de metadatos.
Una forma de evitar la necesidad de las claves de encriptación sin procesar en la memoria del sistema sería guardarlas solo en los espacios de claves de un motor de criptografía intercalado. Sin embargo, este enfoque tiene algunos problemas:
- La cantidad de claves de encriptación puede exceder la cantidad de ranuras de claves.
- Los motores de criptografía intercalados solo se pueden usar para encriptar o desencriptar bloques completos de datos en el disco. Sin embargo, en el caso de la FBE, el software aún debe poder realizar otras tareas criptográficas, como la encriptación de nombres de archivos y la derivación de identificadores de claves. El software aún necesitaría acceso a las claves FBE sin procesar para hacer este otro trabajo.
Para evitar estos problemas, las claves de almacenamiento se convierten en llaves unidas por hardware, que solo las pueden usar o hardware específico. Esto permite que se admita una cantidad ilimitada de claves. Además, la jerarquía de claves se modifica y se traslada parcialmente a este hardware, lo que permite que se devuelva una subclave al software para tareas que no pueden usar un motor de criptografía intercalado.
Jerarquía de claves
Las claves se pueden derivar de otras con una KDF (función de derivación de claves), como HKDF, lo que genera una jerarquía de claves.
En el siguiente diagrama, se muestra una jerarquía de claves típica para la FBE cuando no se usan claves empaquetadas en hardware:
La clave de clase FBE es la clave de encriptación sin procesar que Android pasa al kernel de Linux para desbloquear un conjunto particular de directorios encriptados, como el almacenamiento encriptado con credenciales de un usuario de Android en particular. (En el kernel, este se denomina clave maestra de fscrypt). A partir de esta clave, el kernel deriva las siguientes subclaves:
- El identificador de clave. No se usa para la encriptación, sino que es un valor que se usa para identificar la clave con la que se protege un archivo o directorio en particular.
- La clave de encriptación del contenido del archivo
- La clave de encriptación de los nombres de archivo
Por el contrario, el siguiente diagrama muestra la jerarquía de claves de FBE cuando claves unidas con hardware:
En comparación con el caso anterior, se agregó un nivel adicional a la clave y la clave de encriptación del contenido del archivo se reubica. El nodo raíz sigue representando la clave que Android pasa a Linux para desbloquear un conjunto de directorios encriptados. Sin embargo, ahora esa clave está en forma de unión efímera y, para usarse, se debe pasar al hardware dedicado. Este hardware debe implementar dos interfaces que tomen una clave unida de forma efímera:
- Una interfaz para derivar
inline_encryption_key
y programarla directamente en un espacio de claves del motor de criptografía intercalado. Esto permite enviar archivos que el contenido se encripte o desencripta sin que el software tenga acceso a la . En los kernels comunes de Android, esta interfaz corresponde alblk_crypto_ll_ops::keyslot_program
, que debe ser que implementa el controlador de almacenamiento. - Una interfaz para derivar y mostrar
sw_secret
("secreto de software", también llamado "secreto sin procesar" en algunos lugares), que es la clave que usa Linux para derivar las subclaves de todo lo que no sea la encriptación del contenido de los archivos. En los kernels comunes de Android, esta interfaz corresponde a la operaciónblk_crypto_ll_ops::derive_sw_secret
, que debe implementar el controlador de almacenamiento.
Para derivar inline_encryption_key
y sw_secret
de la
sin procesar, el hardware debe usar un KDF criptográficamente seguro. Este KDF debe seguir las prácticas recomendadas de criptografía y tener una seguridad de al menos 256 bits, es decir, suficiente para cualquier algoritmo que se use más adelante. También debe usar una etiqueta, un contexto y una cadena de información específica de la app distinta cuando derive cada tipo de subclave para garantizar que las subclaves resultantes estén aisladas criptográficamente, es decir, que el conocimiento de una de ellas no revele ninguna otra. No se requiere el estiramiento de claves, ya que la clave de almacenamiento sin procesar ya es una clave aleatoria uniforme.
Técnicamente, se puede usar cualquier KDF que cumpla con los requisitos de seguridad.
Sin embargo, para realizar pruebas, es necesario volver a implementar el mismo KDF en el código de prueba. Actualmente, se revisó y se implementó un KDF. se puede encontrar
en el código fuente de vts_kernel_encryption_test
.
Se recomienda que el hardware use este KDF, que usa NIST SP 800-108 “KDF in Counter Mode” con AES-256-CMAC como PRF. Ten en cuenta que, para ser compatibles, todas
partes del algoritmo deben ser idénticas, incluida la elección de contextos de KDF
y etiquetas para cada subclave.
Unión de claves
Para cumplir con los objetivos de seguridad de las claves unidas con hardware, hay dos tipos de unión de claves están definidos:
- Unión efímera: El hardware encripta la clave sin procesar con una clave que se genera de forma aleatoria en cada inicio y que no se expone directamente fuera del hardware.
- Unión a largo plazo: el hardware encripta la clave sin procesar con un una clave única y persistente integrada en el hardware que no está directamente expuestas por fuera del hardware.
Todas las claves que se pasan al kernel de Linux para desbloquear el almacenamiento se unen de forma efímera. Esto garantiza que, si un atacante puede extraer una clave en uso de la memoria del sistema, esa clave no se pueda usar, no solo fuera del dispositivo, sino también en el dispositivo después de un reinicio.
Al mismo tiempo, Android debe poder almacenar una versión encriptada de las claves en el disco para que se puedan desbloquear. Las claves sin procesar funcionarían para este propósito. Sin embargo, es conveniente que las claves sin procesar nunca estén presentes en la memoria del sistema para que nunca se puedan extraer y usar fuera del dispositivo, incluso si se extraen durante el inicio. Por este motivo, se define el concepto de vinculación a largo plazo.
Para admitir la administración de claves unidas de estas dos formas diferentes, el hardware debe implementa las siguientes interfaces:
- Son interfaces para generar e importar claves de almacenamiento y devolverlas en forma unida a largo plazo. Se accede a estas interfaces indirectamente
KeyMint y corresponden a la etiqueta de KeyMint
TAG_STORAGE_KEY
.vold
usa la función "generar" para generar claves de almacenamiento nuevas que usará Android, mientras quevts_kernel_encryption_test
usa la función "importar" para importar claves de prueba. - Una interfaz para convertir una clave de almacenamiento unida a largo plazo en una clave de almacenamiento unida de forma efímera. Esto corresponde al método KeyMint
convertStorageKeyToEphemeral
.vold
yvts_kernel_encryption_test
usan este método para desbloquear el almacenamiento.
El algoritmo de unión de claves es un detalle de implementación, pero debe usar un un AEAD potente, como AES-256-GCM con IV aleatorios.
Se requieren cambios en el software
AOSP ya tiene un framework básico para admitir claves unidas en hardware. Esto incluye la compatibilidad con componentes del espacio de usuario, como vold
, así como la compatibilidad con el kernel de Linux en blk-crypto, fscrypt y dm-default-key.
Sin embargo, se requieren algunos cambios específicos de la implementación.
Cambios en KeyMint
Se debe modificar la implementación de KeyMint del dispositivo para que sea compatible
TAG_STORAGE_KEY
y, luego, implementa
convertStorageKeyToEphemeral
.
En Keymaster, se usó exportKey
en lugar de convertStorageKeyToEphemeral
.
Cambios en el kernel de Linux
Se debe modificar el controlador de kernel de Linux para el motor de criptografía intercalado del dispositivo para admitir claves empaquetadas en hardware.
Para kernels android14
y versiones posteriores,
establecer BLK_CRYPTO_KEY_TYPE_HW_WRAPPED
en blk_crypto_profile::key_types_supported
,
marca blk_crypto_ll_ops::keyslot_program
y blk_crypto_ll_ops::keyslot_evict
admitir la programación y la expulsión de claves unidas a hardware,
y, luego, implementar blk_crypto_ll_ops::derive_sw_secret
.
Para los kernels android12
y android13
, configura BLK_CRYPTO_FEATURE_WRAPPED_KEYS
en blk_keyslot_manager::features
, haz que blk_ksm_ll_ops::keyslot_program
y blk_ksm_ll_ops::keyslot_evict
admitan la programación o expulsión de claves empaquetadas en hardware, y, luego, implementa blk_ksm_ll_ops::derive_raw_secret
.
Para los kernels android11
, configura BLK_CRYPTO_FEATURE_WRAPPED_KEYS
en keyslot_manager::features
, haz que keyslot_mgmt_ll_ops::keyslot_program
y keyslot_mgmt_ll_ops::keyslot_evict
admitan la programación o expulsión de claves empaquetadas en hardware, y, luego, implementa keyslot_mgmt_ll_ops::derive_raw_secret
.
Prueba
Aunque la encriptación con claves unidas en hardware es más difícil de probar que la encriptación
con claves estándar, es posible realizar pruebas importando una clave de prueba y
o volver a implementar la derivación
de claves que hace el hardware. Esto se implementa
en vts_kernel_encryption_test
. Para ejecutar esta prueba,
ejecuta lo siguiente:
atest -v vts_kernel_encryption_test
Lee el registro de pruebas y verifica que los casos de prueba de la clave unida en hardware (por ejemplo,
FBEPolicyTest.TestAesInlineCryptOptimizedHwWrappedKeyPolicy
y
DmDefaultKeyTest.TestHwWrappedKey
) no se omitieron debido a la compatibilidad
por las claves unidas con hardware que no se detectan, ya que los resultados de la prueba aún
"aprobado" en ese caso.
Habilitar teclas
Una vez que la compatibilidad con la clave del dispositivo unida al hardware funcione correctamente, puedes realizar los siguientes cambios en el archivo fstab
del dispositivo para que Android la use para la encriptación de FBE y metadatos:
- FBE: Agrega la marca
wrappedkey_v0
al parámetrofileencryption
. Por ejemplo, usafileencryption=::inlinecrypt_optimized+wrappedkey_v0
. Para más detalles, consulta la FBE documentación. - Encriptación de metadatos: agrega la marca
wrappedkey_v0
al Parámetrometadata_encryption
. Por ejemplo, usametadata_encryption=:wrappedkey_v0
. Para obtener más detalles, consulta la metadatos documentación de encriptación.