GoSudaСтруктура на FIPS 140-2 и FIPS 140-3 реализациите в стандартната криптографска библиотека на Go
FIPS 140 (Federal Information Processing Standard Publication 140)
FIPS 140 е стандарт за сертифициране на сигурността на криптографски модули, установен от американския NIST. Този стандарт оценява дали даден криптографски модул или библиотека отговаря на изискванията за сигурност, определени от NIST. Следователно преминаването на сертифициране по FIPS 140 означава, че модулът е официално призната за надежден по отношение на сигурността, и че може да бъде използван в области, където сигурността е от първостепенно значение, като финансите, здравеопазването и отбраната.
FIPS 140 е първоначално установен през 1994 г., а впоследствие е актуализиран до 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, като динамични библиотеки. Този подход може да доведе до понижена производителност при инициализация и изпълнение, а при възникване на проблем по време на работа съществува риск той пряко да повлияе на стабилността на цялото приложение.
Уязвимости в сигурността
Както беше споменато по-горе, при архитектури, които свързват външни модули, например OpenSSL Provider, уязвимостите в сигурността на модула могат пряко да се разпространят към приложението. Освен това самият комуникационен слой между приложението и външния модул се превръща в допълнителна повърхност за атака, което налага отделен защитен слой за неговата защита. Това увеличава сложността и може да породи непредвидени уязвимости.
FIPS 140 и Golang
Поради тези причини Golang избра различна стратегия. Go не разчита на външни инструменти за постигане на съответствие с FIPS 140, а предпочете да поддържа стандарта директно в своята официална криптографска библиотека. Така разработчикът не е необходимо да инсталира или конфигурира допълнителен Provider, а може да използва стандартния пакет crypto и просто да активира режима на FIPS сертифициране (GOFIPS=1). В резултат на това комуникационната граница с външните модули се премахва, което укрепва сигурността, а тъй като се разпространява единичен статично компилиран двоичен файл, експлоатацията също се опростява.
FIPS 140-2 и Golang
За тази цел Golang внедри в Go рънтайма модула BoringCrypto, производен от BoringSSL, и по този начин получи сертифициране по FIPS 140-2. BoringCrypto може да бъде активиран в определени дистрибуции, започвайки от Go версия 1.19, и чрез него Go приложенията могат да изградят среда, сертифицирана по FIPS 140-2, без допълнителни външни модули.
Въпреки това, тъй като BoringCrypto се базира на OpenSSL, зависимостта от C все още съществува. Следователно Go приложенията не се компилират като напълно самостоятелни двоични файлове и е било необходимо да се разпространяват и необходимите C библиотеки, което представляваше ограничение.
FIPS 140-3 и Golang
За да преодолее тези ограничения, екипът на Go подобри съществуващата стандартна криптографска библиотека на Go, така че да отговаря на изискванията на 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 препоръчва при ECDSA подписване да се използва методът RFC6979. Go обаче въвежда и метода Hedged, който осигурява по-силна защита срещу странични канални атаки, които могат да възникнат по време на подписването.
Усилен генератор на случайни числа
Генераторът на случайни числа в Go използва DRBG (Deterministic Random Bit Generator) в потребителското пространство, но допълнително инжектира ентропия от operating system kernel, като по този начин генерира случайни числа с висока степен на качество както в потребителското, така и в kernel пространството. Така се допълнително укрепва сигурността на генератора на случайни числа.