Certyfikacja FIPS 140 i Golang
FIPS 140 ( Federal Information Processing Standard Publication 140 )
FIPS 140 to standard certyfikacji bezpieczeństwa modułów kryptograficznych, ustanowiony przez NIST w USA. Standard ten ocenia, czy dany moduł kryptograficzny lub biblioteka spełnia wymagania bezpieczeństwa zdefiniowane przez NIST. Zatem uzyskanie certyfikatu FIPS 140 oznacza, że moduł ten posiada oficjalnie wiarygodne zabezpieczenia i może być używany w sektorach, gdzie bezpieczeństwo jest kluczowe, takich jak finanse, medycyna i obronność.
FIPS 140 został pierwotnie ustanowiony w 1994 roku, następnie zmieniony na FIPS 140-2 w 2001 roku, a na FIPS 140-3 w 2019 roku. Do dziś wiele systemów i aplikacji wymaga certyfikacji FIPS 140-2 lub FIPS 140-3.
FIPS 140 a języki programowania
Z tego powodu moduły kryptograficzne z certyfikatem FIPS 140 są de facto standardem w wielu językach programowania i środowiskach. Przykładami są OpenSSL, BoringSSL, LibreSSL, NSS, które są najczęściej wykorzystywanymi modułami w aplikacjach o krytycznym znaczeniu dla bezpieczeństwa.
Większość modułów z certyfikatem FIPS 140 jest napisana w języku C lub C++. Z tego powodu języki takie jak PHP, Python, Javascript konfigurują środowisko FIPS poprzez integrację z zewnętrznymi modułami Provider, zamiast bezpośredniego użycia tych modułów. Jednak takie podejście ma pewne ograniczenia.
Problem niezgodności wersji
Certyfikat FIPS 140 jest przyznawany tylko dla konkretnej wersji. Aby użyć najnowszej wersji modułu, należy ponownie przejść proces certyfikacji, podczas którego może wystąpić niezgodność wersji między modułem używanym przez aplikację a modułem z certyfikatem FIPS. Jeśli używana jest nieautoryzowana wersja, dane środowisko przestaje być uznawane za środowisko z certyfikatem FIPS.
Dynamiczne ładowanie i spadek wydajności
Większość języków ładuje i używa modułów z certyfikatem FIPS 140 jako bibliotek dynamicznych. Ten sposób może powodować spadek wydajności podczas inicjalizacji i wykonywania, a także stwarza ryzyko bezpośredniego wpływu na stabilność całej aplikacji w przypadku problemów w czasie wykonania.
Luki w zabezpieczeniach
Jak wspomniano powyżej, w strukturach integrujących zewnętrzne moduły, takie jak OpenSSL Provider, istnieje ryzyko bezpośredniego przeniesienia luk w zabezpieczeniach tych modułów do aplikacji. Ponadto sama warstwa komunikacji między aplikacją a modułem zewnętrznym staje się dodatkową powierzchnią ataku, co wymaga oddzielnej warstwy bezpieczeństwa do jej ochrony. Zwiększa to złożoność i może prowadzić do nieoczekiwanych luk w zabezpieczeniach.
FIPS 140 a Golang
Z tych powodów Golang przyjął inną strategię. Go wybrał podejście, w którym certyfikacja FIPS 140 nie zależy od zewnętrznych narzędzi, lecz jest bezpośrednio wspierana przez oficjalną bibliotekę kryptograficzną. Dzięki temu programista nie musi instalować ani konfigurować dodatkowych Providerów, a wystarczy aktywować tryb certyfikacji FIPS (GOFIPS=1) używając standardowego pakietu crypto. W tym procesie granica komunikacji z modułami zewnętrznymi zostaje usunięta, co wzmacnia bezpieczeństwo, a operacje są uproszczone, ponieważ wystarczy dystrybuować jeden statycznie skompilowany plik binarny.
FIPS 140-2 a Golang
W tym celu Golang zintegrował moduł BoringCrypto, pochodzący z BoringSSL, z Go runtime, uzyskując certyfikat FIPS 140-2. BoringCrypto może być aktywowany w niektórych dystrybucjach od wersji Go 1.19, co pozwala aplikacjom Go na konfigurację środowiska z certyfikatem FIPS 140-2 bez konieczności użycia zewnętrznych modułów.
Jednakże, ponieważ BoringCrypto bazuje na OpenSSL, nadal istnieje zależność od języka C. Zatem aplikacje Go nie są kompilowane jako całkowicie niezależne pliki binarne i istniało ograniczenie polegające na konieczności dystrybucji wymaganych bibliotek C wraz z nimi.
FIPS 140-3 a Golang
Zespół Go, aby przezwyciężyć te ograniczenia, udoskonalił istniejącą standardową bibliotekę kryptograficzną Go, aby spełniała specyfikacje FIPS 140-3. Ten ulepszony moduł jest eksperymentalnie dostępny od wersji Go 1.21, a obecnie trwa jego ocena certyfikacyjna FIPS 140-3 przez NIST.Lista modułów w trakcie oceny NIST FIPS 140-3
To świadczy o dojrzałości biblioteki kryptograficznej Go, dzięki której Go może teraz zapewnić środowisko z certyfikatem FIPS 140-3 jako całkowicie niezależny, pojedynczy plik binarny.
Ponadto, zespół Go nie ograniczył się jedynie do spełnienia standardu FIPS 140-3, lecz samodzielnie wzmocnił bezpieczeństwo.
Fail Fast
Tryb FIPS w Go stosuje model bezpieczeństwa Fail Fast, w którym wywołanie niecertyfikowanego algorytmu natychmiast przerywa wykonanie z panic. W przeciwieństwie do modeli opartych na Providerach w innych językach, które pozostawiają możliwość fallbacku, zapewnia to bardziej rygorystyczne i jasne gwarancje w zakresie bezpieczeństwa i zgodności z przepisami.
Hedged Signature
Standard FIPS 140-3 zaleca metodę RFC6979 dla podpisów ECDSA. Jednak Go, oprócz tego, wprowadza metodę Hedged, co silniej przeciwdziała atakom typu side-channel, które mogą wystąpić podczas procesu podpisywania.
Wzmocniony generator liczb losowych
Generator liczb losowych Go używa DRBG (Deterministic Random Bit Generator) w przestrzeni użytkownika, jednocześnie dodatkowo wstrzykując entropię do jądra systemu operacyjnego, co generuje wysokiej jakości liczby losowe zarówno w przestrzeni użytkownika, jak i w przestrzeni jądra. W ten sposób dodatkowo wzmacnia się bezpieczeństwo generatora liczb losowych.