Claves unidas por hardware

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 por un hardware dedicado y no por software, el software, por lo general, debe administrar las claves de encriptación sin procesar.

Por lo general, esto no se ve como un problema, ya que las claves no estarán presentes. durante un ataque sin conexión, que es el principal tipo de ataque que cómo se protege la encriptación. 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, unirlas en formas efímeras y a largo plazo, del usuario, programar directamente una subclave en un motor criptográfico 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 unidas en hardware, que incluye lo siguiente: y qué soporte de hardware se necesita. Este análisis se centra en la encriptación basada en archivos (FBE), pero que la solución se aplica a los metadatos encriptación.

Una forma de evitar la necesidad de las claves de encriptación sin procesar en la memoria del sistema sería y mantenerlos solo en las ranuras de un motor criptográfico intercalado. Sin embargo, enfoque tiene algunos problemas:

• Es posible que la cantidad de claves de encriptación supere la cantidad de ranuras de claves.
• Los motores criptográficos intercalados solo se pueden usar para encriptar o desencriptar bloques completos de en el disco. Sin embargo, en el caso de los FBE, el software debe poder hacer otras tareas criptográficas, como la encriptación de nombres de archivo y las claves derivadas identificadores. 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. En Además, la jerarquía de claves se modifica y se mueve parcialmente a este hardware, que permite devolver una subclave al software para tareas que no pueden usar una con un motor criptográfico intercalado.

Jerarquía de claves

Las claves se pueden derivar de otras claves con un KDF (función de derivación de claves), como HKDF. lo que da como resultado una jerarquía de claves.

El siguiente diagrama muestra una típica jerarquía de claves para FBE cuando claves unidas con hardware no se usan:

La clave de clase FBE es la clave de encriptación sin procesar que Android pasa a Linux para desbloquear un conjunto particular de directorios encriptados, como el almacenamiento encriptado con credenciales para 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:

• Es el identificador de la clave. Esto no se usa para la encriptación, sino que es un valor que se usa para identificar la clave con la que un archivo o directorio en particular están protegidos.
• La clave de encriptación del contenido del archivo
• La clave de encriptación del nombre 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. La raíz aún representa la clave que Android pasa a Linux para desbloquear un conjunto de directorios encriptados. Sin embargo, ahora esa clave está unida de forma efímera y para poder usarla, se debe pasar a hardware dedicado. Este hardware debe implementar dos interfaces que toman una clave unida de forma efímera:

• Una interfaz para derivar inline_encryption_key y programarlo en una ranura del motor criptográfico 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 al blk_crypto_ll_ops::keyslot_program, que debe ser que implementa el controlador de almacenamiento.
• Una interfaz para derivar y mostrar sw_secret ("software Secret" también denominado "Secreto sin procesar" en algunos lugares), que es la clave que Linux los usa para derivar las subclaves de todo lo que no sea el contenido del archivo. encriptación. En los kernels comunes de Android, esta interfaz corresponde al blk_crypto_ll_ops::derive_sw_secret, que debe ser que implementa el controlador de almacenamiento.

Para derivar inline_encryption_key y sw_secret de la sin procesar, el hardware debe usar un KDF seguro a nivel criptográfico. Este KDF Debe seguir las prácticas recomendadas de criptografía. debe tener una seguridad de seguridad de al como mínimo, 256 bits, es decir, suficiente para cualquier algoritmo que se use más adelante. También debe usar un etiqueta distinta, contexto o cadena de información específica de la aplicación cuando derivar cada tipo de subclave para garantizar que las subclaves resultantes están aislados criptográficamente, es decir, el conocimiento de uno de ellos no revela entre sí. No es necesario extender la clave, dado que la clave de almacenamiento sin procesar ya es un uniformemente aleatoria.

Técnicamente, se puede usar cualquier KDF que cumpla con los requisitos de seguridad. Sin embargo, para fines de prueba, es necesario volver a implementar el mismo KDF en 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 usando una clave. que se genera de forma aleatoria en cada inicio y 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 envueltos de forma efímera. Esto garantiza que si un atacante puede extraer clave en uso de la memoria del sistema, no solo quedará inutilizable, no en el 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. Los datos sin procesar de código compatibles funcionarían con este propósito. Sin embargo, es deseable nunca tener los datos en la memoria del sistema para que nunca se puedan extraer usarse fuera del dispositivo, incluso si se extraen en el momento del inicio. Por este motivo, el concepto de ajuste a largo plazo.

Para admitir la administración de claves unidas de estas dos formas diferentes, el hardware debe implementa las siguientes interfaces:

• Interfaces para generar e importar claves de almacenamiento, que las devuelven en formato integrado a largo plazo. Se accede a estas interfaces indirectamente KeyMint y corresponden a la etiqueta de KeyMint TAG_STORAGE_KEY. La columna "generate" vold usa la función para generar nuevo almacenamiento claves para usar en Android, mientras que el comando "import" la capacidad se usa por vts_kernel_encryption_test para importar claves de prueba.
• Una interfaz para convertir una clave de almacenamiento unido a largo plazo en un una clave de almacenamiento unida de forma efímera. Esto corresponde al KeyMint de convertStorageKeyToEphemeral. Este método se usa por vold y vts_kernel_encryption_test para 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. Esta incluye compatibilidad con componentes del espacio de usuario, como vold, y como la compatibilidad del 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 criptográfico intercalado del dispositivo. para admitir claves unidas 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, establecer BLK_CRYPTO_FEATURE_WRAPPED_KEYS en blk_keyslot_manager::features, marca blk_ksm_ll_ops::keyslot_program y blk_ksm_ll_ops::keyslot_evict admitir la programación y la expulsión de claves unidas a hardware, y, luego, implementar blk_ksm_ll_ops::derive_raw_secret.

Para los kernels android11, establecer BLK_CRYPTO_FEATURE_WRAPPED_KEYS en keyslot_manager::features, marca keyslot_mgmt_ll_ops::keyslot_program y keyslot_mgmt_ll_ops::keyslot_evict admitir la programación y la expulsión de claves unidas a hardware, y, luego, implementar 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 las claves unidas en hardware (p.ej., 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 se seguirán "aprobado" en ese caso.

Habilitando...

Una vez que la compatibilidad de la clave unida en hardware del dispositivo funcione correctamente, puedes haz los siguientes cambios en el archivo fstab del dispositivo Android lo usa para la encriptación de metadatos y FBE:

• FBE: agrega la marca wrappedkey_v0 al Parámetro fileencryption. Por ejemplo, usa fileencryption=::inlinecrypt_optimized+wrappedkey_v0 Para más detalles, consulta la FBE documentación.
• Encriptación de metadatos: agrega la marca wrappedkey_v0 al Parámetro metadata_encryption. Por ejemplo, usa metadata_encryption=:wrappedkey_v0 Para obtener más detalles, consulta la metadatos documentación de encriptación.