GKI-Kryptomodul, das gemäß FIPS 140-3 zertifiziert ist

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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 zur FIPS-Zertifizierung eingereicht werden, wenn dies für das Produkt, in dem der GKI-Kernel ausgeführt wird, erforderlich ist.

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 kryptografische Algorithmen verfügbar gemacht werden.
• Das Modul muss seine genehmigten kryptografischen Algorithmen trainieren und verifizieren. mit Selbsttests bekannter Antworten, bevor sie verfügbar sind.

Warum ein separates Kernelmodul?

Die FIPS 140-3-Validierung basiert auf der Annahme, dass ein software- oder hardwarebasiertes Modul nach der Zertifizierung nicht mehr geändert wird. 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 Kryptografie zusammenhängen, eine Neubewertung der Kryptografie.

Der GKI-Kernel soll während der gesamten unterstützten Lebensdauer regelmäßig aktualisiert werden. Daher ist es nicht möglich, dass sich der gesamte Kernel innerhalb der FIPS-Modulgrenze befindet, da ein solches Modul bei jedem Kernel-Update neu zertifiziert werden müsste. 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 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 Kontrolle und Ablaufintegrität, die ein wichtiges Sicherheitsfeature ist.

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.

Einsatzmöglichkeiten für das Modul

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 Krypto-Routinen nicht aus dem GKI-Kernel verschoben, sondern in das Modul kopiert. Wenn das Modul geladen wird, werden die integrierten Kryptoroutinen von der Linux CryptoAPI abgemeldet und durch die im -Modul.

Das fips140.ko-Modul ist also völlig optional und sollte nur bereitgestellt werden, wenn die FIPS 140-3-Zertifizierung erforderlich ist. Darüber hinaus bietet das Modul keine zusätzlichen Funktionen und lädt unnötigerweise, wirkt sich wahrscheinlich nur auf die Startzeit aus, ohne dass ein Vorteil entsteht.

So stellen Sie das Modul bereit

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 in das RAM-Disk des Anbieters kopiert.
• Fügen Sie BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD den Namen des Moduls hinzu. Dieses führt dazu, dass der Modulname zu modules.load auf dem Ziel hinzugefügt wird. modules.load enthält die Liste der Module, die von init geladen werden, wenn der das Gerät startet.

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 geschieht, nachdem der Linux-Modul-Ladeprogramm die üblichen Änderungen wie die ELF-Umsetzung und alternative Patches für CPU-Fehler an diesen Abschnitten vorgenommen hat. 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 macht alle Code-Patches rückgängig, die vom Kernel für den dynamischen Schatten-Stack vorgenommen wurden. 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 damit auch 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 ist ausreichend für Chiffren, 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 derselben Algorithmus. 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	Zuweisbar	Definition
aes	aes-generic, aes-arm64, aes-ce, AES-Bibliothek	Ja	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 Vorlage cmac kann mit einer beliebigen aes-Implementierung mit cmac(<aes-impl>) erstellt werden. Die anderen Implementierungen sind eigenständig.
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ä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ä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 gcm-Vorlage kann mit allen Implementierungen 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	SHA-1-kryptografische Hash-Funktion
sha224	sha224-generic, sha224-arm64, sha224-ce	Ja	SHA-224-Kryptografische Hash-Funktion: Der Code wird an SHA-256 weitergegeben.
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 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	Kryptografische Hash-Funktion SHA-512
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 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 zuvor, aber mit einer Digestlänge von 384 Bit (SHA3-384). Für alle Digest-Längen wird dieselbe Keccak-Implementierung verwendet.
sha3-512	sha3-512-generic	Ja	Wie zuvor, aber mit einer Digestlänge von 512 Bit (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 Schnittstelle erhalten ihre eigenen DRBG-Instanzen.
stdrng	drbg_nopr_hmac_sha1, drbg_nopr_hmac_sha256, drbg_nopr_hmac_sha384, drbg_nopr_hmac_sha512	Ja	Entspricht den drbg_pr_*-Algorithmen, aber ohne Deaktivierung der 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 Benutzeroberfläche erhalten eigene 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 Quellcode 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_dist

• Mit build.sh erstellen (alt):

  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.

Anleitung für Endnutzer

Anleitung für Crypto Officers

Zum Betrieb des Kernel-Moduls muss das Betriebssystem auf einen einzelnen Betriebsmodus beschränkt werden. 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 wird nur in einem genehmigten Betriebsmodus betrieben.

Der Crypto Officer kann die Selbsttests jederzeit durch einen Neustart ausführen. auf dem Gerät.

Anleitung für Nutzer

Nutzer des Kernelmoduls sind andere Kernelkomponenten, die kryptografische Algorithmen verwenden müssen. 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 zur Einhaltung der FIPS-Compliance ist auf genehmigte Algorithmen beschränkt. 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

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.