Najczęstsze wzorce błędnego użycia kryptografii

Tryb Electronic Codebook (ECB) szyfruje każdy blok niezależnie, używając tego samego klucza. Identyczne bloki tekstu jawnego dają identyczne bloki szyfrogramu. Klasyczną demonstracją jest „pingwin ECB”: zaszyfrowanie obrazu bitmapowego w trybie ECB zachowuje strukturę obrazu na poziomie bloków, dzięki czemu kontur pingwina pozostaje wyraźnie widoczny w szyfrogramie. Tryb ECB nie zapewnia bezpieczeństwa semantycznego i nigdy nie powinien być używany do żadnego praktycznego celu związanego z szyfrowaniem.

Implementowanie prymitywów kryptograficznych od podstaw jest jedną z najbardziej niebezpiecznych praktyk w tworzeniu oprogramowania. Kryptografia wymaga bezbłędnej poprawności w warunkach działania przeciwnika: subtelny wyciek czasowy, błąd o jeden w dopełnieniu lub niezrozumienie wymagań bezpieczeństwa mogą utworzyć możliwe do wykorzystania podatności, których podczas zwykłych testów nie da się odróżnić od poprawnego działania. Nawet doświadczeni kryptografowie popełniają błędy implementacyjne, dlatego twórcy aplikacji powinni korzystać wyłącznie z dobrze zbadanych bibliotek.

Od 2004 roku znane są praktyczne ataki łamiące odporność kolizyjną MD5; utworzenie dwóch plików o tym samym skrócie MD5 jest obliczeniowo banalne. Ataki kolizyjne na SHA-1 zostały praktycznie zademonstrowane w 2017 roku przez atak SHAttered firmy Google, w ramach którego utworzono dwa pliki PDF o tym samym skrócie SHA-1. Żadnego z tych algorytmów nie należy używać do celów związanych z bezpieczeństwem: podpisów cyfrowych, integralności danych, przechowywania haseł ani HMAC. We współczesnych wdrożeniach należy używać SHA-256, SHA-3 lub BLAKE2.

Używanie time() lub innych przewidywalnych wartości do zainicjowania generatora pseudolosowego jest krytyczną podatnością, gdy wynik PRNG służy do celów związanych z bezpieczeństwem. Napastnik, który zna przybliżony czas wygenerowania klucza, może metodą siłową przeszukać przestrzeń ziaren (wszystkie możliwe znaczniki czasu w niewielkim przedziale) i odzyskać klucz. Klasycznym przykładem są wczesne wersje Netscape, które inicjowały generowanie kluczy SSL na podstawie czasu i identyfikatora procesu, a obie te wartości były możliwe do ustalenia przez napastnika na tej samej maszynie.

rand() w języku C, java.util.Random oraz moduł random języka Python używają deterministycznych generatorów liniowych kongruencyjnych lub algorytmu Mersenne Twister, zaprojektowanych z myślą o jakości statystycznej w symulacjach, a nie o bezpieczeństwie. Napastnik, który zaobserwuje wystarczająco wiele wyników tych generatorów, może odtworzyć ich stan wewnętrzny i przewidywać wszystkie przyszłe wyniki. Do celów związanych z bezpieczeństwem należy używać dostarczanych przez system operacyjny kryptograficznie bezpiecznych generatorów liczb pseudolosowych (CSPRNG): secrets.token_bytes() w Pythonie, crypto.randomBytes() w Node.js lub /dev/urandom w systemie Linux.

Szyfrowanie bez uwierzytelniania zapewnia wyłącznie poufność, a nie integralność. Napastnik, który nie może odczytać tekstu jawnego, nadal może modyfikować szyfrogram, potencjalnie powodując przewidywalne zmiany tekstu jawnego, zwłaszcza w trybie CTR lub CBC. Ta podatność na modyfikacje umożliwia ataki: napastnik przechwytujący zaszyfrowaną transakcję bankową może odwrócić wybrane bity, aby zmienić kwotę przelewu lub numer rachunku odbiorcy, nie znając tekstu jawnego. Należy zawsze używać szyfrowania uwierzytelnionego (AEAD).

Zakodowanie kluczy szyfrujących lub wektorów inicjalizujących w kodzie źródłowym na stałe jest krytyczną podatnością. Kod źródłowy często trafia do repozytoriów kontroli wersji, czasami publicznych. Nawet w prywatnych repozytoriach klucz zna każda osoba mająca dostęp do kodu. Zakodowane na stałe klucze oznaczają, że wszystkie instancje używają tego samego klucza, a jego rotacja wymaga ponownego wdrożenia. Klucze należy przechowywać w zmiennych środowiskowych, systemach zarządzania sekretami (HashiCorp Vault, AWS Secrets Manager) lub modułach bezpieczeństwa sprzętowego.

Używanie tego samego wektora inicjalizującego podczas wielu operacji szyfrowania z użyciem tego samego klucza tworzy poważne podatności. W trybie CTR ponowne użycie IV powoduje powstanie tego samego strumienia kluczowego, co umożliwia odzyskanie tekstu jawnego za pomocą operacji XOR. W trybie CBC ponowne użycie IV pozwala napastnikowi wykryć, kiedy dwie wiadomości rozpoczynają się od tych samych bloków tekstu jawnego. W trybie GCM ponowne użycie nonce ma katastrofalne skutki (zobacz lekcję o ponownym użyciu nonce). Dla każdej operacji szyfrowania należy generować nowy losowy IV i dołączać go na początku szyfrogramu, aby przechowywać go wraz z kontekstem odszyfrowywania.

Przechowywanie haseł po zastosowaniu funkcji skrótu MD5, SHA-256 lub dowolnej innej szybkiej kryptograficznej funkcji skrótu jest niewystarczające. Współczesne procesory GPU mogą obliczać miliardy skrótów SHA-256 na sekundę, dzięki czemu ataki siłowe offline na skradzione bazy skrótów są trywialnie szybkie. Haszowanie haseł wymaga specjalnie do tego przeznaczonych, powolnych funkcji wymagających dużej ilości pamięci: bcrypt, scrypt lub Argon2id. Zostały one zaprojektowane tak, aby ataki siłowe były kosztowne nawet przy użyciu wyspecjalizowanego sprzętu, dzięki czemu ataki offline stają się obliczeniowo niewykonalne.

Wyłączenie weryfikacji certyfikatów SSL/TLS (ustawienie ssl.CERT_NONE w Pythonie, przekazanie -k do curl lub ustawienie trustAllCerts=true w Androidzie) eliminuje ochronę przed atakami typu man-in-the-middle. Napastnik może przedstawić dowolny certyfikat i przechwycić całą komunikację. Praktyka ta pojawia się w środowiskach programistycznych w celu pomijania błędów związanych z certyfikatami samopodpisanymi, ale często pozostaje także w środowisku produkcyjnym. Należy zawsze stosować prawidłową weryfikację certyfikatów i właściwie naprawiać leżące u podstaw problemy z certyfikatami.

Funkcje kryptograficzne sygnalizują błędy za pomocą wartości zwracanych lub wyjątków. Ignorowanie tych informacji pozwala kontynuować działanie z nieprawidłowym stanem: po odszyfrowaniu mogły powstać bezsensowne dane, weryfikacja mogła się nie powieść albo generowanie klucza mogło zakończyć się błędem. W interfejsach API opartych na C, takich jak OpenSSL, ignorowanie wartości zwracanych jest szczególnie niebezpieczne, ponieważ program może kontynuować działanie z niezainicjalizowaną pamięcią. Należy sprawdzać każdą wartość zwracaną przez funkcje kryptograficzne i bezpiecznie obsługiwać błędy.

Dlaczego tryb ECB (Electronic Codebook) uznaje się za niebezpieczny podczas szyfrowania danych?

Najważniejsze wzorce niewłaściwego użycia, których należy unikać: nigdy nie używać trybu ECB (wyciek wzorców bloków), nigdy samodzielnie nie implementować prymitywów kryptograficznych, odrzucać MD5 i SHA-1 do celów związanych z bezpieczeństwem, inicjować PRNG za pomocą CSPRNG, a nie time(), używać CSPRNG do całej losowości wrażliwej z punktu widzenia bezpieczeństwa, zawsze uwierzytelniać zaszyfrowane dane (AEAD), nigdy nie kodować kluczy ani IV na stałe, generować nowy IV dla każdej operacji szyfrowania, używać Argon2id do haseł zamiast szybkich funkcji skrótu, zawsze weryfikować certyfikaty TLS oraz sprawdzać każdą wartość zwracaną przez funkcje kryptograficzne.