Der GKI-Kernel enthält ein
Linux-Kernelmodul namens fips140.ko, das den
Anforderungen nach FIPS 140-3
für kryptografische Softwaremodule. Dieses Modul kann für FIPS eingereicht werden
wenn das Produkt, auf dem der GKI-Kernel ausgeführt wird, dies erfordert.
Insbesondere die folgenden Anforderungen gemäß FIPS 140-3 müssen erfüllt sein, bevor Krypto-Routinen können verwendet werden:
- Das Modul muss seine eigene Integrität prüfen, bevor es kryptografische Algorithmen erstellt verfügbar.
- Das Modul muss seine genehmigten kryptografischen Algorithmen trainieren und verifizieren. mit Selbsttests bekannter Antworten, bevor sie verfügbar sind.
Warum ein separates Kernelmodul?
Die Validierung nach FIPS 140-3 basiert auf der Idee, dass, sobald eine Software oder Hardware zertifiziert wurde, ändert sich nichts. Wenn sie geändert wird, neu zertifiziert werden. Dies entspricht nicht ohne Weiteres den Softwareentwicklungsprozessen in verwendet werden. Aufgrund dieser Anforderung werden FIPS-Softwaremodule ist im Allgemeinen so konzipiert, dass sie sich genauso genau auf die kryptografischen Komponenten konzentrieren damit Änderungen, die nicht mit der Kryptografie zusammenhängen, eine Neubewertung der Kryptografie.
Der GKI-Kernel sollte während der gesamten unterstützten Lebenserwartung. Dadurch ist es nicht möglich, dass sich der gesamte Kernel innerhalb der FIPS befindet. Modulgrenze, sodass ein solches Modul bei jedem Kernel neu zertifiziert werden muss. aktualisieren. „FIPS-Modul“ definieren Teil des Kernel-Images zu sein, dieses Problem zu beseitigen, es aber nicht lösen zu können, da der Binärinhalt der „FIPS-Modul“ immer noch viel häufiger als nötig ändern.
Vor der Kernel-Version 6.1 war eine weitere Überlegung, dass GKI mit LTO (Link Time Optimization) muss aktiviert sein, da LTO eine Voraussetzung für die Kontrollgruppe war. Ablaufintegrität, die ein wichtiges Sicherheitsfeature ist.
Daher wird der gesamte Code, der von den FIPS 140-3-Anforderungen abgedeckt wird, in ein Paket mit
separaten Kernelmodul fips140.ko, das ausschließlich auf
Schnittstellen, die von der GKI-Kernelquelle offengelegt werden, aus der er erstellt wurde. Dieses
sorgt dafür, dass das Modul mit verschiedenen GKI-Releases derselben
und darf nur aktualisiert und noch einmal zur Zertifizierung eingereicht werden.
ob Probleme im Code behoben wurden, der vom Modul selbst unterstützt wird.
Wann sollte das Modul verwendet werden?
Der GKI-Kernel selbst überträgt Code, der von den Kryptoroutinen abhängt, die auch im FIPS 140-3-Kernelmodul verpackt. Die integrierte Kryptowährung Routinen werden nicht tatsächlich aus dem GKI-Kernel verschoben, sondern in des Moduls. Wenn das Modul geladen wird, werden die integrierten Kryptoroutinen von der Linux CryptoAPI abgemeldet und durch die im -Modul.
Das bedeutet, dass das Modul fips140.ko vollständig optional ist und nur
wenn eine FIPS 140-3-Zertifizierung
erforderlich ist. Darüber hinaus
bietet das Modul keine zusätzlichen Funktionen.
wirkt sich wahrscheinlich nur auf die Startzeit aus, ohne dass ein Vorteil entsteht.
So stellen Sie das Modul bereit
Das Modul kann mithilfe der folgenden Schritte in den Android-Build eingebunden werden:
- Fügen Sie den Modulnamen zu
BOARD_VENDOR_RAMDISK_KERNEL_MODULEShinzu. Dies führt dazu, dass die das auf die anbieter-ramdisk kopiert wird. - Fügen Sie den Modulnamen zu
BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOADhinzu. Dieses führt dazu, dass der Modulname zumodules.loadauf dem Ziel hinzugefügt wird.modules.loadenthält die Liste der Module, die voninitgeladen werden, wenn der das Gerät startet.
Selbstprüfung der Integrität
Das FIPS 140-3-Kernelmodul übernimmt den HMAC-SHA256-Digest seines eigenen .code
und .rodata bei der Modulladezeit und vergleicht ihn
die im Modul aufgezeichnet wurden. Dies erfolgt, nachdem das Linux-Modulladeprogramm
die gewohnten Änderungen vorgenommen haben,
z. B. die ELF-Verschiebung und
Alternativen zum Patchen
von CPU-Fehlern in diesen Bereichen. Die folgenden
Es werden zusätzliche Schritte unternommen, damit der Digest
richtig:
- ELF-Verschiebungen werden im Modul beibehalten, damit sie in zur Eingabe des HMAC.
- Das Modul kehrt alle Code-Patches um, die vom Kernel für dynamische Shadow-Call-Stack. Insbesondere ersetzt das Modul alle Anweisungen, Push oder Pop aus dem Shadow-Call-Stack mit dem Pointer-Authentifizierungscode (PAC)-Anweisungen, die ursprünglich vorhanden waren.
- Alle anderen Code-Patches sind für das Modul deaktiviert, einschließlich statischer Schlüssel und also Tracepoints sowie Anbieter-Hooks.
Selbsttests mit bekannten Antworten
Alle implementierten Algorithmen, die unter die FIPS 140-3-Anforderungen fallen, Führen Sie vor der Verwendung einen Selbsttest mit bekannten Antworten durch. Gemäß FIPS 140-3 Implementierungsanleitung 10.3.A Ein einzelner Testvektor pro Algorithmus mit einer der unterstützten Schlüssellängen ist ausreichend für Chiffren, solange sowohl Verschlüsselung als auch Entschlüsselung getestet werden.
Die Linux CryptoAPI hat ein Konzept von Algorithmusprioritäten, bei denen mehrere Implementierungen (z. B. mit speziellen Kryptoanweisungen und einem Fallback) für CPUs, die diese Anweisungen nicht implementieren), kann der gleiche Algorithmus koexistieren. Daher müssen alle Implementierungen derselben Algorithmus. Dies ist erforderlich, da die Linux CryptoAPI die Priorität dass ein Algorithmus mit niedrigerer Priorität ausgewählt.
Im Modul enthaltene Algorithmen
Alle Algorithmen, die im FIPS 140-3-Modul enthalten sind, sind im Folgenden aufgeführt.
Dies gilt für android12-5.10, android13-5.10, android13-5.15,
Die Kernel-Zweige android14-5.15, android14-6.1 und android15-6.6
Unterschiede zwischen den Kernel-Versionen gegebenenfalls vermerkt.
| Algorithmus | Implementierungen | Zuweisbar | Definition |
|---|---|---|---|
aes |
aes-generic, aes-arm64, aes-ce, AES-Bibliothek |
Ja | Einfache AES-Blockverschlüsselung ohne Betriebsmodus: Alle Schlüsselgrößen (128 Bit, 192 Bit und 256 Bit) werden unterstützt. Alle Implementierungen außer der Bibliotheksimplementierung können mit einem Betriebsmodus über eine Vorlage erstellt werden. |
cmac(aes) |
cmac (Vorlage), cmac-aes-neon, cmac-aes-ce |
Ja | AES-CMAC: Alle AES-Schlüsselgrößen werden unterstützt. Die Vorlage cmac kann mit einer beliebigen aes-Implementierung mit cmac(<aes-impl>) erstellt werden. Die anderen Implementierungen sind eigenständige Implementierungen. |
ecb(aes) |
ecb (Vorlage), ecb-aes-neon, ecb-aes-neonbs, ecb-aes-ce |
Ja | AES-ECB: Alle AES-Schlüsselgrößen werden unterstützt. Die Vorlage ecb kann mit einer beliebigen aes-Implementierung mit ecb(<aes-impl>) erstellt werden. Die anderen Implementierungen sind eigenständige Implementierungen. |
cbc(aes) |
cbc (Vorlage), cbc-aes-neon, cbc-aes-neonbs, cbc-aes-ce |
Ja | AES-CBC: Alle AES-Schlüsselgrößen werden unterstützt. Die Vorlage cbc kann mit einer beliebigen aes-Implementierung mit ctr(<aes-impl>) erstellt werden. Die anderen Implementierungen sind eigenständige Implementierungen. |
cts(cbc(aes)) |
cts (Vorlage), cts-cbc-aes-neon, cts-cbc-aes-ce |
Ja | AES-CBC-CTS oder AES-CBC mit Geheimtextdiebstahl: Die verwendete Konvention ist CS3. werden die letzten beiden
Geheimtextblöcke unbedingt vertauscht.Alle AES-Schlüsselgrößen werden unterstützt.Die Vorlage cts kann mit einer beliebigen cbc-Implementierung mit cts(<cbc(aes)-impl>) erstellt werden.Die anderen Implementierungen sind eigenständige Implementierungen. |
ctr(aes) |
ctr (Vorlage), ctr-aes-neon, ctr-aes-neonbs, ctr-aes-ce |
Ja | AES-CTR: Alle AES-Schlüsselgrößen werden unterstützt. Die Vorlage ctr kann mit einer beliebigen aes-Implementierung mit ctr(<aes-impl>) erstellt werden. Die anderen Implementierungen sind eigenständige Implementierungen. |
xts(aes) |
xts (Vorlage), xts-aes-neon, xts-aes-neonbs, xts-aes-ce |
Ja | AES-XTS: Ab Kernel-Version 6.1 werden alle AES-Schlüsselgrößen unterstützt. in Kernel-Version 6.6 und höher werden nur AES-128 und AES-256 unterstützt. Die Vorlage xts kann mit einer beliebigen ecb(aes)-Implementierung mit xts(<ecb(aes)-impl>) erstellt werden. Die anderen Implementierungen sind eigenständige Implementierungen. Bei allen Implementierungen wird die von FIPS geforderte schwache Schlüsselprüfung implementiert. d. h. XTS-Schlüssel, deren erste und zweite Hälfte identisch sind, werden abgelehnt. |
gcm(aes) |
gcm (Vorlage), gcm-aes-ce |
Nein1 | AES-GCM: Alle AES-Schlüsselgrößen werden unterstützt. Es werden nur 96-Bit-IVs unterstützt. Wie bei allen anderen AES-Modi in diesem Modul ist der Aufrufer für die Bereitstellung der IVs verantwortlich. Die Vorlage gcm kann mit einer beliebigen Implementierung von ctr(aes) und ghash mithilfe von gcm_base(<ctr(aes)-impl>,<ghash-impl>) erstellt werden. Die anderen Implementierungen sind eigenständige Implementierungen. |
sha1 |
sha1-generic, sha1-ce |
Ja | SHA-1-kryptografische Hash-Funktion |
sha224 |
sha224-generic, sha224-arm64, sha224-ce |
Ja | SHA-224-Kryptografie-Hash-Funktion: Der Code wird an SHA-256 weitergegeben. |
sha256 |
sha256-generic, sha256-arm64, sha256-ce, SHA-256-Bibliothek |
Ja | SHA-256-Kryptografische Hash-Funktion: Zusätzlich zur herkömmlichen CryptoAPI-Schnittstelle wird für SHA-256 eine Bibliotheksschnittstelle bereitgestellt. Diese Bibliotheksoberfläche verwendet eine andere Implementierung. |
sha384 |
sha384-generic, sha384-arm64, sha384-ce |
Ja | SHA-384-Kryptografische Hash-Funktion: Der Code wird an SHA-512 weitergegeben. |
sha512 |
sha512-generic, sha512-arm64, sha512-ce |
Ja | SHA-512-kryptografische Hash-Funktion |
sha3-224 |
sha3-224-generic |
Ja | SHA3-224-kryptografische Hash-Funktion. Nur ab Kernel-Version 6.6 vorhanden. |
sha3-256 |
sha3-256-generic |
Ja | Wie oben, aber mit einer Digest-Länge von 256 Bit (SHA3-256). Für alle Digest-Längen wird dieselbe Keccak-Implementierung verwendet. |
sha3-384 |
sha3-384-generic |
Ja | Wie oben, aber mit einer Digest-Länge von 384 Bit (SHA3-384). Für alle Digest-Längen wird dieselbe Keccak-Implementierung verwendet. |
sha3-512 |
sha3-512-generic |
Ja | Wie oben, aber mit 512-Bit-Digest-Länge (SHA3-512). Für alle Digest-Längen wird dieselbe Keccak-Implementierung verwendet. |
hmac |
hmac (Vorlage) |
Ja | HMAC (Keyed-Hash Message Authentication Code, Schlüssel-Hash-Nachrichtenauthentifizierungscode): Die Vorlage hmac kann mit einem beliebigen SHA-Algorithmus oder einer SHA-Implementierung mit hmac(<sha-alg>) oder hmac(<sha-impl>) erstellt werden. |
stdrng |
drbg_pr_hmac_sha1, drbg_pr_hmac_sha256, drbg_pr_hmac_sha384, drbg_pr_hmac_sha512 |
Ja | HMAC_DRBG wird mit der benannten Hash-Funktion instanziiert und die Vorhersageresistenz aktiviert. Systemdiagnosen sind enthalten. Nutzer dieser Schnittstelle erhalten ihre eigenen DRBG-Instanzen. |
stdrng |
drbg_nopr_hmac_sha1, drbg_nopr_hmac_sha256, drbg_nopr_hmac_sha384, drbg_nopr_hmac_sha512 |
Ja | Wie die drbg_pr_*-Algorithmen, aber mit deaktivierter Vorhersageresistenz. Der Code wird an die vorhersageresistente Variante weitergegeben. In Kernel-Version 5.10 ist drbg_nopr_hmac_sha256 der DRBG mit der höchsten Priorität. Ab Kernel-Version 5.15 ist dies drbg_pr_hmac_sha512. |
jitterentropy_rng |
jitterentropy_rng |
Nein | Jitter-RNG, entweder Version 2.2.0 (Kernel-Version 6.1 und niedriger) oder Version 3.4.0 (Kernel-Version 6.6 und höher). Nutzer dieser Schnittstelle erhalten ihre eigenen Jitter-RNG-Instanzen. Die von den DRBGs verwendeten Instanzen werden nicht wiederverwendet. |
xcbc(aes) |
xcbc-aes-neon, xcbc-aes-ce |
Nein | |
xctr(aes) |
xctr-aes-neon, xctr-aes-ce |
Nein | Nur ab Kernel-Version 5.15 vorhanden. |
cbcmac(aes) |
cbcmac-aes-neon, cbcmac-aes-ce |
Nein | |
essiv(cbc(aes),sha256) |
essiv-cbc-aes-sha256-neon, essiv-cbc-aes-sha256-ce |
Nein |
Modul aus Quelle erstellen
Für Android 14 und höher (einschließlich
android-mainline), erstellen Sie das Modul fips140.ko aus der Quelle mit der
folgenden Befehle.
Erstellen Sie mit Bazel:
tools/bazel run //common:fips140_distMit
build.sherstellen (alt):BUILD_CONFIG=common/build.config.gki.aarch64.fips140 build/build.sh
Diese Befehle führen einen vollständigen Build einschließlich des Kernels und der fips140.ko aus
mit dem eingebetteten HMAC-SHA256-Digest-Inhalt.
Anleitung für Endnutzer
Anleitung für Crypto Officers
Für den Betrieb des Kernelmoduls muss das Betriebssystem auf eine Einzeloperatormodus verwenden. Das wird von Android automatisch erledigt mit Speicherverwaltungshardware im Prozessor.
Das Kernelmodul kann nicht separat installiert werden. als Teil des Firmware des Geräts und wird beim Booten automatisch geladen. Sie funktioniert nur in einem genehmigter Betriebsmodus.
Der Crypto Officer kann die Selbsttests jederzeit durch einen Neustart ausführen, auf dem Gerät.
Anleitung für Nutzer
Bei dem Nutzer des Kernel-Moduls handelt es sich um andere Kernel-Komponenten, die kryptografischer Algorithmen. Das Kernelmodul bietet keine zusätzliche Logik in der Algorithmen genutzt und speichert keine Parameter außerhalb des Zeitraums die für einen kryptografischen Vorgang erforderlich sind.
Die Verwendung der Algorithmen zum Zweck der FIPS-Konformität ist auf genehmigte
Algorithmen. Um den „Service Indicator“ gemäß FIPS 140-3 zu erfüllen Anforderung, die
Modul stellt eine fips140_is_approved_service-Funktion bereit, die angibt,
genehmigt wurde.
Fehler beim automatischen Test
Im Falle eines Selbsttestfehlers veranlasst das Kernelmodul den Kernel, das Gerät nicht mehr hochfährt. Wenn ein Neustart des Geräts nicht behebt, muss das Gerät im Wiederherstellungsmodus starten, damit der Fehler Problem durch erneutes Flash des Geräts.
-
Es wird erwartet, dass die AES-GCM-Implementierungen des Moduls vom Typ "Algorithmus genehmigt" aber nicht „Modul genehmigt“. Sie können validiert werden, aber AES-GCM aus Sicht des FIPS-Moduls nicht als genehmigter Algorithmus angesehen werden kann. Das liegt daran, dass die FIPS-Modulanforderungen für GCM nicht mit GCM-Implementierungen, die keine eigenen IVs generieren.↩