Módulo criptográfico de GKI certificado de FIPS 140-3

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

El kernel de GKI incluye un módulo de kernel de Linux llamado fips140.ko que cumple con Requisitos de FIPS 140-3 para los módulos de software criptográfico. Este módulo se puede enviar para la certificación FIPS si el producto que ejecuta el kernel de GKI lo requiere.

En particular, se deben cumplir los siguientes requisitos del estándar FIPS 140-3 antes de que se puedan usar las rutinas de criptografía:

• El módulo debe comprobar su propia integridad antes de crear algoritmos criptográficos disponibles.
• El módulo debe ejecutar y verificar sus algoritmos criptográficos aprobados con autopruebas de respuestas conocidas antes de que estén disponibles.

Por qué se usa un módulo de kernel independiente

La validación de FIPS 140-3 se basa en la idea de que, una vez que se certifica un módulo basado en software o hardware, nunca se cambia. Si se cambia, debe ser renovar la certificación. Esto no coincide fácilmente con los procesos de desarrollo de software que se usan en la actualidad y, como resultado de este requisito, los módulos de software de FIPS suelen diseñarse para enfocarse lo más posible en los componentes criptográficos, a fin de garantizar que los cambios que no estén relacionados con la criptografía no requieran una nueva evaluación de esta.

El kernel de GKI está diseñado para actualizarse con regularidad durante toda la etapa de vida útil. Esto hace que sea inviable que todo el kernel esté dentro del límite del módulo FIPS, ya que ese módulo debería volver a certificarse en cada actualización del kernel. Cómo definir el “módulo FIPS” como un subconjunto de la imagen del kernel mitigar este problema, pero no lo resolvería, ya que los contenidos binarios del "Módulo FIPS" cambiarían con mucha más frecuencia de la necesaria.

Antes de la versión de kernel 6.1, otra consideración era que GKI se compiló con Se habilitó LTO (Optimización del tiempo por vinculación), ya que era un requisito previo para controlar Integridad del flujo, que es una función de seguridad importante

Por lo tanto, todo el código incluido en los requisitos del estándar FIPS 140-3 se empaqueta en un módulo de kernel fips140.ko independiente que solo se basa en archivos Son interfaces expuestas por la fuente del kernel de GKI desde la que se compiló. Esta significa que el módulo se puede usar con diferentes versiones de GKI del mismo generación y que debe actualizarse y volver a enviarse solo para certificación si se solucionó algún problema en el código que lleva el módulo.

Cuándo usar el módulo

El kernel de GKI lleva un código que depende de las rutinas criptográficas incluidos en el módulo de kernel del FIPS 140-3. Por lo tanto, el método criptográfico incorporado las rutinas no se quitan del kernel de GKI, sino que se copian el módulo. Cuando el módulo está cargado, las rutinas criptográficas integradas se de la CryptoAPI de Linux y sustituidas por las que llevan las módulo.

Esto significa que el módulo fips140.ko es completamente opcional y solo hace y, si es necesario, la certificación con el estándar FIPS 140-3. Además, el módulo no proporciona capacidades adicionales, y cargarlo innecesariamente solo puede afectar el tiempo de inicio, sin proporcionar ningún beneficio.

Cómo implementar el módulo

El módulo se puede incorporar en la compilación de Android siguiendo estos pasos:

• Agrega el nombre del módulo a BOARD_VENDOR_RAMDISK_KERNEL_MODULES. Esto hace que el módulo se copie en el ramdisk del proveedor.
• Agrega el nombre del módulo a BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD. Esto hace que el nombre del módulo se agregue a modules.load en el destino. modules.load contiene la lista de módulos que carga init cuando se inicia el dispositivo.

La autoverificación de integridad

El módulo de kernel del FIPS 140-3 toma el resumen HMAC-SHA256 de su propio .code y .rodata en el tiempo de carga del módulo, y lo compara con el resumen registrados en el módulo. Esto ocurre después de que el cargador de módulos de Linux ya realizó las modificaciones habituales, como el procesamiento de la reubicación ELF alternativas a esas secciones para aplicar parches en la errata de la CPU. Lo siguiente se toman medidas adicionales para garantizar que el resumen se pueda reproducir correctamente:

• Las reubicaciones de ELF se conservan dentro del módulo para que se puedan aplicar de forma inversa a la entrada del HMAC.
• El módulo invierte cualquier parche de código que haya hecho el kernel para la pila de llamadas de sombra dinámica. Específicamente, el módulo reemplaza cualquier instrucción que inserte o quite de la pila de llamadas en la sombra con las instrucciones de código de autenticación de punteros (PAC) que estaban presentes originalmente.
• Se inhabilitan todos los demás parches de código para el módulo, incluidas las claves estáticas y, por lo tanto, los puntos de seguimiento, así como los hooks de proveedores.

Las autopruebas de respuesta conocida

Todos los algoritmos implementados que estén cubiertos por los requisitos del estándar FIPS 140-3 deben realizar una autoprueba de respuesta conocida antes de usarla. Según el estándar FIPS 140-3, Orientación para la implementación 10.3.A un solo vector de prueba por algoritmo con cualquiera de las longitudes de clave admitidas suficiente para los cifrados, siempre que se prueben tanto la encriptación como la desencriptación.

La CryptoAPI de Linux tiene una noción de prioridades de algoritmos, en la que implementaciones (como una que usa instrucciones criptográficas especiales y un resguardo en CPU que no implementan esas instrucciones) del mismo algoritmo coexistir. Por lo tanto, es necesario probar todas las implementaciones del mismo algoritmo. Esto es necesario porque la CryptoAPI de Linux permite omitir la selección basada en la prioridad y, en su lugar, seleccionar un algoritmo de prioridad más baja.

Algoritmos incluidos en el módulo

A continuación, se indican todos los algoritmos incluidos en el módulo del estándar FIPS 140-3. Esto se aplica a las políticas android12-5.10, android13-5.10, android13-5.15 y Sin embargo, las ramas de kernel android14-5.15, android14-6.1 y android15-6.6 se observan las diferencias entre las versiones de kernel cuando corresponde.

Algoritmo	Implementaciones	Aprobable	Definición
aes	aes-generic, aes-arm64, aes-ce, biblioteca de AES	Sí	Algoritmo de cifrado por bloques AES sin modo de operación: Se admiten todos los tamaños de clave (128 bits, 192 bits y 256 bits). Todas las implementaciones que no sean la de la biblioteca se pueden componer con un modo de operación a través de una plantilla.
cmac(aes)	cmac (plantilla), cmac-aes-neon, cmac-aes-ce	Sí	AES-CMAC: Se admiten todos los tamaños de clave AES. La plantilla cmac se puede componer con cualquier implementación de aes con cmac(<aes-impl>). Las otras implementaciones son independientes.
ecb(aes)	ecb (plantilla), ecb-aes-neon, ecb-aes-neonbs, ecb-aes-ce	Sí	AES-ECB: Se admiten todos los tamaños de clave AES. La plantilla ecb se puede componer con cualquier implementación de aes usando ecb(<aes-impl>). Las otras implementaciones son independientes.
cbc(aes)	cbc (plantilla), cbc-aes-neon, cbc-aes-neonbs, cbc-aes-ce	Sí	AES-CBC: Se admiten todos los tamaños de clave AES. La plantilla cbc se puede componer con cualquier implementación de aes usando ctr(<aes-impl>). Las otras implementaciones son independientes.
cts(cbc(aes))	cts (plantilla), cts-cbc-aes-neon, cts-cbc-aes-ce	Sí	AES-CBC-CTS o AES-CBC con robo de texto cifrado: La convención que se usa es CS3. los dos últimos bloques se intercambian de forma incondicional. Se admiten todos los tamaños de clave AES.La plantilla cts se puede componer con cualquier implementación de cbc usando cts(<cbc(aes)-impl>).Las otras implementaciones son independientes.
ctr(aes)	ctr (plantilla), ctr-aes-neon, ctr-aes-neonbs, ctr-aes-ce	Sí	AES-CTR: Se admiten todos los tamaños de clave AES. La plantilla ctr se puede componer con cualquier implementación de aes usando ctr(<aes-impl>). Las otras implementaciones son independientes.
xts(aes)	xts (plantilla), xts-aes-neon, xts-aes-neonbs, xts-aes-ce	Sí	AES-XTS: En la versión de kernel 6.1 y anteriores, se admiten todos los tamaños de clave AES. en la versión de kernel 6.6 y posteriores, solo se admiten AES-128 y AES-256. La plantilla xts se puede componer con cualquier implementación de ecb(aes) con xts(<ecb(aes)-impl>). Las otras implementaciones son independientes. Todas las implementaciones implementan la comprobación de clave débil que requiere FIPS; es decir, se rechazan las claves XTS cuyos primeros y segundos son iguales.
gcm(aes)	gcm (plantilla), gcm-aes-ce	No1	AES-GCM: Se admiten todos los tamaños de clave AES. Solo se admiten IV de 96 bits. Al igual que con todos los demás modos de AES en este módulo, el llamador es responsable de proporcionar los IVs. La plantilla gcm se puede componer con cualquier implementación de ctr(aes) y ghash a través de gcm_base(<ctr(aes)-impl>,<ghash-impl>). Las otras implementaciones son independientes.
sha1	sha1-generic, sha1-ce	Sí	Función de hash de criptografía SHA-1
sha224	sha224-generic, sha224-arm64 y sha224-ce	Sí	Función hash criptográfica SHA-224: El código se comparte con SHA-256.
sha256	sha256-generic, sha256-arm64, sha256-ce, biblioteca SHA-256	Sí	Función hash criptográfica SHA-256: Se proporciona una interfaz de biblioteca a SHA-256, además de la interfaz estándar de CryptoAPI. Esta interfaz de biblioteca usa una implementación diferente.
sha384	sha384-generic, sha384-arm64 y sha384-ce	Sí	Función de hash de criptografía SHA-384: El código se comparte con SHA-512.
sha512	sha512-generic, sha512-arm64 y sha512-ce	Sí	Función de hash de criptografía SHA-512
sha3-224	sha3-224-generic	Sí	Función hash criptográfica SHA3-224. Solo está presente en la versión de kernel 6.6 y versiones posteriores.
sha3-256	sha3-256-generic	Sí	Igual que el anterior, pero con una longitud de resumen de 256 bits (SHA3-256). Todas las longitudes de resumen usan la misma implementación de Keccak.
sha3-384	sha3-384-generic	Sí	Igual que el anterior, pero con una longitud de resumen de 384 bits (SHA3-384). Todas las longitudes de resumen usan la misma implementación de Keccak.
sha3-512	sha3-512-generic	Sí	Igual que el anterior, pero con una longitud de resumen de 512 bits (SHA3-512). Todas las longitudes de resumen usan la misma implementación de Keccak.
hmac	hmac (plantilla)	Sí	HMAC (código de autenticación de mensajes en clave hash): La plantilla hmac se puede componer con cualquier algoritmo o implementación de SHA con hmac(<sha-alg>) o hmac(<sha-impl>).
stdrng	drbg_pr_hmac_sha1, drbg_pr_hmac_sha256, drbg_pr_hmac_sha384, drbg_pr_hmac_sha512	Sí	Se creó una instancia de HMAC_DRBG con la función hash con nombre y con la resistencia a la predicción habilitada: Se incluyen las verificaciones de estado. Los usuarios de esta interfaz obtienen sus propias instancias de DRBG.
stdrng	drbg_nopr_hmac_sha1, drbg_nopr_hmac_sha256, drbg_nopr_hmac_sha384, drbg_nopr_hmac_sha512	Sí	Es igual que los algoritmos drbg_pr_*, pero con la resistencia a la predicción inhabilitada. El código se comparte con la variante resistente a las predicciones. En la versión 5.10 del kernel, el DRBG de prioridad más alta es drbg_nopr_hmac_sha256. En la versión de kernel 5.15 y posteriores, es drbg_pr_hmac_sha512.
jitterentropy_rng	jitterentropy_rng	No	Jitter RNG, ya sea la versión 2.2.0 (kernel versión 6.1 y anterior) o versión 3.4.0 (kernel versión 6.6 y posterior) Los usuarios de esta interfaz obtienen sus propias instancias de Jitter RNG. No reutilizan las instancias que usan los DRBG.
xcbc(aes)	xcbc-aes-neon, xcbc-aes-ce	No
xctr(aes)	xctr-aes-neon, xctr-aes-ce	No	Solo está presente en el kernel 5.15 y versiones posteriores.
cbcmac(aes)	cbcmac-aes-neon, cbcmac-aes-ce	No
essiv(cbc(aes),sha256)	essiv-cbc-aes-sha256-neon, essiv-cbc-aes-sha256-ce	No

Compila el módulo desde el código fuente

En el caso de Android 14 y versiones posteriores (incluida android-mainline), compila el módulo fips140.ko desde la fuente con los siguientes comandos.

• Compila con Bazel:

  tools/bazel run //common:fips140_dist

• Compila con build.sh (heredado):

  BUILD_CONFIG=common/build.config.gki.aarch64.fips140 build/build.sh

Estos comandos realizan una compilación completa que incluye el kernel y el fips140.ko. con el contenido de resumen HMAC-SHA256 incorporado.

Orientación para usuarios finales

Guía para funcionarios criptográficos

Para operar el módulo del kernel, el sistema operativo debe restringirse a un modo de operación de operador único. Android se encarga automáticamente de esta tarea. con hardware de administración de memoria en el procesador.

El módulo del kernel no se puede instalar por separado, ya que se incluye como parte del firmware del dispositivo y se carga automáticamente durante el inicio. Solo funciona en un y el modo de operación aprobado.

El encargado de criptografía puede reiniciar el dispositivo para que se ejecuten las autopruebas en cualquier momento.

Orientación para el usuario

El usuario del módulo del kernel son otros componentes del kernel que deben usar algoritmos de criptografía. El módulo del kernel no proporciona lógica adicional en el uso de los algoritmos ni almacena ningún parámetro más allá del tiempo necesario para realizar una operación criptográfica.

El uso de los algoritmos para el cumplimiento de FIPS se limita a los algoritmos aprobados. Para satisfacer el requisito de "indicador de servicio" del FIPS 140-3, el módulo proporciona una función fips140_is_approved_service que indica si se aprobó un algoritmo.

Errores de autoprueba

En caso de que falle la autoprueba, el módulo del kernel hace que el kernel entre en pánico y el dispositivo no continúe con el inicio. Si reinicias el dispositivo no resuelve el problema, el dispositivo debe iniciarse en Modo de recuperación para corregir la para solucionar el problema. Para ello, vuelve a escribir en la memoria flash del dispositivo.