Modulo crittografico GKI certificabile FIPS 140-3

Il kernel GKI include un modulo del kernel Linux denominato fips140.ko che è 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.

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

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

Perché un modulo kernel separato

La convalida FIPS 140-3 si basa sull'idea che, una volta certificato, un modulo basato su hardware o software non viene mai modificato. Se viene modificata, deve essere nuovamente certificata. Questo non corrisponde immediatamente ai processi di sviluppo software attualmente in uso e, a causa di questo requisito, i moduli software FIPS sono generalmente progettati per essere il più possibile incentrati sui componenti crittografici, in modo da garantire che le modifiche non correlate alla crittografia non richiedano una rivalutazione della crittografia.

Il kernel GKI deve essere aggiornato regolarmente durante l'intero ciclo di vita supportato. Ciò rende non fattibile che l'intero kernel rientri nel confine del modulo FIPS, poiché un modulo di questo tipo dovrebbe essere sottoposto a nuova certificazione a ogni aggiornamento del kernel. Definire il "modulo FIPS" come un sottoinsieme dell'immagine del kernel attenuarebbe questo problema, ma non lo risolverebbe, poiché i contenuti binari del "modulo FIPS" cambierebbero comunque molto più di frequente del necessario.

Prima della versione del kernel 6.1, un'altra considerazione era che GKI veniva compilato con l'LTO (Link Time Optimization) abilitato, poiché l'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 viene pacchettizzato in un modulo del kernel separato fips140.ko che si basa solo su interfacce stabili esposte dal codice sorgente del kernel GKI da cui è stato compilato. Ciò significa che il modulo può essere utilizzato con release GKI diverse della stessa generazione e che deve essere aggiornato e inviato nuovamente per la certificazione solo se sono stati corretti eventuali problemi nel codice del modulo stesso.

Quando utilizzare il modulo

Il kernel GKI stesso contiene codice che dipende dalle routine di crittografia che sono anche pacchettizzate nel modulo del kernel FIPS 140-3. Pertanto, le routine di crittografia predefinite non vengono rimosse dal kernel GKI, ma vengono copiate nel modulo. Quando il modulo viene caricato, le routine di crittografia integrate vengono ritirate da CryptoAPI di Linux e sostituite da quelle del modulo.

Ciò significa che il modulo fips140.ko è completamente facoltativo e ha senso implementarlo solo se la certificazione FIPS 140-3 è un requisito. Oltre a questo, il modulo non offre funzionalità aggiuntive e il suo caricamento non necessario potrebbe influire solo sul tempo di avvio, senza 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. Il modulo viene quindi copiato nella 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 nel target. modules.load contiene l'elenco dei moduli caricati da init all'avvio del dispositivo.

Il controllo di integrità automatico

Il modulo del kernel FIPS 140-3 prende il digest HMAC-SHA256 delle proprie sezioni .code e .rodata al momento del caricamento del modulo e lo confronta con il digest registrato nel modulo. Questo avviene dopo che il caricatore di moduli Linux ha già apportato le modifiche consuete, come l'elaborazione del ricollegamento ELF e le patch di alternative per gli errori 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 modo inverso all'input dell'HMAC.
• Il modulo annulla eventuali patch di codice apportate dal kernel per lo stack di chiamate dinamico ombra. Nello specifico, il modulo sostituisce tutte le istruzioni che push o pop dallo stack di chiamate shadow con le istruzioni del codice di autenticazione del puntatore (PAC) presenti inizialmente.
• Tutte le altre patch di codice sono disattivate per il modulo, incluse le chiavi statiche e quindi i tracepoint, nonché gli hook del fornitore.

I test di autodiagnosi con risposta nota

Eventuali algoritmi implementati coperti dai requisiti FIPS 140-3 devono eseguire un autotest con risposta nota prima di essere utilizzati. In base alle Indicazioni per l'implementazione FIPS 140-3 10.3.A, un singolo vettore di test per algoritmo che utilizza una delle lunghezze della chiave supportate è sufficiente per le chiavi, a condizione che vengano testati sia la crittografia sia la decrittografia.

CryptoAPI di Linux ha un concetto di priorità dell'algoritmo, in cui possono coesistere diverse implementazioni (ad esempio una che utilizza istruzioni di crittografia speciali e una di riserva per le CPU che non implementano queste istruzioni) dello stesso algoritmo. Di conseguenza, è necessario testare tutte le implementazioni dello stesso algoritmo. Questo è necessario perché CryptoAPI di Linux consente di aggirare la selezione in base alla 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. Questo 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 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 crittografia: la convenzione utilizzata è CS3; i due blocchi di crittografia finali vengono scambiati incondizionatamente. 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, è compito dell'utente chiamante fornire gli IV. Il modello gcm può essere composto con 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 di hash crittografica SHA-224: il codice è condiviso con SHA-256.
sha256	sha256-generic, sha256-arm64, sha256-ce, libreria SHA-256	Sì	Funzione di hash crittografica SHA-256: oltre all'interfaccia CryptoAPI standard, è fornita un'interfaccia della libreria per 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 di hash crittografica SHA-512
sha3-224	sha3-224-generic	Sì	Funzione di hash crittografica SHA3-224. Presente solo nella versione del kernel 6.6 e successive.
sha3-256	sha3-256-generic	Sì	Come sopra, ma con una 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ì	Uguale al precedente, ma con una 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 sopra, ma con una 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 con nome 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ì	Gli stessi algoritmi di drbg_pr_*, ma con la resistenza alla previsione disattivata. Il codice viene condiviso con la variante resistente alle previsioni. Nella versione del kernel 5.10, la 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

Compila il modulo dal codice sorgente

Per Android 14 e versioni successive (inclusoandroid-mainline), compila il modulo fips140.ko dal codice sorgente utilizzando i seguenti comandi.

• Crea 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 compilazione completa che include il kernel e il fips140.ko modulo con i contenuti del digest HMAC-SHA256 incorporati.

Guida per gli utenti finali

Guida per gli addetti alla criptovaluta

Per utilizzare il modulo del kernel, il sistema operativo deve essere limitato a una modalità di funzionamento con un solo operatore. 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 caricato automaticamente all'avvio. Funziona solo in una modalità di funzionamento approvata.

L'addetto alla crittografia può eseguire i test di autodiagnosi 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 criptografici. Il modulo del kernel non fornisce logica aggiuntiva per l'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 diagnostica automatica

In caso di errore di autotest, il modulo del kernel provoca un panico del kernel e il dispositivo non continua l'avvio. Se il riavvio del dispositivo non risolve il problema, è necessario avviarlo in modalità di ripristino per correggerlo eseguendo il riflash del dispositivo.