FIPS 140 сертификация и Golang

FIPS 140 ( Federal Information Processing Standard Publication 140 )

FIPS 140 е стандарт за сертифициране на сигурността на криптографски модули, установен от NIST в САЩ. Този стандарт оценява дали даден криптографски модул или библиотека отговаря на изискванията за сигурност, дефинирани от NIST. Следователно, преминаването на FIPS 140 сертификация означава, че съответният модул притежава официално надеждна сигурност и може да бъде използван в сектори, където сигурността е от критично значение, като финанси, здравеопазване и отбрана.

След първоначалното си установяване през 1994 г., FIPS 140 е преразгледан като FIPS 140-2 през 2001 г. и като FIPS 140-3 през 2019 г. Дори и днес, много системи и приложения изискват FIPS 140-2 или FIPS 140-3 сертификация.

FIPS 140 и езиците за програмиране

Поради тези причини, криптографските модули, сертифицирани по FIPS 140, се използват като de facto стандарт в различни езици за програмиране и среди. Типични примери включват OpenSSL, BoringSSL, LibreSSL и NSS, които са най-широко използваните модули в приложения с високи изисквания за сигурност.

Повечето FIPS 140 сертифицирани модули са написани на C или C++. Поради това, езици като PHP, Python и Javascript конфигурират FIPS среда, като се свързват с тези модули чрез външни Provider модули, вместо да ги използват директно. Този подход обаче има някои ограничения.

• Проблем с несъответствието във версиите

  FIPS 140 сертификацията се предоставя само за конкретни версии. Следователно, за да се използва най-новата версия на модула, трябва да се премине отново процесът на сертифициране, и по време на този процес може да възникне несъответствие във версиите между модула, използван от приложението, и сертифицирания FIPS модул. Ако се използва неразрешена версия, средата вече не се счита за FIPS сертифицирана.

• Динамично зареждане и намаляване на производителността

  Повечето езици използват FIPS 140 сертифицираните модули, като ги зареждат като динамични библиотеки. Този подход може да доведе до намаляване на производителността по време на инициализация и изпълнение, и съществува риск от пряко въздействие върху цялостната стабилност на приложението, ако възникне проблем по време на изпълнение (runtime).

• Уязвимости в сигурността

  Както бе споменато по-горе, в структура, която интегрира външни модули като OpenSSL Provider, съществува риск уязвимостите в сигурността на този модул да се разпространят директно в приложението. Освен това, самият комуникационен слой между приложението и външния модул се превръща в допълнителна атакуема повърхност, което налага нуждата от отделен слой за сигурност за неговата защита. Това увеличава сложността и може да доведе до неочаквани уязвимости.

FIPS 140 и Golang

Поради тези причини Golang възприе различна стратегия. Go избра подход, при който FIPS 140 сертификацията се поддържа директно в официалната криптографска библиотека, без да се разчита на външни инструменти. Следователно, разработчиците не трябва да инсталират или конфигурират отделен Provider, а просто трябва да активират FIPS сертифицирания режим (GOFIPS=1), докато използват стандартния crypto пакет. При този процес се елиминира границата на комуникация с външни модули, като по този начин се подобрява сигурността, а оперирането се опростява, тъй като трябва да се разпространи само един статично компилиран бинарен файл.

FIPS 140-2 и Golang

За да постигне това, Golang вгради модула BoringCrypto, който е производно на BoringSSL, в Go runtime и получи FIPS 140-2 сертификация. BoringCrypto може да бъде активиран в специфични дистрибуции от Go версия 1.19 нататък, което позволява на Go приложенията да конфигурират FIPS 140-2 сертифицирана среда без нужда от отделни външни модули.

Въпреки това, тъй като BoringCrypto се основава на OpenSSL, все още съществува зависимост от езика C. Следователно, Go приложението не се компилира като напълно независим бинарен файл и имаше ограничението да се разпространяват необходимите C библиотеки заедно с него.

FIPS 140-3 и Golang

Go екипът подобри съществуващата стандартна Go crypto библиотека, за да отговори на спецификацията FIPS 140-3, с цел преодоляване на тези ограничения. Този подобрен модул започна да се предлага експериментално от Go версия 1.21, и в момента тече процес по сертифициране на FIPS 140-3 от NIST.Списък на модулите в процес на FIPS 140-3 оценка от NIST

Това демонстрира зрелостта на Go криптографската библиотека, което позволява на Go да предостави FIPS 140-3 сертифицирана среда като напълно независим единичен бинарен файл.

Освен това, Go екипът не просто отговаря на стандарта FIPS 140-3, но и подобрява собствената си сигурност.

• Fail Fast

  FIPS режимът на Go прилага модела за сигурност Fail Fast, като незабавно прекратява изпълнението с panic, ако бъде извикан несертифициран алгоритъм. За разлика от моделите, базирани на Provider в други езици, които оставят възможност за резервен вариант (fallback), това осигурява по-строга и ясна гаранция по отношение на сигурността и спазването на регулациите.

• Hedged Signature

  Стандартът FIPS 140-3 препоръчва използването на метода RFC6979 за ECDSA подписване. Въпреки това, Go въвежда и метода Hedged, за да реагира по-силно на атаки чрез страничен канал, които могат да възникнат по време на процеса на подписване.

• Подобрен генератор на случайни числа

  Генераторът на случайни числа на Go използва DRBG (Deterministic Random Bit Generator) в потребителското пространство, като същевременно инжектира допълнителна ентропия в ядрото на операционната система, генерирайки висококачествени случайни числа не само в потребителското пространство, но и в пространството на ядрото. Това допълнително повишава сигурността на генератора на случайни числа.