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 pruebas FIPS
certificación si el producto que ejecuta el kernel de GKI lo requiere.
Se deben cumplir los siguientes requisitos del FIPS 140-3 antes del Se pueden usar las rutinas criptográficas:
- 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é usar un módulo de kernel independiente
La validación con FIPS 140-3 se basa en la idea de que una vez que un software o hardware basado en el módulo se certifica, nunca se modifica. Si se cambia, debe ser renovar la certificación. Esto no coincide fácilmente con los procesos de desarrollo de software en y, como resultado de este requisito, los módulos de software generalmente están diseñadas para enfocarse en los componentes criptográficos posible para garantizar que los cambios no relacionados con la criptografía no requieran una nueva evaluación de la criptografía.
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 estándar FIPS límite de módulo, ya que tendría que volver a certificarse cada kernel actualización. 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. Más allá de eso,
el módulo no ofrece capacidades adicionales, y cargarlo innecesariamente
solo es probable que afecte al tiempo de inicio, sin proporcionar ningún beneficio.
Cómo implementar el módulo
El módulo puede incorporarse a la compilación de Android mediante los siguientes pasos:
- Agrega el nombre del módulo a
BOARD_VENDOR_RAMDISK_KERNEL_MODULES
. Esto provoca el módulo se copiará en el ramdisk del proveedor. - Agrega el nombre del módulo a
BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD
. Esta hace que el nombre del módulo se agregue amodules.load
en el destino.modules.load
contiene la lista de módulos que cargainit
cuando el elemento 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 ELF se conservan dentro del módulo de modo que puedan aplicarse en inversa a la entrada de HMAC.
- El módulo revierte cualquier parche de código que haya realizado el kernel para el lenguaje Pila de llamadas paralelas. Específicamente, el módulo reemplaza las instrucciones que envía o resalta desde la pila de llamadas paralela con el código de autenticación del puntero. (PAC) que estaban presentes en un principio.
- Todos los demás parches de código están inhabilitados para el módulo, incluidas las claves estáticas y por lo tanto, puntos de seguimiento y hooks del proveedor.
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 de la misma de codificador-decodificador. Esto es necesario porque la CryptoAPI de Linux permite la prioridad que la selección basada en datos se elude y que un algoritmo de menor prioridad en su lugar.
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 AES |
Sí | Cifrado por bloques AES simple, 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 usando 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) usando 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 AES de este módulo, el llamador es responsable de proporcionar los IV. 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 de hash de criptografía SHA-224: El código se comparte con SHA-256. |
sha256 |
sha256-generic , sha256-arm64 , sha256-ce , biblioteca SHA-256 |
Sí | Función de hash de criptografía SHA-256: Además de la interfaz CryptoAPI estándar, se proporciona una interfaz de biblioteca a SHA-256. 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 de hash SHA3-224 de criptografía. Solo está presente en la versión de kernel 6.6 y versiones posteriores. |
sha3-256 |
sha3-256-generic |
Sí | Igual al anterior, pero con 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 al anterior, pero con 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 al anterior, pero con 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 redactar con cualquier implementación o algoritmo de SHA mediante 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í | Igual que los algoritmos drbg_pr_* , pero con la resistencia a las predicciones inhabilitada. El código se comparte con la variante resistente a las predicciones. En la versión de kernel 5.10, el DRBG de mayor prioridad 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 la versión de 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 a partir del código fuente
Para Android 14 y versiones posteriores (incluido
android-mainline
), compila el módulo fips140.ko
desde la fuente usando el
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 agentes criptográficos
Para operar el módulo de kernel, el sistema operativo debe estar restringido a un modo de operación de un solo operador. Android se encarga automáticamente de esta tarea. con hardware de administración de memoria en el procesador.
El módulo de kernel no se puede instalar por separado. se incluye como parte del del dispositivo y se cargan automáticamente durante el inicio. Solo funciona en un y el modo de operación aprobado.
El oficial de criptografía puede hacer que las autopruebas se ejecuten en cualquier momento reiniciando el dispositivo.
Orientación para el usuario
El usuario del módulo del kernel son otros componentes del kernel que deben usar algoritmos criptográficos. El módulo de kernel no proporciona lógica adicional en el uso de los algoritmos y no almacena ningún parámetro más allá del tiempo necesarias para realizar una operación criptográfica.
El uso de los algoritmos con fines de cumplimiento del estándar FIPS se limita a los resultados aprobados
con algoritmos criptográficos eficaces. Para cumplir con el “indicador de servicio” del estándar FIPS 140-3 de la infraestructura, la
proporciona una función fips140_is_approved_service
que indica si
se aprueba un algoritmo.
Errores de autoprueba
En caso de que se produzca una falla en la autoprueba, el módulo del kernel hace que el kernel se y el dispositivo no continuará con el proceso de 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.
-
Se espera que las implementaciones AES-GCM del módulo sean “algoritmos de aprobado" pero no "módulo aprobado". Pueden validarse, pero AES-GCM No se puede considerar un algoritmo aprobado desde el punto de vista del módulo FIPS. Esto se debe a que los requisitos del módulo FIPS para GCM no son compatibles con Implementaciones de GCM que no generan sus propios IV ↩