Nach FIPS 140-3 zertifiziertes GKI-Kryptomodul

Der GKI-Kernel enthält ein Linux-Kernelmodul namens fips140.ko, das den Anforderungen von FIPS 140-3 für kryptografische Softwaremodule entspricht. Dieses Modul kann für die FIPS-Zertifizierung eingereicht werden, wenn das Produkt, das den GKI-Kernel ausführt, dies erfordert.

Insbesondere müssen die folgenden FIPS 140-3-Anforderungen erfüllt sein, bevor die Krypto-Routinen verwendet werden können:

• Das Modul muss seine eigene Integrität prüfen, bevor kryptografische Algorithmen zur Verfügung gestellt werden.
• Das Modul muss seine genehmigten kryptografischen Algorithmen mithilfe von Selbsttests mit bekannten Antworten testen und prüfen, bevor sie verfügbar gemacht werden.

Warum ein separates Kernelmodul

Die Validierung gemäß FIPS 140-3 basiert auf der Idee, dass ein Software- oder Hardwaremodul nach der Zertifizierung nie geändert wird. Andernfalls muss es noch einmal zertifiziert werden. Dies entspricht nicht den derzeit verwendeten Softwareentwicklungsprozessen. Aufgrund dieser Anforderung sind FIPS-Softwaremodule in der Regel so konzipiert, dass sie sich so eng wie möglich auf die kryptografischen Komponenten konzentrieren, damit Änderungen, die nicht mit der Kryptografie zusammenhängen, keine Neubewertung der Kryptografie erfordern.

Der GKI-Kernel soll während der gesamten unterstützten Lebensdauer regelmäßig aktualisiert werden. Dadurch ist es nicht möglich, dass sich der gesamte Kernel innerhalb der FIPS-Modulgrenze befindet, sodass ein solches Modul bei jeder Kernel-Aktualisierung neu zertifiziert werden muss. Wenn das „FIPS-Modul“ als Teil des Kernel-Images definiert wird, wird dieses Problem zwar gemildert, aber nicht behoben, da sich der Binärinhalt des „FIPS-Moduls“ immer noch viel häufiger als nötig ändern würde.

Vor der Kernelversion 6.1 war ein weiterer Aspekt, dass GKI mit aktivierter LTO (Link Time Optimization) kompiliert wurde, da LTO eine Voraussetzung für die Control Flow Integrity ist, eine wichtige Sicherheitsfunktion.

Daher wird der gesamte Code, der den FIPS 140-3-Anforderungen unterliegt, in einem separaten Kernelmodul fips140.ko verpackt, das nur auf stabilen Schnittstellen basiert, die von der GKI-Kernelquelle bereitgestellt werden, aus der es erstellt wurde. Das bedeutet, dass das Modul mit verschiedenen GKI-Releases derselben Generation verwendet werden kann und nur aktualisiert und zur Zertifizierung noch einmal eingereicht werden muss, wenn Probleme im Code behoben wurden, der sich im Modul selbst befindet.

Wann sollte das Modul verwendet werden?

Der GKI-Kernel selbst enthält Code, der von den Krypto-Routinen abhängt, die auch im FIPS 140-3-Kernelmodul enthalten sind. Daher werden die integrierten Kryptoroutinen nicht tatsächlich aus dem GKI-Kernel verschoben, sondern in das Modul kopiert. Wenn das Modul geladen wird, werden die integrierten Krypto-Routinen von der Linux CryptoAPI abgemeldet und durch die vom Modul bereitgestellten ersetzt.

Das fips140.ko-Modul ist also völlig optional und sollte nur bereitgestellt werden, wenn die FIPS 140-3-Zertifizierung erforderlich ist. Außerdem bietet das Modul keine zusätzlichen Funktionen. Wenn es unnötig geladen wird, wirkt sich das wahrscheinlich nur auf die Bootzeit aus, ohne einen Vorteil zu bieten.

Modul bereitstellen

Das Modul kann mit den folgenden Schritten in den Android-Build eingefügt werden:

• Fügen Sie den Modulnamen zu BOARD_VENDOR_RAMDISK_KERNEL_MODULES hinzu. Dadurch wird das Modul auf die Anbieter-RAMdisk kopiert.
• Fügen Sie BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD den Namen des Moduls hinzu. Dadurch wird der Modulname modules.load im Ziel hinzugefügt. modules.load enthält die Liste der Module, die von init beim Starten des Geräts geladen werden.

Selbstprüfung der Integrität

Das FIPS 140-3-Kernelmodul nimmt beim Laden des Moduls den HMAC-SHA256-Digest seiner eigenen .code- und .rodata-Abschnitte und vergleicht ihn mit dem im Modul aufgezeichneten Digest. Dies erfolgt, nachdem das Linux-Modulladeprogramm bereits die üblichen Änderungen wie die ELF-Neuzuweisungsverarbeitung und alternatives Patchen für CPU-Fehler in diesen Abschnitten vorgenommen hat. Die folgenden zusätzlichen Schritte werden ausgeführt, damit der Digest korrekt reproduziert werden kann:

• ELF-Verschiebungen bleiben im Modul erhalten, damit sie in umgekehrter Reihenfolge auf die Eingabe des HMAC angewendet werden können.
• Das Modul kehrt alle Code-Patches um, die vom Kernel für den Dynamic Shadow Call Stack erstellt wurden. Insbesondere ersetzt das Modul alle Anweisungen, die vom Schatten-Callstack auf den Stack schieben oder vom Stack poppen, durch die ursprünglich vorhandenen Pointer Authentication Code-Anweisungen (PAC).
• Alle anderen Code-Patching sind für das Modul deaktiviert, einschließlich statischer Schlüssel und daher Tracepoints sowie Anbieter-Hooks.

Selbsttests mit bekannten Antworten

Alle implementierten Algorithmen, die durch die FIPS 140-3-Anforderungen abgedeckt sind, müssen vor ihrer Verwendung einen Selbsttest mit bekannten Antworten durchführen. Gemäß der FIPS 140-3-Implementierungsanleitung 10.3.A ist für Chiffren ein einzelner Testvektor pro Algorithmus mit einer beliebigen der unterstützten Schlüssellängen ausreichend, solange sowohl Verschlüsselung als auch Entschlüsselung getestet werden.

Die Linux CryptoAPI kennt Algorithmusprioritäten, bei denen mehrere Implementierungen (z. B. eine mit speziellen Kryptoanweisungen und ein Fallback für CPUs, die diese Anweisungen nicht implementieren) desselben Algorithmus nebeneinander existieren können. Daher müssen alle Implementierungen desselben Algorithmus getestet werden. Das ist notwendig, da die Linux CryptoAPI die prioritätsbasierte Auswahl umgehen und stattdessen einen Algorithmus mit niedrigerer Priorität auswählen lässt.

Im Modul enthaltene Algorithmen

Alle Algorithmen, die im FIPS 140-3-Modul enthalten sind, sind nachfolgend aufgeführt. Dies gilt für die Kernel-Branches android12-5.10, android13-5.10, android13-5.15, android14-5.15, android14-6.1 und android15-6.6. Unterschiede zwischen den Kernelversionen werden gegebenenfalls vermerkt.

Algorithmus	Implementierungen	Genehmigungsfähig	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 über eine Vorlage mit einem Betriebsmodus kombiniert werden.
cmac(aes)	cmac (Vorlage), cmac-aes-neon, cmac-aes-ce	Ja	AES-CMAC: Alle AES-Schlüsselgrößen werden unterstützt. Die cmac-Vorlage kann mit jeder Implementierung von aes mithilfe von 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 ecb-Vorlage kann mit jeder Implementierung von aes mithilfe von 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ändig.
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. Die letzten beiden Geheimtextblöcke werden bedingungslos ausgetauscht. 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ändig.
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 ctr-Vorlage kann mit jeder Implementierung von aes mithilfe von ctr(<aes-impl>) erstellt werden. Die anderen Implementierungen sind eigenständig.
xts(aes)	xts (Vorlage), xts-aes-neon, xts-aes-neonbs, xts-aes-ce	Ja	AES-XTS: In der Kernelversion 6.1 und niedriger werden alle AES-Schlüsselgrößen unterstützt. In der Kernelversion 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. Alle Implementierungen implementieren die von FIPS geforderte Prüfung auf schwache Schlüssel. Das bedeutet, dass XTS-Schlüssel, deren erste und zweite Hälfte gleich sind, abgelehnt werden.
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ändig.
sha1	sha1-generic, sha1-ce	Ja	Kryptografische SHA-1-Hash-Funktion
sha224	sha224-generic, sha224-arm64, sha224-ce	Ja	Kryptografische Hash-Funktion SHA-224: Der Code wird mit SHA-256 geteilt.
sha256	sha256-generic, sha256-arm64, sha256-ce, SHA-256-Bibliothek	Ja	Kryptografische SHA-256-Hash-Funktion: Zusätzlich zur standardmäßigen CryptoAPI-Schnittstelle wird für SHA-256 eine Bibliotheksschnittstelle bereitgestellt. Diese Bibliothek-Schnittstelle verwendet eine andere Implementierung.
sha384	sha384-generic, sha384-arm64, sha384-ce	Ja	Kryptografische Hash-Funktion SHA-384: Der Code wird mit SHA-512 geteilt.
sha512	sha512-generic, sha512-arm64, sha512-ce	Ja	SHA-512-kryptografische Hash-Funktion
sha3-224	sha3-224-generic	Ja	Kryptografische Hash-Funktion SHA3-224. Nur in Kernelversion 6.6 und höher vorhanden.
sha3-256	sha3-256-generic	Ja	Wie zuvor, aber mit einer Digest-Länge von 256 Bit (SHA3-256). Für alle Digestlängen wird dieselbe Keccak-Implementierung verwendet.
sha3-384	sha3-384-generic	Ja	Wie zuvor, aber mit einer Digestlänge von 384 Bit (SHA3-384). Für alle Digestlä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 Digestlängen wird dieselbe Keccak-Implementierung verwendet.
hmac	hmac (Vorlage)	Ja	HMAC (Keyed-Hash Message Authentication Code): Die hmac-Vorlage kann mit jedem SHA-Algorithmus oder jeder 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 Benutzeroberfläche erhalten eigene 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 für die variante verwendet, die nicht durch Vorhersagen beeinflusst wird. 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 in Kernelversion 5.15 und höher 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 Quellcode erstellen

Für Android 14 und höher (einschließlich android-mainline) erstellen Sie das fips140.ko-Modul mit den folgenden Befehlen aus der Quelle.

• Mit Bazel erstellen:

  tools/bazel run //common:fips140_dist

• Mit build.sh (alt) erstellen:

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

Diese Befehle führen einen vollständigen Build aus, einschließlich des Kernels und des fips140.ko-Moduls mit dem eingebetteten HMAC-SHA256-Digest-Inhalt.

Hinweise für Endnutzer

Anleitung für Crypto Officers

Zum Betrieb des Kernel-Moduls muss das Betriebssystem auf einen einzelnen Betriebsmodus beschränkt werden. Dies wird von Android automatisch mithilfe der Speicherverwaltungshardware im Prozessor verwaltet.

Das Kernelmodul kann nicht separat installiert werden. Es ist Teil der Gerätefirmware und wird beim Starten automatisch geladen. Sie wird nur in einem genehmigten Betriebsmodus betrieben.

Der Krypto-Sicherheitsbeauftragte kann die Selbsttests jederzeit durch einen Neustart des Geräts ausführen lassen.

Anleitung für Nutzer

Nutzer des Kernelmoduls sind andere Kernelkomponenten, die kryptografische Algorithmen verwenden müssen. Das Kernelmodul bietet bei der Verwendung der Algorithmen keine zusätzliche Logik und speichert keine Parameter über die für die Durchführung eines kryptografischen Vorgangs erforderliche Zeit hinaus.

Die Verwendung der Algorithmen zum Zweck der FIPS-Compliance ist auf zugelassene Algorithmen beschränkt. Um die FIPS 140-3-Anforderung an den „Dienstindikator“ zu erfüllen, stellt das Modul die Funktion fips140_is_approved_service bereit, die angibt, ob ein Algorithmus genehmigt ist.

Fehler beim automatischen Test

Bei einem Fehler beim Selbsttest führt das Kernel-Modul dazu, dass der Kernel in den Notfallmodus wechselt und das Gerät nicht weiter hochfährt. Wenn das Problem durch einen Neustart des Geräts nicht behoben wird, muss es im Wiederherstellungsmodus gestartet werden, um das Problem durch einen Neu-Flash des Geräts zu beheben.