Audytowanie i wybór zależności kryptograficznych

Wybór biblioteki kryptograficznej jest jedną z najbardziej brzemiennych w skutki decyzji dotyczących bezpieczeństwa w projekcie. Nawet programiści działający w dobrej wierze mogą, korzystając ze słabej biblioteki, stworzyć niezabezpieczone systemy. Z kolei dobrze zaprojektowana biblioteka utrudnia popełnienie katastrofalnych błędów. Proces wyboru powinien być systematyczny i uwzględniać historię bezpieczeństwa, projekt API, stan utrzymania oraz przydatność do konkretnego zastosowania.

Jednym z pierwszych pytań dotyczących każdej biblioteki kryptograficznej powinno być to, kiedy została ostatnio niezależnie poddana audytowi i jaki zakres obejmował ten audyt. Audyt sprzed pięciu lat dotyczący wersji 1.0 daje mniejszą pewność w przypadku używanej obecnie wersji 3.0. Należy szukać audytów przeprowadzonych przez renomowane firmy zajmujące się bezpieczeństwem (NCC Group, Trail of Bits, Quarkslab, Cure53), obejmujących konkretną funkcjonalność planowaną do wykorzystania. Niektóre biblioteki publikują raporty z audytów, natomiast całkowity brak audytu jest istotnym czynnikiem ryzyka.

Należy przeanalizować historię CVE biblioteki w bazie NVD (National Vulnerability Database). Warto sprawdzić: ile istnieje CVE, jakie mają oceny ważności, jakich klas podatności dotyczą (błędów logicznych, uszkodzeń pamięci czy słabości algorytmów) oraz jak szybko opiekunowie wydawali poprawki. Biblioteka z okazjonalnymi CVE, które są szybko usuwane, świadczy o sprawnym utrzymaniu. Biblioteka z licznymi CVE o wysokiej ważności lub powoli wydająca poprawki to sygnał alarmowy.

Nieutrzymywane biblioteki kryptograficzne są niebezpieczne. Należy sprawdzić datę ostatniego commitu, częstotliwość wydań oraz to, czy rozwiązywane są zgłoszenia dotyczące bezpieczeństwa. Biblioteka, której ostatni commit pochodzi sprzed trzech lat, może zawierać znane podatności, które nigdy nie zostaną naprawione. Wielkość społeczności ma znaczenie ze względu na zakres przeglądów: szeroko używane biblioteki są dokładniej analizowane przez badaczy bezpieczeństwa niż niszowe projekty.

Mniejsza powierzchnia API, narzucająca konkretne rozwiązania, jest lepsza z punktu widzenia bezpieczeństwa. Biblioteki udostępniające wiele opcji algorytmów i parametrów konfiguracyjnych stwarzają możliwości błędnej konfiguracji. Warto porównać libsodium (jedna funkcja na przypadek użycia, stały algorytm) z OpenSSL EVP (osobny wybór szyfru, trybu, rozmiaru klucza, dopełnienia i obsługi IV). Im trudniej użyć biblioteki niepoprawnie, tym lepiej nadaje się ona do projektów, w których bezpieczeństwo jest priorytetem.

W przypadku operacji obejmujących dane poufne (porównywanie kluczy, deszyfrowanie, weryfikację podpisów) implementacja musi używać algorytmów działających w czasie stałym, które nie wykonują rozgałęzień ani nie uzależniają dostępu do pamięci od wartości tajnych. Należy sprawdzić, czy dokumentacja biblioteki wyraźnie określa gwarancje stałego czasu dla wrażliwych operacji albo czy kod źródłowy korzysta z zatwierdzonych funkcji porównywania w czasie stałym. Biblioteki bez takiej gwarancji są podatne na ataki kanałem bocznym wykorzystującym czas wykonania.

Dobra biblioteka kryptograficzna powinna obsługiwać nowoczesne algorytmy i planować wycofywanie przestarzałych. Powinna oferować ChaCha20-Poly1305 lub AES-256-GCM do szyfrowania, Ed25519 lub ECDSA P-256 do podpisów, X25519 do wymiany kluczy oraz Argon2id do haszowania haseł. Biblioteki oferujące wyłącznie starsze algorytmy (DES, RC4, MD5, SHA-1) nie nadają się do nowych wdrożeń, niezależnie od pozostałych zalet.

Należy ocenić zależności pośrednie: od jakich bibliotek zależy biblioteka kryptograficzna i jaki jest stan ich bezpieczeństwa? Biblioteka bez zewnętrznych zależności, taka jak libsodium, wiąże się z minimalnym ryzykiem dotyczącym łańcucha dostaw. Biblioteka zależna od kilkunastu pakietów npm, z których każdy ma własne zależności, ma dużą powierzchnię ataku w łańcuchu dostaw. Należy sprawdzić, czy biblioteka wykorzystuje reprodukowalne kompilacje, dzięki którym można zweryfikować, że rozpowszechniany plik binarny odpowiada kodowi źródłowemu.

Branże podlegające regulacjom (opieka zdrowotna, finanse, administracja publiczna) często wymagają zwalidowanych zgodnie z FIPS 140-2 lub 140-3 modułów kryptograficznych. Walidacja FIPS jest kosztowna i czasochłonna, dlatego ma ją tylko część bibliotek. OpenSSL z dostawcą FIPS, BoringCrypto (używanym w crypto/tls języka Go) oraz niektóre biblioteki HSM mają walidację FIPS. Jeśli wdrożenie musi spełniać wymagania FIPS, istotnie ogranicza to wybór biblioteki.

Moduły bezpieczeństwa sprzętowego (HSM) i usługi chmurowe KMS często udostępniają zastrzeżone interfejsy API do operacji na kluczach. Ścisłe powiązanie aplikacji z AWS KMS lub konkretnym dostawcą HSM stwarza ryzyko uzależnienia od dostawcy. Należy ocenić, czy biblioteka udostępnia warstwy abstrakcji, takie jak integracja Tink z KMS, które umożliwiają zmianę dostawcy. Warto także uwzględnić, że jeśli dostawca HSM zakończy wsparcie lub podniesie ceny, koszty migracji mogą być znaczne.

Najważniejsza zasada przy wyborze zależności kryptograficznych brzmi: należy korzystać z dobrze znanych, szeroko stosowanych bibliotek implementujących uznane standardy i nigdy samodzielnie nie implementować prymitywów kryptograficznych. Niezależnie od tego, jak dobrze rozumieją Państwo teorię, poprawna implementacja AES, RSA, operacji na krzywych eliptycznych czy szyfrowania uwierzytelnionego w kodzie produkcyjnym jest niezwykle trudna i niemal nigdy nie uzasadnia podejmowania ryzyka w porównaniu z użyciem sprawdzonej biblioteki.

Lista kontrolna wyboru biblioteki: sprawdź zakres i raport z niedawnego niezależnego audytu, przeanalizuj historię CVE i czas reakcji na zgłoszenia poprzez wydawanie poprawek, zweryfikuj aktywne utrzymanie i zaangażowanie społeczności, wybieraj mniejsze powierzchnie API odporne na nieprawidłowe użycie, potwierdź gwarancje stałego czasu dla wrażliwych operacji, upewnij się, że biblioteka obsługuje nowoczesne algorytmy, oceń zależności w łańcuchu dostaw, sprawdź walidację FIPS, jeśli projekt podlega regulacjom, uwzględnij ryzyko uzależnienia od dostawcy KMS i zawsze korzystaj z uznanych bibliotek zamiast implementować prymitywy samodzielnie.