Der GKI -Kernel enthält ein Linux-Kernelmodul namens fips140.ko , das die Anforderungen von FIPS 140-3 für kryptografische Softwaremodule erfüllt. Dieses Modul kann zur FIPS-Zertifizierung eingereicht werden, wenn das Produkt, auf dem der GKI-Kernel ausgeführt wird, dies erfordert.
Insbesondere die folgenden FIPS 140-3-Anforderungen müssen erfüllt sein, bevor die Krypto-Routinen verwendet werden dürfen:
- Das Modul muss seine eigene Integrität prüfen, bevor es kryptografische Algorithmen zur Verfügung stellt.
- Das Modul muss seine genehmigten kryptografischen Algorithmen mithilfe von Selbsttests mit bekannter Antwort ausführen und verifizieren, bevor es sie verfügbar macht.
Warum ein separates Kernelmodul
Die FIPS 140-3-Validierung basiert auf der Idee, dass ein einmal zertifiziertes software- oder hardwarebasiertes Modul nie mehr geändert wird. Bei einer Änderung muss es neu zertifiziert werden. Dies passt nicht ohne Weiteres zu den heute verwendeten Softwareentwicklungsprozessen, und aufgrund dieser Anforderung sind FIPS-Softwaremodule im Allgemeinen so konzipiert, dass sie sich so eng wie möglich auf die kryptografischen Komponenten konzentrieren, um sicherzustellen, dass Änderungen, die nichts mit Kryptografie zu tun haben erfordern keine Neubewertung der Kryptografie.
Der GKI-Kernel soll während seiner gesamten unterstützten Lebensdauer regelmäßig aktualisiert werden. Dies macht es unmöglich, dass sich der gesamte Kernel innerhalb der FIPS-Modulgrenze befindet, da ein solches Modul bei jeder Kernel-Aktualisierung neu zertifiziert werden muss. Außerdem wird GKI mit aktiviertem LTO (Link Time Optimization) kompiliert, da LTO eine Voraussetzung für CFI ist, das ein wichtiges Sicherheitsmerkmal ist. Dies macht es unmöglich, die Grenze des FIPS-Moduls nur um den Kryptocode des Kernels herum zu ziehen, da sich dieser Code nicht an einer klar definierten Stelle in der resultierenden Binärdatei befindet. Kernel-Updates können auch den Kryptocode ändern.
Daher wird der gesamte Code, der von den FIPS 140-3-Anforderungen abgedeckt wird, in ein separates Kernelmodul fips140.ko , das nur auf stabilen Schnittstellen beruht, die von der GKI-Kernelquelle bereitgestellt werden, aus der es erstellt wurde. Dadurch wird sichergestellt, dass das Modul mit verschiedenen GKI-Releases derselben Generation verwendet werden kann und dass es nur dann aktualisiert und erneut zur Zertifizierung eingereicht werden muss, wenn Probleme im Code behoben wurden, der vom Modul selbst getragen wird.
Wann Sie das Modul verwenden
Der GKI-Kernel selbst enthält Code, der von den Kryptoroutinen abhängt, die ebenfalls im FIPS 140-3-Kernelmodul enthalten sind. Daher werden die eingebauten Krypto-Routinen nicht wirklich aus dem GKI-Kernel ausgelagert, sondern in das Modul kopiert. Wenn das Modul geladen wird, werden die integrierten Kryptoroutinen von der Linux CryptoAPI abgemeldet und durch die vom Modul getragenen ersetzt.
Das bedeutet, dass das fips140.ko -Modul vollständig optional ist und es nur dann sinnvoll eingesetzt werden kann, wenn eine FIPS 140-3-Zertifizierung erforderlich ist. Darüber hinaus bietet das Modul keine zusätzlichen Funktionen, und unnötiges Laden wirkt sich wahrscheinlich nur auf die Startzeit aus, ohne einen Vorteil zu bieten.
So stellen Sie das Modul bereit
Das Modul kann mit den folgenden Schritten in den Android-Build integriert werden:
- Fügen Sie den Modulnamen zu
BOARD_VENDOR_RAMDISK_KERNEL_MODULES. Dadurch wird das Modul auf die Hersteller-Ramdisk kopiert. - Fügen Sie den Modulnamen zu
BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD. Dadurch wird der Modulname zumodules.loadauf dem Ziel hinzugefügt.modules.loadenthält die Liste der Module, die voninitgeladen werden, wenn das Gerät bootet.
Der Integritätsselbsttest
Das FIPS 140-3-Kernelmodul nimmt den HMAC-SHA256-Digest seiner eigenen .code und .rodata Abschnitte beim Laden des Moduls und vergleicht ihn mit dem im Modul aufgezeichneten Digest. Dies findet statt, nachdem der Linux-Modul-Loader bereits die üblichen Modifikationen wie ELF-Umzugsverarbeitung und alternatives Patchen für CPU-Errata an diesen Abschnitten vorgenommen hat. Die folgenden zusätzlichen Schritte werden unternommen, um sicherzustellen, dass der Digest korrekt reproduziert werden kann:
- ELF-Verschiebungen werden innerhalb des Moduls aufbewahrt, so dass sie umgekehrt auf die Eingabe des HMAC angewendet werden können.
- Alle anderen Code-Patches sind für das Modul deaktiviert, einschließlich statischer Schlüssel und damit Tracepoints sowie Hersteller-Hooks.
Die bekannten Selbsttests
Alle implementierten Algorithmen, die von den FIPS 140-3-Anforderungen abgedeckt werden, müssen vor der Verwendung einen Selbsttest mit bekannter Antwort durchführen. Gemäß der FIPS 140-3-Implementierungsrichtlinie 10.3.A ist ein einzelner Testvektor pro Algorithmus, der eine der unterstützten Schlüssellängen verwendet, für Chiffren ausreichend, solange sowohl die Verschlüsselung als auch die Entschlüsselung getestet werden.
Die Linux CryptoAPI hat eine Vorstellung von 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. Dies ist notwendig, da die Linux-CryptoAPI es zulässt, die prioritätsbasierte Auswahl zu umgehen und stattdessen einen Algorithmus mit niedrigerer Priorität auszuwählen.
Im Modul enthaltene Algorithmen
Alle Algorithmen, die im FIPS 140-3-Modul enthalten sind, wenn es aus den Android13-5.10-Quellen erstellt wurde, sind wie folgt aufgeführt.
| Algorithmus | Implementierungen | Zugelassen | 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 durch eine Vorlage zusammengestellt 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 unter Verwendung von cmac(<aes-impl>) . 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 ecb Vorlage kann mit jeder Implementierung von aes unter Verwendung von ecb(<aes-impl>) . Die anderen Implementierungen sind eigenständig. |
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 cbc Vorlage kann mit jeder Implementierung von aes unter Verwendung von ctr(<aes-impl>) . 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 Chiffretextblöcke werden bedingungslos ausgetauscht. Alle AES-Schlüsselgrößen werden unterstützt. Die cts -Vorlage kann mit jeder Implementierung von cbc unter Verwendung von cts(<cbc(aes)-impl>) 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 unter Verwendung von ctr(<aes-impl>) . Die anderen Implementierungen sind eigenständig. |
xts(aes) | xts (Vorlage), xts-aes-neon , xts-aes-neonbs , xts-aes-ce | Ja | AES-XTS: Alle AES-Schlüsselgrößen werden unterstützt. Die xts Vorlage kann mit jeder Implementierung von ecb(aes) unter Verwendung von xts(<ecb(aes)-impl>) . Die anderen Implementierungen sind eigenständig. Alle Implementierungen implementieren die von FIPS geforderte Prüfung auf schwache Schlüssel; das heißt, XTS-Schlüssel, deren erste und zweite Hälfte gleich sind, werden zurückgewiesen. |
gcm(aes) | gcm (Vorlage), gcm-aes-ce | Nein 1 | 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 beliebigen Implementierungen von ctr(aes) und ghash unter Verwendung von gcm_base(<ctr(aes)-impl>,<ghash-impl>) . 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 mit SHA-256 geteilt. |
sha256 | sha256-generic , sha256-arm64 , sha256-ce , SHA-256-Bibliothek | Ja | SHA-256-Kryptografie-Hashfunktion: Zusätzlich zur herkömmlichen CryptoAPI-Schnittstelle wird SHA-256 eine Bibliotheksschnittstelle bereitgestellt. Diese Bibliotheksschnittstelle verwendet eine andere Implementierung. |
sha384 | sha384-generic , sha384-arm64 , sha384-ce | Ja | SHA-384 kryptografische Hash-Funktion: Der Code wird mit SHA-512 geteilt. |
sha512 | sha512-generic , sha512-arm64 , sha512-ce | Ja | SHA-512 kryptografische Hash-Funktion |
hmac | hmac (Vorlage) | Ja | HMAC (Keyed-Hash Message Authentication Code): Die hmac Vorlage kann mit jedem SHA-Algorithmus oder jeder Implementierung unter Verwendung von hmac(<sha-alg>) oder hmac(<sha-impl>) . |
stdrng | drbg_pr_hmac_sha1 , drbg_pr_hmac_sha256 , drbg_pr_hmac_sha384 , drbg_pr_hmac_sha512 | Ja | HMAC_DRBG instanziiert mit der benannten Hash-Funktion und mit aktiviertem Vorhersagewiderstand: Integritätsprüfungen sind enthalten. Benutzer 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 deaktiviertem Vorhersagewiderstand. Der Code wird mit der prädiktionsresistenten Variante geteilt. Das DRBG mit der höchsten Priorität ist drbg_nopr_hmac_sha256 . |
jitterentropy_rng | jitterentropy_rng | Nein | Version 2.2.0 des Jitter RNG : Benutzer dieser Schnittstelle erhalten ihre eigenen Jitter RNG-Instanzen. Sie verwenden die von den DRBGs verwendeten Instanzen nicht wieder. |
xcbc(aes) | xcbc-aes-neon , xcbc-aes-ce | Nein | |
cbcmac(aes) | cbcmac-aes-neon , cbcmac-aes-ce | Nein | |
essiv(cbc(aes),sha256) | essiv-cbc-aes-sha256-neon , essiv-cbc-aes-sha256-ce | Nein |
Erstellen des Moduls aus der Quelle
Das Modul fips140.ko kann mit dem folgenden Befehl aus den GKI-Kernelquellen erstellt werden:
BUILD_CONFIG=common/build.config.gki.aarch64.fips140 build/build.sh
Dies führt den vollständigen Build mit dem Kernel und dem fips140.ko -Modul durch, wobei der korrekte HMAC-SHA256-Digest seines Inhalts eingebettet ist.
Erstellen Sie in Android 14 (AOSP experimentell) und höher mit Bazel anstelle von build/build.sh mit dem folgenden Befehl:
tools/bazel run //common:fips140_dist
Endbenutzerführung
Anleitung für Krypto-Beauftragte
Um das Kernel-Modul zu betreiben, muss das Betriebssystem auf einen Betriebsmodus eines einzigen Bedieners beschränkt sein. Dies wird automatisch von Android mithilfe von Speicherverwaltungshardware im Prozessor gehandhabt.
Das Kernelmodul kann nicht separat installiert werden; Es ist Teil der Gerätefirmware und wird beim Booten automatisch geladen. Es arbeitet nur in einem zugelassenen Betriebsmodus.
Der Crypto Officer kann die Selbsttests jederzeit durch einen Neustart des Geräts veranlassen.
Benutzerführung
Der Benutzer des Kernelmoduls sind andere Kernelkomponenten, die kryptografische Algorithmen verwenden müssen. Das Kernelmodul stellt keine zusätzliche Logik bei der Verwendung der Algorithmen bereit und speichert keine Parameter über die Zeit hinaus, die zum Ausführen einer kryptografischen Operation benötigt wird.
Die Verwendung der Algorithmen zum Zweck der FIPS-Konformität ist auf genehmigte Algorithmen beschränkt. Um die Anforderung von FIPS 140-3 „Service Indicator“ zu erfüllen, stellt das Modul eine Funktion fips140_is_approved_service , die anzeigt, ob ein Algorithmus genehmigt ist.
Fehler beim Selbsttest
Im Falle eines Selbsttestfehlers verursacht das Kernel-Modul eine Kernel-Panik und das Gerät bootet nicht weiter. Wenn ein Neustart des Geräts das Problem nicht behebt, muss das Gerät in den Wiederherstellungsmodus booten, um das Problem durch erneutes Flashen des Geräts zu beheben.
Es wird erwartet, dass die AES-GCM-Implementierungen des Moduls „Algorithmus-geprüft“, aber nicht „Modul-geprüft“ sein können. Sie können validiert werden, aber AES-GCM kann aus Sicht eines FIPS-Moduls nicht als genehmigter Algorithmus betrachtet werden. Dies liegt daran, dass die FIPS-Modulanforderungen für GCM nicht mit GCM-Implementierungen kompatibel sind, die keine eigenen IVs generieren. ↩