certyfikowany moduł kryptograficzny GKI z certyfikatem FIPS 140-3

Jądro GKI zawiera Moduł jądra systemu Linux o nazwie fips140.ko, który jest zgodny z Wymagania FIPS 140-3 modułów oprogramowania kryptograficznego. Ten moduł można przesłać do standardu FIPS , jeśli wymaga tego usługa z jądrem GKI.

W szczególności te wymagania FIPS 140-3 należy spełnić przed możesz zastosować procedury kryptograficzne:

• Przed rozpoczęciem tworzenia algorytmów kryptograficznych moduł musi sprawdzić własną integralność i dostępności informacji.
• Moduł musi sprawdzać i weryfikować zatwierdzone algorytmy kryptograficzne przy użyciu testów autotestów ze znanymi odpowiedziami.

Dlaczego oddzielny moduł jądra

Walidacja FIPS 140-3 opiera się na założeniu, że gdy oprogramowanie lub sprzęt moduł został certyfikowany, nigdy nie jest zmieniany. Jeśli została zmieniona, musi być ponownie uzyskać certyfikat. To nie odpowiada procesom tworzenia oprogramowania w obecnie używanych systemów FIPS. W związku z tym moduły oprogramowania FIPS jest zazwyczaj skoncentrowany na komponentach kryptograficznych aby mieć pewność, że zmiany niezwiązane z kryptografią mogą wymagać ponownej oceny kryptografii.

Jądro GKI powinno być regularnie aktualizowane przez cały okres oraz długość życia. Uniemożliwia to umieszczenie całego jądra w standardzie FIPS. granicą modułu, w związku z czym taki moduł wymagałby ponownego certyfikatu dla każdego jądra systemu . Definiowanie modułu FIPS jako podzbioru obrazu jądra, ale nie pozwoli go rozwiązać, ponieważ zawartość binarna „Moduł FIPS” zmieniałyby się znacznie częściej, niż trzeba.

Przed wersją 6.1 jądra można było wziąć pod uwagę także fakt, że GKI została skompilowana z Włączono LTO (optymalizacja czasu połączenia), ponieważ był on niezbędnym elementem kontroli Integralność przepływu, czyli ważna funkcja zabezpieczeń.

Dlatego cały kod objęty normą FIPS 140-3 znajduje się w pakiecie. do osobnego modułu jądra fips140.ko, który opiera się wyłącznie na stabilnej wersji udostępnianych przez źródło jądra GKI, z którego zostało utworzone. Ten co oznacza, że moduł może być używany z różnymi wersjami GKI tego samego oraz że należy je zaktualizować i ponownie przesłać wyłącznie w celu uzyskania certyfikatu sprawdź, czy w kodzie umieszczonym przez moduł nie występują żadne błędy.

Kiedy używać modułu

Jądro GKI zawiera kod zależny od procedur kryptograficznych są także spakowane do modułu jądra FIPS 140-3. W związku z tym wbudowane kryptowaluty że rutyny nie są przenoszone z jądra GKI, lecz są kopiowane do w module. Po wczytaniu modułu wbudowane procedury kryptograficzne są wyrejestrowane z interfejsu Linux CryptoAPI i zastąpione przez interfejsy obsługiwane przez .

Oznacza to, że moduł fips140.ko jest całkowicie opcjonalny. Zapewnia jedynie warto wdrożyć go, jeśli wymagana jest certyfikacja FIPS 140-3. Poza tym moduł nie ma żadnych dodatkowych funkcji, a ładowanie go niepotrzebnie co zwykle nie wpływa na czas uruchamiania, nie przynosząc żadnych korzyści.

Jak wdrożyć moduł

Moduł można włączyć do kompilacji Androida, wykonując te czynności:

• Dodaj nazwę modułu do pola BOARD_VENDOR_RAMDISK_KERNEL_MODULES. Powoduje to, że który ma zostać skopiowany do folderu pamięci RAM dostawcy.
• Dodaj nazwę modułu do pola BOARD_VENDOR_RAMDISK_KERNEL_MODULES_LOAD. Ten powoduje, że nazwa modułu jest dodawana do elementu modules.load w elemencie docelowym. modules.load zawiera listę modułów ładowanych przez tag init, gdy uruchamianie urządzenia.

Samodzielne sprawdzenie integralności

Moduł jądra FIPS 140-3 wykorzystuje skrót HMAC-SHA256 z własnego skrótu .code i .rodata w czasie wczytywania modułu, i porównuje go ze skrótem omówione w ramach modułu. Odbywa się to po tym, jak w programie ładującym moduł po wprowadzeniu standardowych zmian, takich jak przetwarzanie relokacji ELF i lub instalowanie poprawek błędów procesora w tych sekcjach. Poniżej podejmowane są dodatkowe działania, aby skrót mógł zostać odtworzony prawidłowo:

• Relokacje ELF są zachowywane w module, więc można je zastosować na dane wejściowe HMAC.
• Moduł odwraca wszystkie poprawki kodu wprowadzone przez jądro na potrzeby kreacji dynamicznych Stos wywołań cieni. W szczególności moduł zastępuje wszelkie instrukcje, które wypchnięcie lub wyskoczenie ze stosu wywołań cienia za pomocą kodu uwierzytelniania wskaźnika (PAC), które były dostępne pierwotnie.
• Instalowanie poprawek kodu we wszystkich innych przypadkach jest wyłączone w module, w tym klucze statyczne i oraz punkty zaczepienia dostawcy.

Autotesty dotyczące znanej odpowiedzi

Wszystkie zaimplementowane algorytmy objęte normą FIPS 140-3 muszą jak sprawdzić znaną odpowiedź przed jej użyciem. Zgodnie z normą FIPS 140-3 Wskazówki dotyczące wdrażania 10.3.A. jeden wektor testowy na algorytm przy użyciu dowolnej z obsługiwanych długości kluczy to wystarczającą do szyfrowania, jeśli testowane jest zarówno szyfrowanie, jak i odszyfrowywanie.

W Linuksie CryptoAPI można znaleźć priorytety algorytmu, przy czym kilka z nich implementacji (np. wykorzystującą specjalne instrukcje dotyczące kryptografii, a kod zastępczy dla procesorów, które nie stosują tych instrukcji) tego samego algorytmu może współistnieć. Należy więc testować wszystkie implementacje tego samego algorytmem bezpieczeństwa. Jest to konieczne, ponieważ interfejs Linux CryptoAPI zezwala pomijanego wyboru i dla algorytmu o niższym priorytecie została wybrana.

Algorytmy zawarte w module

Wszystkie algorytmy uwzględnione w module FIPS 140-3 są wymienione poniżej. Dotyczy to tych usług: android12-5.10, android13-5.10, android13-5.15, jednak gałęzie jądra android14-5.15, android14-6.1 i android15-6.6 tam, gdzie ma to uzasadnienie, różnice między wersjami jądra.

Algorytm	Implementacje	Odpowiednia	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-, 192-bitowe i 256-bitowe). Wszystkie implementacje inne niż implementacja biblioteki można skomponować z trybem działania z poziomu szablonu.
cmac(aes)	cmac (szablon), cmac-aes-neon, cmac-aes-ce	Tak	AES-CMAC: obsługiwane są wszystkie rozmiary kluczy AES. Szablon cmac może być utworzony z dowolną implementacją elementu aes za pomocą atrybutu cmac(<aes-impl>). Pozostałe implementacje są niezależne.
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że być utworzony z dowolną implementacją elementu aes za pomocą atrybutu ecb(<aes-impl>). Pozostałe implementacje są niezależne.
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że być utworzony z dowolną implementacją elementu aes za pomocą atrybutu ctr(<aes-impl>). Pozostałe implementacje są niezależne.
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ą zastępowane bezwarunkowo.Obsługiwane są wszystkie rozmiary kluczy AES.Szablon cts może być utworzony z dowolną implementacją elementu cbc za pomocą atrybutu cts(<cbc(aes)-impl>).Pozostałe implementacje są niezależne.
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że być utworzony z dowolną implementacją elementu aes za pomocą atrybutu ctr(<aes-impl>). Pozostałe implementacje są niezależne.
xts(aes)	xts (szablon), xts-aes-neon, xts-aes-neonbs, xts-aes-ce	Tak	AES-XTS: w jądrze w wersji 6.1 lub starszej obsługiwane są wszystkie rozmiary kluczy AES. w jądrze w wersji 6.6 lub nowszej obsługiwane są tylko AES-128 i AES-256. Szablon xts może być utworzony z dowolną implementacją elementu ecb(aes) za pomocą atrybutu xts(<ecb(aes)-impl>). Pozostałe implementacje są niezależne. we wszystkich implementacjach stosuje się słabą kontrolę klucza wymaganą przez FIPS; czyli klucze XTS, których pierwsza i druga połowa są równe, są odrzucane.
gcm(aes)	gcm (szablon), gcm-aes-ce	Nr1	AES-GCM: obsługiwane są wszystkie rozmiary kluczy AES. Obsługiwane są tylko 96-bitowe pliki IV. Tak jak w przypadku wszystkich innych trybów AES w tym module, za dostarczanie IV odpowiada element wywołujący. Szablon gcm może zawierać dowolne implementacje komponentów ctr(aes) i ghash w języku gcm_base(<ctr(aes)-impl>,<ghash-impl>). Pozostałe implementacje są niezależne.
sha1	sha1-generic, sha1-ce	Tak	Kryptograficzna funkcja skrótu SHA-1
sha224	sha224-generic, sha224-arm64, sha224-ce	Tak	Funkcja szyfrowania SHA-224: kod jest udostępniany z wykorzystaniem algorytmu SHA-256.
sha256	Biblioteka sha256-generic, sha256-arm64, sha256-ce, SHA-256	Tak	Funkcja skrótu kryptograficznego SHA-256: oprócz standardowego interfejsu CryptoAPI interfejs biblioteki SHA-256 jest udostępniany. Interfejs tego biblioteki ma inną implementację.
sha384	sha384-generic, sha384-arm64, sha384-ce	Tak	Funkcja szyfrowania SHA-384: kod jest udostępniany z wykorzystaniem algorytmu SHA-512.
sha512	sha512-generic, sha512-arm64, sha512-ce	Tak	Kryptograficzna funkcja skrótu SHA-512
sha3-224	sha3-224-generic	Tak	kryptograficzna funkcja skrótu SHA3-224, Występuje tylko w jądrze w wersji 6.6 lub nowszej.
sha3-256	sha3-256-generic	Tak	Tak samo jak wyżej, ale z 256-bitowym skrótem o długości SHA3-256. Wszystkie długości skrótu używają tej samej implementacji Keccak.
sha3-384	sha3-384-generic	Tak	Tak samo jak wyżej, ale z 384-bitowym skrótem o długości SHA3-384. Wszystkie długości skrótu używają tej samej implementacji Keccak.
sha3-512	sha3-512-generic	Tak	Tak samo jak wyżej, ale z 512-bitowym skrótem o długości SHA3-512. Wszystkie długości skrótu używają tej samej implementacji Keccak.
hmac	hmac (szablon)	Tak	HMAC (Keyed-Hash Message Authentication Code): szablon hmac może zawierać dowolny algorytm SHA lub implementację przy użyciu hmac(<sha-alg>) bądź hmac(<sha-impl>).
stdrng	drbg_pr_hmac_sha1, drbg_pr_hmac_sha256, drbg_pr_hmac_sha384, drbg_pr_hmac_sha512	Tak	Wystąpienie HMAC_DRBG z nazwaną funkcją skrótu i włączoną odpornością na prognozy: uwzględniane są 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 algorytm drbg_pr_*, ale z wyłączoną odpornością na prognozy. Kod jest udostępniany wariantowi odpornem na prognozy. W jądrze w wersji 5.10 DRBG o najwyższym priorytecie to drbg_nopr_hmac_sha256. W jądrze w wersji 5.15 lub nowszej jest to drbg_pr_hmac_sha512.
jitterentropy_rng	jitterentropy_rng	Nie	Jitter RNG w wersji 2.2.0 (jądro w wersji 6.1 lub starszej) lub 3.4.0 (jądro w wersji 6.6 lub nowszej). Użytkownicy tego interfejsu otrzymują własne instancje zakłóceń RNG. Nie używają 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 jądrze w wersji 5.15 lub nowszej.
cbcmac(aes)	cbcmac-aes-neon, cbcmac-aes-ce	Nie
essiv(cbc(aes),sha256)	essiv-cbc-aes-sha256-neon, essiv-cbc-aes-sha256-ce	Nie

Skompiluj moduł na podstawie źródła

Na Androida 14 i nowszego (w tym android-mainline), utwórz moduł fips140.ko ze źródła za pomocą tych poleceń.

• Tworzenie w Bazelu:

  tools/bazel run //common:fips140_dist
  

• Kompilacja z wykorzystaniem build.sh (starszej wersji):

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

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

Wskazówki dla użytkowników

Wskazówki dla dyrektora ds. kryptowalut

Aby można było obsługiwać moduł jądra, system operacyjny musi być ograniczony do w trybie działania pojedynczego operatora. Android obsługuje to automatycznie przez wykorzystanie w procesorze sprzętu do zarządzania pamięcią.

Moduł jądra nie może być zainstalowany oddzielnie; jest częścią oprogramowania urządzenia i automatycznie załadowany podczas uruchamiania. Działa ona tylko zatwierdzony tryb działania.

Crypto Officer może uruchomić autotesty w dowolnym momencie, uruchamiając je ponownie urządzenia.

Wskazówki dla użytkownika

Użytkownikiem modułu jądra są inne komponenty jądra, które muszą do algorytmów kryptograficznych. Moduł jądra nie udostępnia dodatkowej logiki wykorzystanie algorytmów i nie przechowuje żadnych parametrów poza czasem potrzebne do przeprowadzenia operacji kryptograficznej.

Użycie algorytmów do celów zgodności z FIPS jest ograniczone do zatwierdzonych za pomocą algorytmów. W celu spełnienia wymogów standardu FIPS 140-3 „service wskaźniki” funkcji moduł zawiera funkcję fips140_is_approved_service, która wskazuje, czy algorytm został zatwierdzony.

Błędy autotestu

W przypadku niepowodzenia autotestu moduł jądra powoduje uruchomienie panik i urządzenie nie będzie dalej uruchamiać się. Jeśli ponowne uruchomienie urządzenia nie rozwiąże problemu, urządzenie musi uruchomić się w trybie przywracania, aby naprawić błąd problem, ponownie instalując urządzenie.