Moduł kryptograficzny GKI z certyfikatem FIPS 140-3

Jądro GKI zawiera moduł jądra Linuksa o nazwie fips140.ko , który jest zgodny z wymaganiami FIPS 140-3 dla modułów oprogramowania kryptograficznego. Moduł ten można zgłosić do certyfikacji FIPS, jeśli wymaga tego produkt, na którym działa jądro GKI.

Przed użyciem procedur kryptograficznych muszą zostać spełnione w szczególności następujące wymagania FIPS 140-3:

• Moduł musi sprawdzić swoją integralność przed udostępnieniem algorytmów kryptograficznych.
• Moduł musi ćwiczyć i weryfikować zatwierdzone algorytmy kryptograficzne za pomocą autotestów znanych odpowiedzi przed ich udostępnieniem.

Dlaczego osobny moduł jądra

Walidacja FIPS 140-3 opiera się na założeniu, że raz certyfikowany moduł oparty na oprogramowaniu lub sprzęcie nie ulega zmianie. W przypadku zmiany należy dokonać ponownej certyfikacji. Nie odpowiada to obecnie stosowanym procesom tworzenia oprogramowania i w wyniku tego wymogu moduły oprogramowania FIPS są zazwyczaj projektowane tak, aby jak najściślej skupiały się na komponentach kryptograficznych, aby zapewnić, że zmiany niezwiązane z kryptografią nie zostaną nie wymagają ponownej oceny kryptografii.

Jądro GKI ma być regularnie aktualizowane przez cały okres wsparcia. To sprawia, że ​​nie jest możliwe, aby całe jądro znajdowało się w granicach modułu FIPS, ponieważ taki moduł musiałby być ponownie certyfikowany przy każdej aktualizacji jądra. Zdefiniowanie „modułu FIPS” jako podzbioru obrazu jądra złagodziłoby ten problem, ale go nie rozwiązało, ponieważ zawartość binarna „modułu FIPS” nadal zmieniałaby się znacznie częściej niż to konieczne.

Przed wersją jądra 6.1 inną kwestią było to, że GKI zostało skompilowane z włączoną funkcją LTO (Optymalizacja czasu łącza), ponieważ LTO było warunkiem wstępnym integralności przepływu sterowania , która jest ważną funkcją bezpieczeństwa.

Dlatego cały kod objęty wymaganiami FIPS 140-3 jest spakowany w oddzielnym module jądra fips140.ko , który opiera się wyłącznie na stabilnych interfejsach udostępnianych przez źródło jądra GKI, z którego został zbudowany. Gwarantuje to, że moduł może być używany z różnymi wydaniami GKI tej samej generacji oraz że należy go aktualizować i ponownie zgłaszać do certyfikacji tylko wtedy, gdy naprawiono jakiekolwiek problemy w kodzie przenoszonym przez sam moduł.

Kiedy używać modułu

Samo jądro GKI zawiera kod zależny od procedur kryptograficznych, które są również spakowane w module jądra FIPS 140-3. Dlatego wbudowane procedury kryptograficzne nie są w rzeczywistości przenoszone z jądra GKI, ale raczej kopiowane do modułu. Po załadowaniu modułu wbudowane procedury kryptograficzne są wyrejestrowywane z Linux CryptoAPI i zastępowane przez te obsługiwane przez moduł.

Oznacza to, że moduł fips140.ko jest całkowicie opcjonalny i jego wdrożenie ma sens tylko wtedy, gdy wymagana jest certyfikacja FIPS 140-3. Poza tym moduł nie zapewnia żadnej dodatkowej funkcjonalności, a niepotrzebne ładowanie może jedynie wpłynąć na czas rozruchu, nie zapewniając żadnych korzyści.

Jak wdrożyć moduł

Moduł można włączyć do kompilacji systemu Android, wykonując następujące kroki:

• Dodaj nazwę modułu do BOARD_VENDOR_RAMDISK_KERNEL_MODULES . Powoduje to skopiowanie modułu na dysk RAM dostawcy.
• Dodaj nazwę modułu do BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD . Powoduje to dodanie nazwy modułu do modules.load w miejscu docelowym. modules.load zawiera listę modułów ładowanych przez init podczas uruchamiania urządzenia.

Samokontrola integralności

Moduł jądra FIPS 140-3 pobiera podsumowanie HMAC-SHA256 z własnych sekcji .code i .rodata w czasie ładowania modułu i porównuje je z podsumowaniem zarejestrowanym w module. Ma to miejsce po tym, jak moduł ładujący moduły Linux dokonał już zwykłych modyfikacji, takich jak przetwarzanie relokacji ELF i alternatywne łatanie erraty procesora w tych sekcjach. Aby zapewnić prawidłowe odtworzenie podsumowania, podejmowane są następujące dodatkowe kroki:

• Relokacje ELF są zachowywane wewnątrz modułu, dzięki czemu można je zastosować w odwrotnej kolejności do wejścia HMAC.
• Wszystkie inne poprawki kodu są wyłączone dla modułu, w tym klucze statyczne, a zatem punkty śledzenia, a także zaczepy dostawców.

Autotesty ze znaną odpowiedzią

Wszelkie zaimplementowane algorytmy objęte wymaganiami FIPS 140-3 muszą przed użyciem przeprowadzić autotest ze znaną odpowiedzią. Zgodnie z wytycznymi dotyczącymi implementacji FIPS 140-3 10.3.A , w przypadku szyfrów wystarczający jest pojedynczy wektor testowy na algorytm wykorzystujący dowolną obsługiwaną długość klucza, o ile testowane jest zarówno szyfrowanie, jak i deszyfrowanie.

Linux CryptoAPI ma pojęcie priorytetów algorytmów, w którym może współistnieć kilka implementacji (na przykład ta wykorzystująca specjalne instrukcje kryptograficzne i rezerwowa dla procesorów, które nie implementują tych instrukcji) tego samego algorytmu. Istnieje zatem potrzeba testowania wszystkich implementacji tego samego algorytmu. Jest to konieczne, ponieważ Linux CryptoAPI pozwala na ominięcie wyboru opartego na priorytetach i zamiast tego wybranie algorytmu o niższym priorytecie.

Algorytmy zawarte w module

Wszystkie algorytmy zawarte w module FIPS 140-3 są wymienione poniżej. Dotyczy to gałęzi jądra android12-5.10 , android13-5.10 , android13-5.15 , android14-5.15 i android14-6.1 , chociaż w stosownych przypadkach zaznaczono różnice między wersjami jądra.

Algorytm	Wdrożenia	Zatwierdzone	Definicja
aes	aes-generic , aes-arm64 , aes-ce , biblioteka AES	Tak	Zwykły szyfr blokowy AES bez trybu działania: obsługiwane są wszystkie rozmiary kluczy (128 bitów, 192 bity i 256 bitów). Wszystkie implementacje inne niż implementacja biblioteki można skomponować z trybem działania poprzez szablon.
cmac(aes)	cmac (szablon), cmac-aes-neon , cmac-aes-ce	Tak	AES-CMAC: obsługiwane są wszystkie rozmiary kluczy AES. Szablon cmac można skomponować z dowolną implementacją aes przy użyciu cmac(<aes-impl>) . Pozostałe wdrożenia są samodzielne.
ecb(aes)	ecb (szablon), ecb-aes-neon , ecb-aes-neonbs , ecb-aes-ce	Tak	AES-ECB: obsługiwane są wszystkie rozmiary kluczy AES. Szablon ecb można skomponować z dowolną implementacją aes przy użyciu ecb(<aes-impl>) . Pozostałe wdrożenia są samodzielne.
cbc(aes)	cbc (szablon), cbc-aes-neon , cbc-aes-neonbs , cbc-aes-ce	Tak	AES-CBC: obsługiwane są wszystkie rozmiary kluczy AES. Szablon cbc można skomponować z dowolną implementacją aes za pomocą ctr(<aes-impl>) . Pozostałe wdrożenia są samodzielne.
cts(cbc(aes))	cts (szablon), cts-cbc-aes-neon , cts-cbc-aes-ce	Tak	AES-CBC-CTS lub AES-CBC z kradzieżą tekstu zaszyfrowanego: stosowana konwencja to CS3 ; ostatnie dwa bloki tekstu zaszyfrowanego są zamieniane bezwarunkowo. Obsługiwane są wszystkie rozmiary kluczy AES. Szablon cts można skomponować z dowolną implementacją cbc za pomocą cts(<cbc(aes)-impl>) . Pozostałe wdrożenia są samodzielne.
ctr(aes)	ctr (szablon), ctr-aes-neon , ctr-aes-neonbs , ctr-aes-ce	Tak	AES-CTR: obsługiwane są wszystkie rozmiary kluczy AES. Szablon ctr można skomponować z dowolną implementacją aes za pomocą ctr(<aes-impl>) . Pozostałe wdrożenia są samodzielne.
xts(aes)	xts (szablon), xts-aes-neon , xts-aes-neonbs , xts-aes-ce	Tak	AES-XTS: obsługiwane są wszystkie rozmiary kluczy AES. Szablon xts można skomponować z dowolną implementacją ecb(aes) przy użyciu xts(<ecb(aes)-impl>) . Pozostałe wdrożenia są samodzielne. Wszystkie implementacje implementują kontrolę słabego klucza wymaganą przez FIPS; to znaczy, że klucze XTS, których pierwsza i druga połowa są równe, są odrzucane.
gcm(aes)	gcm (szablon), gcm-aes-ce	nr 1	AES-GCM: obsługiwane są wszystkie rozmiary kluczy AES. Obsługiwane są tylko 96-bitowe IV. Podobnie jak w przypadku wszystkich innych trybów AES w tym module, osoba wywołująca jest odpowiedzialna za zapewnienie IV. Szablon gcm można złożyć z dowolną implementacją ctr(aes) i ghash przy użyciu gcm_base(<ctr(aes)-impl>,<ghash-impl>) . Pozostałe wdrożenia są samodzielne.
sha1	sha1-generic , sha1-ce	Tak	Kryptograficzna funkcja skrótu SHA-1
sha224	sha224-generic , sha224-arm64 , sha224-ce	Tak	Kryptograficzna funkcja skrótu SHA-224: kod jest współdzielony z SHA-256.
sha256	sha256-generic , sha256-arm64 , sha256-ce , biblioteka SHA-256	Tak	Kryptograficzna funkcja skrótu SHA-256: Oprócz tradycyjnego interfejsu CryptoAPI, SHA-256 udostępnia interfejs biblioteczny. Ten interfejs biblioteki wykorzystuje inną implementację.
sha384	sha384-generic , sha384-arm64 , sha384-ce	Tak	Kryptograficzna funkcja skrótu SHA-384: kod jest współdzielony z SHA-512.
sha512	sha512-generic , sha512-arm64 , sha512-ce	Tak	Kryptograficzna funkcja skrótu SHA-512
hmac	hmac (szablon)	Tak	HMAC (Keyed-Hash Message Authentication Code): Szablon hmac można utworzyć przy użyciu dowolnego algorytmu lub implementacji SHA przy użyciu hmac(<sha-alg>) lub hmac(<sha-impl>) .
stdrng	drbg_pr_hmac_sha1 , drbg_pr_hmac_sha256 , drbg_pr_hmac_sha384 , drbg_pr_hmac_sha512	Tak	Utworzono instancję HMAC_DRBG z nazwaną funkcją skrótu i ​​włączoną odpornością na przewidywanie: uwzględniono kontrole stanu. Użytkownicy tego interfejsu otrzymują własne instancje DRBG.
stdrng	drbg_nopr_hmac_sha1 , drbg_nopr_hmac_sha256 , drbg_nopr_hmac_sha384 , drbg_nopr_hmac_sha512	Tak	Taki sam jak algorytmy drbg_pr_* , ale z wyłączoną odpornością na przewidywanie. Kod jest współdzielony z wariantem odpornym na przewidywanie. W wersji jądra 5.10 DRBG o najwyższym priorytecie to drbg_nopr_hmac_sha256 . W wersji jądra 5.15 i nowszych jest to drbg_pr_hmac_sha512 .
jitterentropy_rng	jitterentropy_rng	NIE	Wersja 2.2.0 Jitter RNG : Użytkownicy tego interfejsu otrzymują własne instancje Jitter RNG. Nie wykorzystują ponownie instancji używanych przez DRBG.
xcbc(aes)	xcbc-aes-neon , xcbc-aes-ce	NIE
xctr(aes)	xctr-aes-neon , xctr-aes-ce	NIE	Występuje tylko w wersji jądra 5.15 i nowszych.
cbcmac(aes)	cbcmac-aes-neon , cbcmac-aes-ce	NIE
essiv(cbc(aes),sha256)	essiv-cbc-aes-sha256-neon , essiv-cbc-aes-sha256-ce	NIE

Zbuduj moduł ze źródła

W przypadku Androida 14 lub nowszego (w tym android-mainline ) zbuduj moduł fips140.ko ze źródła, używając następujących poleceń.

• Buduj z Bazelem:

  tools/bazel run //common:fips140_dist
  

• Kompiluj za pomocą build.sh (starsza wersja):

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

Te polecenia wykonują pełną kompilację, w tym jądro i moduł fips140.ko z osadzoną w nim zawartością skrótu HMAC-SHA256.

Wskazówki dla użytkownika końcowego

Wskazówki dla specjalisty ds. kryptografii

Aby móc obsługiwać moduł jądra, system operacyjny musi być ograniczony do trybu działania z jednym operatorem. Jest to obsługiwane automatycznie przez system Android za pomocą sprzętu do zarządzania pamięcią w procesorze.

Modułu jądra nie można zainstalować osobno; jest on zawarty w oprogramowaniu sprzętowym urządzenia i ładowany automatycznie podczas rozruchu. Działa wyłącznie w zatwierdzonym trybie pracy.

Crypto Officer może w dowolnym momencie uruchomić autotesty poprzez ponowne uruchomienie urządzenia.

Wskazówki dla użytkownika

Użytkownikiem modułu jądra są inne komponenty jądra, które muszą korzystać z algorytmów kryptograficznych. Moduł jądra nie zapewnia dodatkowej logiki w wykorzystaniu algorytmów oraz nie przechowuje żadnych parametrów poza czasem niezbędnym do wykonania operacji kryptograficznej.

Stosowanie algorytmów na potrzeby zgodności z FIPS ogranicza się do zatwierdzonych algorytmów. Aby spełnić wymagania „wskaźnika usługi” FIPS 140-3, moduł udostępnia funkcję fips140_is_approved_service , która wskazuje, czy algorytm jest zatwierdzony.

Błędy autotestu

W przypadku niepowodzenia autotestu moduł jądra powoduje panikę jądra i urządzenie nie kontynuuje uruchamiania. Jeśli ponowne uruchomienie urządzenia nie rozwiąże problemu, urządzenie musi uruchomić się w trybie odzyskiwania, aby rozwiązać problem poprzez ponowne flashowanie urządzenia.