Modulo crittografico GKI certificabile FIPS 140-3

Il kernel GKI include un modulo kernel Linux denominato fips140.ko conforme ai requisiti FIPS 140-3 per i moduli software crittografici. Questo modulo può essere inviato per la certificazione FIPS se il prodotto che esegue il kernel GKI lo richiede.

Prima di poter utilizzare le routine di crittografia, devono essere soddisfatti in particolare i seguenti requisiti FIPS 140-3:

• Il modulo deve controllare la propria integrità prima di rendere disponibili gli algoritmi crittografici.
• Il modulo deve esercitare e verificare i propri algoritmi crittografici approvati utilizzando autotest con risposte note prima di renderli disponibili.

Perché un modulo kernel separato

La convalida FIPS 140-3 si basa sull'idea che una volta certificato un modulo software o hardware, non viene mai modificato. Se modificato, deve essere ricertificato. Ciò non corrisponde facilmente ai processi di sviluppo software in uso oggi e, di conseguenza, i moduli software FIPS sono generalmente progettati per concentrarsi il più possibile sui componenti crittografici, in modo da garantire che le modifiche non correlate alla crittografia non richiedano una rivalutazione della crittografia.

Il kernel GKI è progettato per essere aggiornato regolarmente durante l'intero ciclo di vita supportato. In questo modo, è impossibile che l'intero kernel si trovi all'interno del limite del modulo FIPS, in quanto un modulo di questo tipo dovrebbe essere ricertificato a ogni aggiornamento del kernel. Definire il "modulo FIPS" come sottoinsieme dell'immagine del kernel mitigherebbe questo problema, ma non lo risolverebbe, poiché i contenuti binari del "modulo FIPS" cambierebbero comunque molto più spesso del necessario.

Prima della versione 6.1 del kernel, un'altra considerazione era che GKI veniva compilato con LTO (Link Time Optimization) abilitato, poiché LTO era un prerequisito per l'integrità del flusso di controllo, una funzionalità di sicurezza importante.

Pertanto, tutto il codice coperto dai requisiti FIPS 140-3 è incluso in un modulo del kernel separato fips140.ko che si basa solo su interfacce stabili esposte dall'origine del kernel GKI da cui è stato creato. Ciò significa che il modulo può essere utilizzato con diverse release di GKI della stessa generazione e che deve essere aggiornato e inviato nuovamente per la certificazione solo se sono stati risolti problemi nel codice contenuto nel modulo stesso.

Quando utilizzare il modulo

Il kernel GKI stesso contiene codice che dipende dalle routine crittografiche incluse anche nel modulo del kernel FIPS 140-3. Pertanto, le routine crittografiche integrate non vengono effettivamente spostate dal kernel GKI, ma vengono copiate nel modulo. Quando il modulo viene caricato, le routine di crittografia integrate vengono annullate dalla CryptoAPI di Linux e sostituite da quelle eseguite dal modulo.

Ciò significa che il modulo fips140.ko è completamente facoltativo e ha senso implementarlo solo se la certificazione FIPS 140-3 è un requisito. A parte questo, il modulo non fornisce funzionalità aggiuntive e il suo caricamento non necessario probabilmente influirà solo sul tempo di avvio, senza fornire alcun vantaggio.

Come eseguire il deployment del modulo

Il modulo può essere incorporato nella build Android seguendo questi passaggi:

• Aggiungi il nome del modulo a BOARD_VENDOR_RAMDISK_KERNEL_MODULES. In questo modo, il modulo viene copiato nel ramdisk del fornitore.
• Aggiungi il nome del modulo a BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD. In questo modo, il nome del modulo viene aggiunto a modules.load sulla destinazione. modules.load contiene l'elenco dei moduli caricati da init all'avvio del dispositivo.

L'autocontrollo dell'integrità

Il modulo kernel FIPS 140-3 esegue l'hash HMAC-SHA256 delle proprie sezioni .code e .rodata al momento del caricamento del modulo e lo confronta con l'hash registrato nel modulo. Ciò avviene dopo che il caricatore di moduli Linux ha già apportato le modifiche consuete, come l'elaborazione del riposizionamento ELF e l'applicazione di patch alternative per gli errata della CPU a queste sezioni. Per garantire che il digest possa essere riprodotto correttamente, vengono eseguiti i seguenti passaggi aggiuntivi:

• Le rilocazioni ELF vengono conservate all'interno del modulo in modo che possano essere applicate in senso inverso all'input dell'HMAC.
• Il modulo inverte le patch di codice apportate dal kernel per Dynamic Shadow Call Stack. Nello specifico, il modulo sostituisce qualsiasi istruzione che inserisce o estrae dallo stack di chiamate ombra le istruzioni del codice di autenticazione del puntatore (PAC) presenti originariamente.
• Tutte le altre patch del codice sono disattivate per il modulo, incluse le chiavi statiche e quindi anche i punti di traccia e gli hook del fornitore.

I test automatici con risposta nota

Tutti gli algoritmi implementati coperti dai requisiti FIPS 140-3 devono eseguire un test automatico con risposta nota prima di essere utilizzati. Secondo la guida all'implementazione FIPS 140-3 10.3.A, un singolo vettore di test per algoritmo che utilizza una qualsiasi delle lunghezze delle chiavi supportate è sufficiente per le cifrature, a condizione che vengano testate sia la crittografia che la decrittografia.

L'API Crypto di Linux ha una nozione di priorità degli algoritmi, in cui possono coesistere diverse implementazioni (ad esempio una che utilizza istruzioni di crittografia speciali e un fallback per le CPU che non implementano queste istruzioni) dello stesso algoritmo. Pertanto, è necessario testare tutte le implementazioni dello stesso algoritmo. Ciò è necessario perché Linux CryptoAPI consente di aggirare la selezione basata sulla priorità e di selezionare un algoritmo con priorità inferiore.

Algoritmi inclusi nel modulo

Tutti gli algoritmi inclusi nel modulo FIPS 140-3 sono elencati di seguito. Ciò vale per i rami del kernel android12-5.10, android13-5.10, android13-5.15, android14-5.15, android14-6.1 e android15-6.6, anche se le differenze tra le versioni del kernel sono indicate ove opportuno.

Algoritmo	Implementazioni	Approvabile	Definizione
aes	aes-generic, aes-arm64, aes-ce, libreria AES	Sì	Cifratura a blocchi AES semplice, senza modalità di funzionamento: sono supportate tutte le dimensioni delle chiavi (128 bit, 192 bit e 256 bit). Tutte le implementazioni diverse da quella della libreria possono essere composte con una modalità di funzionamento tramite un modello.
cmac(aes)	cmac (modello), cmac-aes-neon, cmac-aes-ce	Sì	AES-CMAC: sono supportate tutte le dimensioni delle chiavi AES. Il modello cmac può essere composto con qualsiasi implementazione di aes utilizzando cmac(<aes-impl>). Le altre implementazioni sono autonome.
ecb(aes)	ecb (modello), ecb-aes-neon, ecb-aes-neonbs, ecb-aes-ce	Sì	AES-ECB: sono supportate tutte le dimensioni delle chiavi AES. Il modello ecb può essere composto con qualsiasi implementazione di aes utilizzando ecb(<aes-impl>). Le altre implementazioni sono autonome.
cbc(aes)	cbc (modello), cbc-aes-neon, cbc-aes-neonbs, cbc-aes-ce	Sì	AES-CBC: sono supportate tutte le dimensioni delle chiavi AES. Il modello cbc può essere composto con qualsiasi implementazione di aes utilizzando ctr(<aes-impl>). Le altre implementazioni sono autonome.
cts(cbc(aes))	cts (modello), cts-cbc-aes-neon, cts-cbc-aes-ce	Sì	AES-CBC-CTS o AES-CBC con furto di testo non criptato: la convenzione utilizzata è CS3; gli ultimi due blocchi di testo non criptato vengono scambiati in modo incondizionato. Sono supportate tutte le dimensioni delle chiavi AES. Il modello cts può essere composto con qualsiasi implementazione di cbc utilizzando cts(<cbc(aes)-impl>). Le altre implementazioni sono autonome.
ctr(aes)	ctr (modello), ctr-aes-neon, ctr-aes-neonbs, ctr-aes-ce	Sì	AES-CTR: sono supportate tutte le dimensioni delle chiavi AES. Il modello ctr può essere composto con qualsiasi implementazione di aes utilizzando ctr(<aes-impl>). Le altre implementazioni sono autonome.
xts(aes)	xts (modello), xts-aes-neon, xts-aes-neonbs, xts-aes-ce	Sì	AES-XTS: nella versione del kernel 6.1 e precedenti, sono supportate tutte le dimensioni delle chiavi AES; nella versione del kernel 6.6 e successive, sono supportati solo AES-128 e AES-256. Il modello xts può essere composto con qualsiasi implementazione di ecb(aes) utilizzando xts(<ecb(aes)-impl>). Le altre implementazioni sono autonome. Tutte le implementazioni implementano il controllo delle chiavi deboli richiesto da FIPS, ovvero le chiavi XTS la cui prima e seconda metà sono uguali vengono rifiutate.
gcm(aes)	gcm (modello), gcm-aes-ce	No1	AES-GCM: sono supportate tutte le dimensioni delle chiavi AES. Sono supportati solo IV a 96 bit. Come per tutte le altre modalità AES in questo modulo, il chiamante è responsabile della fornitura degli IV. Il modello gcm può essere composto da qualsiasi implementazione di ctr(aes) e ghash utilizzando gcm_base(<ctr(aes)-impl>,<ghash-impl>). Le altre implementazioni sono autonome.
sha1	sha1-generic, sha1-ce	Sì	Funzione di hash crittografica SHA-1
sha224	sha224-generic, sha224-arm64 e sha224-ce	Sì	Funzione hash crittografica SHA-224: il codice è condiviso con SHA-256.
sha256	sha256-generic, sha256-arm64, sha256-ce, libreria SHA-256	Sì	Funzione hash crittografica SHA-256: oltre all'interfaccia CryptoAPI standard, viene fornita un'interfaccia di libreria a SHA-256. Questa interfaccia della libreria utilizza un'implementazione diversa.
sha384	sha384-generic, sha384-arm64 e sha384-ce	Sì	Funzione di hash crittografica SHA-384: il codice è condiviso con SHA-512.
sha512	sha512-generic, sha512-arm64 e sha512-ce	Sì	Funzione hash crittografica SHA-512
sha3-224	sha3-224-generic	Sì	Funzione hash crittografica SHA3-224. Presente solo nella versione 6.6 e successive del kernel.
sha3-256	sha3-256-generic	Sì	Come il precedente, ma con lunghezza del digest di 256 bit (SHA3-256). Tutte le lunghezze del digest utilizzano la stessa implementazione di Keccak.
sha3-384	sha3-384-generic	Sì	Come il precedente, ma con lunghezza del digest di 384 bit (SHA3-384). Tutte le lunghezze del digest utilizzano la stessa implementazione di Keccak.
sha3-512	sha3-512-generic	Sì	Come il precedente, ma con lunghezza del digest di 512 bit (SHA3-512). Tutte le lunghezze del digest utilizzano la stessa implementazione di Keccak.
hmac	hmac (modello)	Sì	HMAC (Keyed-Hash Message Authentication Code): il modello hmac può essere composto con qualsiasi algoritmo o implementazione SHA utilizzando 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ì	HMAC_DRBG istanziato con la funzione hash denominata e con la resistenza alla previsione abilitata: sono inclusi i controlli di integrità. Gli utenti di questa interfaccia ottengono le proprie istanze DRBG.
stdrng	drbg_nopr_hmac_sha1, drbg_nopr_hmac_sha256, drbg_nopr_hmac_sha384, drbg_nopr_hmac_sha512	Sì	Uguale agli algoritmi drbg_pr_*, ma con la resistenza alla previsione disattivata. Il codice viene condiviso con la variante resistente alla previsione. Nella versione del kernel 5.10, il DRBG con la priorità più alta è drbg_nopr_hmac_sha256. Nella versione del kernel 5.15 e successive, è drbg_pr_hmac_sha512.
jitterentropy_rng	jitterentropy_rng	No	Jitter RNG, versione 2.2.0 (kernel versione 6.1 e precedenti) o versione 3.4.0 (kernel versione 6.6 e successive). Gli utenti di questa interfaccia ottengono le proprie istanze Jitter RNG. Non riutilizzano le istanze utilizzate dai DRBG.
xcbc(aes)	xcbc-aes-neon, xcbc-aes-ce	No
xctr(aes)	xctr-aes-neon, xctr-aes-ce	No	Presente solo nella versione del kernel 5.15 e successive.
cbcmac(aes)	cbcmac-aes-neon, cbcmac-aes-ce	No
essiv(cbc(aes),sha256)	essiv-cbc-aes-sha256-neon, essiv-cbc-aes-sha256-ce	No

Crea il modulo dal codice sorgente

Per Android 14 e versioni successive (incluso android-mainline), crea il modulo fips140.ko dall'origine utilizzando i seguenti comandi.

• Creazione con Bazel:

  tools/bazel run //common:fips140_dist

• Crea con build.sh (legacy):

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

Questi comandi eseguono una build completa, inclusi il kernel e il modulo fips140.ko con i contenuti del digest HMAC-SHA256 incorporati.

Indicazioni per l'utente finale

Indicazioni per il responsabile delle criptovalute

Per utilizzare il modulo del kernel, il sistema operativo deve essere limitato a una singola modalità operativa. Questa operazione viene gestita automaticamente da Android utilizzando l'hardware di gestione della memoria nel processore.

Il modulo del kernel non può essere installato separatamente; è incluso nel firmware del dispositivo e viene caricato automaticamente all'avvio. Funziona solo in una modalità di funzionamento approvata.

Il Crypto Officer può far eseguire gli autotest in qualsiasi momento riavviando il dispositivo.

Indicazioni per l'utente

L'utente del modulo del kernel sono altri componenti del kernel che devono utilizzare algoritmi crittografici. Il modulo del kernel non fornisce logica aggiuntiva nell'utilizzo degli algoritmi e non memorizza parametri oltre il tempo necessario per eseguire un'operazione di crittografia.

L'utilizzo degli algoritmi ai fini della conformità FIPS è limitato agli algoritmi approvati. Per soddisfare il requisito dell'"indicatore di servizio" FIPS 140-3, il modulo fornisce una funzione fips140_is_approved_service che indica se un algoritmo è approvato.

Errori di autotest

In caso di esito negativo dell'autotest, il modulo del kernel causa un errore irreversibile del kernel e il dispositivo non continua l'avvio. Se il riavvio del dispositivo non risolve il problema, il dispositivo deve essere avviato in modalità di ripristino per correggere il problema tramite il reflashing.