Il kernel GKI include una
modulo kernel Linux chiamato fips140.ko
conforme a
Requisiti FIPS 140-3
per i moduli software crittografici. Questo modulo può essere inviato per FIPS
se richiesto dal prodotto che esegue il kernel GKI.
I seguenti requisiti FIPS 140-3 in particolare devono essere soddisfatti prima le criptovalute possono essere usate:
- Il modulo deve verificare la propria integrità prima di creare algoritmi crittografici disponibili.
- Il modulo deve esercitarsi e verificare gli 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 che un software non è mai stato modificato. Se modificata, deve essere viene rinnovata. Non corrisponde immediatamente ai processi di sviluppo software utilizzare oggi. Di conseguenza, i moduli software FIPS vengono progettata per essere incentrata sui componenti crittografici, possibile, per garantire che le modifiche non correlate alla crittografia non richiedono una rivalutazione della crittografia.
Il kernel GKI è pensato per essere aggiornato regolarmente durante l'intero processo e la durata del ciclo di vita. Questo rende impossibile che l'intero kernel si trovi all'interno del file FIPS del modulo, per cui un modulo di questo tipo deve essere ricertificato a ogni kernel aggiornamento. Definizione del "modulo FIPS" un sottoinsieme dell'immagine kernel a mitigare il problema, ma non lo risolverebbe, poiché i contenuti binari "Modulo FIPS" cambierà comunque molto più spesso del necessario.
Prima della versione del kernel 6.1, un'altra considerazione era che GKI era compilato LTO (ottimizzazione del tempo di collegamento) attivato, in quanto LTO era un prerequisito del controllo Integrità del flusso, che è una funzionalità di sicurezza importante.
Pertanto, tutto il codice coperto dai requisiti FIPS 140-3 viene pacchettizzato
in un modulo kernel separato fips140.ko
che si basa solo su
interfacce esposte dal sorgente del kernel GKI da cui è stato creato. Questo
significa che il modulo può essere utilizzato con diverse release GKI dello stesso
e deve essere aggiornata e inviata nuovamente solo per la certificazione
se ci sono problemi risolti nel codice gestito dal modulo stesso.
Quando utilizzare il modulo
Lo stesso kernel GKI trasporta codice che dipende dalle routine crittografiche che sono è anche pacchettizzato nel modulo kernel FIPS 140-3. Pertanto, la crittografia integrata le routine non vengono effettivamente spostate fuori dal kernel GKI, ma piuttosto copiate nel modulo. Quando il modulo viene caricato, le routine di crittografia integrate vengono la registrazione in Linux CryptoAPI e sostituita da quelle trasferite dalla in maggior dettaglio più avanti in questo modulo.
Ciò significa che il modulo fips140.ko
è del tutto facoltativo e rende
ha senso implementarla se è richiesta la certificazione FIPS 140-3. A parte questo,
il modulo non fornisce funzionalità aggiuntive e se lo carichi inutilmente
influiranno solo sui tempi di avvio, senza offrire alcun vantaggio.
Come eseguire il deployment del modulo
Il modulo può essere incorporato nella build Android seguendo questa procedura:
- Aggiungi il nome del modulo a
BOARD_VENDOR_RAMDISK_KERNEL_MODULES
. Questo fa sì che da copiare nel ramdisk del fornitore. - Aggiungi il nome del modulo a
BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD
. Questo fa sì che il nome del modulo venga aggiunto amodules.load
nel target.modules.load
contiene l'elenco dei moduli caricati dainit
quando l'oggetto all'avvio del dispositivo.
Controllo autonomo dell'integrità
Il modulo kernel FIPS 140-3 prende il digest HMAC-SHA256 del proprio .code
e .rodata
sezioni al tempo di caricamento del modulo e le confronta con il digest
registrati nel modulo. Questo avviene dopo che il caricatore di moduli Linux
ha già apportato le solite modifiche, come l'elaborazione del trasferimento ELF e
le patching alternative per gli errori della CPU
in queste sezioni. Le seguenti
vengono eseguiti ulteriori passaggi per garantire
la riproduzione del digest
correttamente:
- I trasferimenti ELF vengono conservati all'interno del modulo in modo che possano essere applicati invertire l'input di HMAC.
- Il modulo inverte qualsiasi patch di codice creata dal kernel per contenuti Stack di chiamate shadow. In particolare, il modulo sostituisce qualsiasi istruzione che esegui il push o pop dallo stack delle chiamate shadow con il codice di autenticazione Pointer (PAC) presenti in origine.
- Tutte le altre patch del codice sono disabilitate per il modulo, incluse le chiavi statiche e ovvero tracepoint e hook dei fornitori.
I test automatici a risposta nota
Tutti gli algoritmi implementati che sono coperti dai requisiti FIPS 140-3 devono eseguire una diagnostica automatica a risposta nota prima di essere utilizzata. In base allo standard FIPS 140-3 Indicazioni per l'implementazione 10.3.A, un singolo vettore di test per algoritmo che utilizza una qualsiasi delle lunghezze della chiave supportate è sufficiente per le crittografie, purché siano testate sia la crittografia che la decrittografia.
La CryptoAPI di Linux ha una nozione di priorità degli algoritmi, in cui diverse (ad esempio, quella che utilizza speciali istruzioni per le criptovalute e una per le CPU che non implementano queste istruzioni) dello stesso algoritmo potrebbe coesistono. È quindi necessario testare tutte le implementazioni dello stesso dell'algoritmo. Questa operazione è necessaria perché la CryptoAPI di Linux dà la priorità basata sull'analisi di dati da eludere e affinché un algoritmo a priorità più bassa venga selezionato.
Algoritmi inclusi nel modulo
Di seguito sono elencati tutti gli algoritmi inclusi nel modulo FIPS 140-3.
Si applica a android12-5.10
, android13-5.10
, android13-5.15
,
Rami del kernel android14-5.15
, android14-6.1
e android15-6.6
, però
le differenze tra le versioni del kernel vengono indicate ove appropriato.
Algoritmo | Implementazioni | Approvabile | Definizione |
---|---|---|---|
aes |
aes-generic , aes-arm64 , aes-ce , libreria AES |
Sì | Crittografia a blocchi AES semplice, senza modalità operativa: sono supportate tutte le dimensioni di chiave (128, 192 e 256 bit). Tutte le implementazioni, diverse dall'implementazione della libreria, possono essere create con una modalità operativa mediante 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 del testo crittografato: la convenzione utilizzata è CS3 ; gli ultimi due blocchi di testo crittografato 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 kernel 6.1 e precedenti, sono supportate tutte le dimensioni delle chiavi AES; nel kernel versione 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 della chiave debole richiesto dal FIPS; cioè le chiavi XTS la cui prima e la seconda metà sono uguali vengono rifiutate. |
gcm(aes) |
gcm (modello), gcm-aes-ce |
N.1 | AES-GCM: sono supportate tutte le dimensioni delle chiavi AES. Sono supportati solo gli 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 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 hash crittografica SHA-1 |
sha224 |
sha224-generic , sha224-arm64 e sha224-ce |
Sì | Funzione hash crittografica SHA-224: il codice viene condiviso con SHA-256. |
sha256 |
sha256-generic , sha256-arm64 , sha256-ce , libreria SHA-256 |
Sì | Funzione hash crittografica SHA-256: a SHA-256 viene fornita un'interfaccia della libreria oltre all'interfaccia CryptoAPI standard. L'interfaccia di questa libreria utilizza un'implementazione diversa. |
sha384 |
sha384-generic , sha384-arm64 e sha384-ce |
Sì | Funzione hash crittografica SHA-384: il codice viene condiviso con l'algoritmo 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 kernel 6.6 e successive. |
sha3-256 |
sha3-256-generic |
Sì | Come la versione precedente, ma con lunghezza digest a 256 bit (SHA3-256). Tutte le lunghezze del digest utilizzano la stessa implementazione Keccak. |
sha3-384 |
sha3-384-generic |
Sì | Come la versione precedente, ma con lunghezza digest a 384 bit (SHA3-384). Tutte le lunghezze del digest utilizzano la stessa implementazione Keccak. |
sha3-512 |
sha3-512-generic |
Sì | Come la versione precedente, ma con lunghezza digest a 512 bit (SHA3-512). Tutte le lunghezze del digest utilizzano la stessa implementazione 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ì | Istanza HMAC_DRBG creata con la funzione hash denominata e con resistenza alle previsioni abilitata: sono inclusi i controlli di integrità. Gli utenti di questa interfaccia ricevono le proprie istanze DRBG. |
stdrng |
drbg_nopr_hmac_sha1 , drbg_nopr_hmac_sha256 , drbg_nopr_hmac_sha384 , drbg_nopr_hmac_sha512 |
Sì | Come gli algoritmi di drbg_pr_* , ma con la resistenza alle previsioni disabilitata. Il codice viene condiviso con la variante resistente alle previsioni. Nella versione del kernel 5.10, il DRBG a priorità massima è 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 versioni precedenti) o versione 3.4.0 (kernel versione 6.6 e successive). Gli utenti di questa interfaccia ricevono le proprie istanze Jitter RNG. Non riutilizzano le istanze usate 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 dall'origine
Per Android 14 e versioni successive (incluse
android-mainline
), crea il modulo fips140.ko
dal codice sorgente utilizzando
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 build completa che include il kernel e l'fips140.ko
con i contenuti del digest HMAC-SHA256 incorporati.
Indicazioni per l'utente finale
Indicazioni per l'ufficiale di crittografia
Per utilizzare il modulo kernel, il sistema operativo deve essere limitato a una con un singolo operatore. Questa operazione viene gestita automaticamente da Android utilizzando hardware di gestione della memoria nel processore.
Il modulo kernel non può essere installato separatamente; è incluso nel firmware del dispositivo e viene caricato automaticamente all'avvio. Funziona solo una modalità operativa approvata.
L'ufficiale di crittografia può avviare i test automatici in qualsiasi momento riavviando del dispositivo.
Indicazioni per l'utente
Gli utenti di un modulo kernel sono altri componenti del kernel che devono usare algoritmi crittografici. Il modulo kernel non fornisce logica aggiuntiva l'uso degli algoritmi e non memorizza alcun parametro oltre il tempo necessarie per eseguire un'operazione crittografica.
L'uso degli algoritmi ai fini della conformità FIPS è limitato ai casi
degli algoritmi. Per soddisfare il "indicatore di servizio" FIPS 140-3 requisito, il
fornisce una funzione fips140_is_approved_service
che indica se
viene approvato un algoritmo.
Errori di diagnostica automatica
In caso di errore di autotest, il modulo del kernel fa sì che il kernel panico e il dispositivo non continua ad avviarsi. Se il riavvio del dispositivo non risolva il problema, il dispositivo deve avviarsi in modalità Recovery per correggere problema eseguendo di nuovo il flash del dispositivo.
-
È previsto che le implementazioni AES-GCM del modulo possano essere "algoritmo approvato" ma non con "modulo approvato". Possono essere convalidati, ma AES-GCM non possono essere considerati un algoritmo approvato dal punto di vista dei moduli FIPS. Questo perché i requisiti del modulo FIPS per GCM non sono compatibili con Implementazioni di GCM che non generano IV propri.↩