klucz kryptograficzny

Klucz kryptograficzny to ciąg bitów sterujący działaniem algorytmu kryptograficznego: tym samym algorytmem różne klucze dają różne wyniki. Od tajności i losowości klucza zależy bezpieczeństwo szyfrowania, podpisu i uwierzytelniania wiadomości. NIST poświęca zarządzaniu kluczami osobną serię zaleceń, SP 800-57, której część pierwszą w piątej rewizji opublikował w maju 2020 roku ^[3]. Obejmuje ona rodzaje kluczy, ich ochronę i funkcje zarządzania materiałem kluczowym ^[3].

Rodzaje

OWASP dzieli klucze według zadania, które pełnią ^[1]. Zgodnie z zaleceniem NIST jeden klucz powinien służyć tylko do jednego celu, na przykład szyfrowania, uwierzytelniania, opakowywania innych kluczy albo podpisu ^[1]. Ograniczenie to zmniejsza szkody, gdy klucz zostanie ujawniony.

W kryptografii asymetrycznej klucz publiczny można ujawnić, a prywatny musi pozostać tajny. Na tej zasadzie działają podpis cyfrowy, certyfikaty SSL/TLS i logowanie kluczem SSH. CERT Polska zaleca w certyfikatach serwerów klucze RSA co najmniej 2048-bitowe albo ECDSA co najmniej 256-bitowe ^[6]. Powiązanie klucza publicznego z tożsamością właściciela zapewnia infrastruktura klucza publicznego.

Cykl życia

Klucz przechodzi przez etapy od wygenerowania do zniszczenia. OWASP wymienia generowanie, dystrybucję, przechowywanie, rotację i niszczenie ^[1]. Cykl pokazuje schemat poniżej.

RYS. 1Cykl życia klucza

Generowanie. Klucze należy tworzyć w modułach kryptograficznych zgodnych z FIPS 140-2 lub 140-3; moduły sprzętowe są według OWASP lepsze od programowych ^[1]. Klucz wyprowadzony z hasła wymaga osobnej funkcji, KDF.

Przechowywanie. OWASP zaleca, by klucze nigdy nie istniały w postaci jawnej, były trzymane w sejfach kryptograficznych, takich jak HSM, i pozostawały niedostępne dla zwykłego kodu aplikacji ^[1]. Tam, gdzie to możliwe, klucze szyfrujące należy przechowywać w innym miejscu niż zaszyfrowane dane ^[2].

Szyfrowanie kopertowe. Klucz danych (DEK) szyfruje dane, a klucz szyfrujący klucze (KEK) szyfruje klucz danych; rozdzielenie obu zwiększa ochronę ^[2].

Rotacja. Rotację kluczy przeprowadza się między innymi przy podejrzeniu ujawnienia, po upływie okresu ważności, po zaszyfrowaniu określonej ilości danych i po wykryciu słabości algorytmu ^[2].

W WordPressie

Najbliżej kluczy kryptograficznych w typowej instalacji są klucze bezpieczeństwa i sole w pliku wp-config.php. Dokumentacja opisuje tajny klucz jako hasło z elementami, które utrudniają wygenerowanie dość wielu możliwości, by przełamać zabezpieczenia ^[5]. Wymagane są cztery klucze: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY i NONCE_KEY; cztery sole są zalecane ^[5].

Wartości mają być długie, losowe i skomplikowane; nie trzeba ich pamiętać ^[5]. Dokumentacja wskazuje generator api.wordpress.org/secret-key/1.1/salt/ ^[5]. Zmiana kluczy unieważnia wszystkie istniejące ciasteczka, więc wszyscy użytkownicy muszą zalogować się ponownie ^[5]. To przydatne po włamaniu, bo odcina skradzione sesje.

define( 'AUTH_KEY',        'długi-losowy-ciąg-z-generatora' );
define( 'SECURE_AUTH_KEY', 'inny-długi-losowy-ciąg' );

Inne klucze na stronie WordPress to klucz prywatny certyfikatu TLS na serwerze, klucze SSH do wdrożeń oraz klucze API usług zewnętrznych zapisywane przez wtyczki. Te ostatnie są raczej sekretami niż kluczami w ścisłym sensie; ich ochronę opisuje zarządzanie sekretami.

Zagrożenia i skutki

Najczęstszym błędem jest klucz zapisany w kodzie. MITRE opisuje go jako słabość CWE-321: produkt używa zaszytego, niezmiennego klucza kryptograficznego ^[4]. Według MITRE przy takim kluczu niemal pewne jest, że atakujący uzyska dostęp przez dane konto, a szansa odzyskania zaszyfrowanych danych znacznie rośnie ^[4]. Ten sam problem dotyczy haseł, zob. zaszyte w kodzie hasło.

Drugim błędem jest klucz przechowywany razem z danymi. Kto wykradnie kopię bazy wraz z plikiem konfiguracyjnym, dostaje szyfrogram i klucz jednocześnie. Z tego powodu OWASP wymaga opracowania planów na wypadek ujawnienia klucza: kontaktów, metod zmiany kluczy i spisu dotkniętych zasobów ^[1].

Trzecim zagrożeniem jest słaba losowość. Klucz generowany przewidywalnym generatorem można odtworzyć bez łamania algorytmu. Dlatego OWASP wymaga generowania kluczy w certyfikowanych modułach kryptograficznych, a nie zwykłym kodem aplikacji ^[1]. Osobnym zagadnieniem jest odporność algorytmów na komputery kwantowe, którą zajmuje się kryptografia postkwantowa.

Dobre praktyki

Zalecenia OWASP i CERT Polska sprowadzają się do kilku reguł, które dotyczą także małych stron.

• Jeden klucz do jednego celu: osobny do szyfrowania, osobny do podpisu, osobny do opakowywania kluczy ^[1].
• Klucze generować w module kryptograficznym, a nie ręcznie ani prostym generatorem liczb ^[1].
• Nie zapisywać kluczy w kodzie; MITRE zauważa, że atakujący prawdopodobnie odczyta taki klucz i przejmie system ^[4].
• Przechowywać klucze poza zaszyfrowanymi danymi i poza zasięgiem zwykłego kodu aplikacji ^{[2] [1]}.
• Mieć przygotowany plan wymiany kluczy na wypadek ich ujawnienia ^[1].
• W certyfikacie serwera używać kluczy o zalecanej długości i wysyłać pełny łańcuch certyfikatów ^[6].
• Po włamaniu na stronę WordPress wygenerować nowe klucze bezpieczeństwa i sole; zmiana unieważnia wszystkie ciasteczka logowania ^[5].

Historia i przykłady

MITRE przytacza przy CWE-321 kilka podatności z zaszytymi kluczami ^[4]:

• CVE-2022-30271: terminal zdalny z zaszytym prywatnym kluczem SSH, prawdopodobnie instalowanym domyślnie ^[4];
• CVE-2020-10884: usługa routera Wi-Fi z zaszytym kluczem szyfrującym, pozwalającym uzyskać dostęp roota ^[4];
• CVE-2014-2198: produkt komunikacyjny z zaszytym prywatnym kluczem SSH dającym dostęp do konta root ^[4].

Przypadek szyfrowanych pendrive’ów z 2010 roku pokazuje z kolei znaczenie ochrony samego klucza. Dysk był szyfrowany losowym kluczem, który z kolei był szyfrowany kluczem wyprowadzonym z hasła użytkownika ^[7]. Mimo to oprogramowanie wysyłało do urządzenia to samo polecenie odszyfrowania niezależnie od hasła, a certyfikacja FIPS nie obejmowała zarządzania kluczami ^[7].