HSM

HSM (hardware security module) to dedykowane, odporne na manipulacje urządzenie, które generuje i przechowuje klucze oraz wykonuje na nich operacje kryptograficzne tak, by klucz nigdy nie opuścił sprzętu w jawnej postaci. NIST definiuje HSM jako fizyczne urządzenie obliczeniowe, które chroni klucze kryptograficzne, zarządza nimi i wykonuje przetwarzanie kryptograficzne ^[1]. Druga definicja NIST dodaje, że ochrona ma ujawniać próby manipulacji i opierać się włamaniom ^[1]. HSM może mieć postać karty rozszerzeń, urządzenia sieciowego albo usługi w chmurze.

Jak działa

Podstawowa idea to rozdzielenie klucza od aplikacji. Aplikacja nie dostaje klucza kryptograficznego, tylko prosi HSM o wykonanie operacji: podpisania, odszyfrowania albo wyliczenia MAC. Wynik wraca do aplikacji, a klucz zostaje w urządzeniu. OWASP zaleca, by klucze i operacje kryptograficzne wykonywać wewnątrz zamkniętego sejfu, a zwykły kod aplikacji nigdy nie miał bezpośredniego dostępu do kluczy ^[3].

Przebieg typowego podpisu pokazuje schemat poniżej.

RYS. 1Podpis wykonany w HSM-ie

Aplikacje rozmawiają z HSM-ami zwykle przez standardowe interfejsy. Jednym z nich jest PKCS #11, czyli Cryptoki: interfejs programistyczny do urządzeń, które przechowują informacje kryptograficzne i wykonują funkcje kryptograficzne ^[4]. Wersja 3.1 specyfikacji pochodzi z 23 lipca 2023 roku ^[4]. Specyfikacja stanowi, że jeśli klucz ma atrybut CKA_SENSITIVE ustawiony na prawdę albo CKA_EXTRACTABLE na fałsz, pewnych jego atrybutów nie da się ujawnić w postaci jawnej poza tokenem ^[4].

CKA_SENSITIVE   = CK_TRUE    klucz nie opuszcza tokenu jawnie
CKA_EXTRACTABLE = CK_FALSE   klucza nie da się wyeksportować

Rodzaje i certyfikacja

Poziom ochrony HSM-a opisuje norma FIPS 140-3, opublikowana 22 marca 2019 roku i zastępująca FIPS 140-2 ^[2]. Określa ona wymagania bezpieczeństwa dla modułów kryptograficznych na czterech rosnących poziomach ^[2]. Wymagania obejmują między innymi interfejsy, role i uwierzytelnianie, bezpieczeństwo fizyczne i testy własne ^[2]. FIPS 140-3 opiera się na normach ISO/IEC 19790:2012 i ISO/IEC 24759:2017 ^[2].

AWS opisuje swoją usługę CloudHSM jako jednodzierżawne HSM-y z walidacją FIPS 140-2 albo FIPS 140-3 poziomu 3 w trybie FIPS ^[5]. Klient ma w niej pełną kontrolę nad kluczami i algorytmami ^[5]. Dla klientów, którzy nie chcą obsługiwać własnych HSM-ów, AWS wskazuje zarządzaną usługę KMS ^[5]. Dokumentacja podkreśla też, że aplikacje korzystające ze standardowych interfejsów, takich jak PKCS #11, JCE albo CNG, można przenieść do usługi z niewielkimi zmianami ^[5]. To pokazuje rolę wspólnych interfejsów: aplikacja nie zależy od konkretnego producenta sprzętu. Osobną grupę stanowią płatnicze HSM-y, dla których AWS prowadzi oddzielną usługę ^[5].

HSM to nie to samo co moduł TPM wlutowany w płytę główną, który chroni jeden komputer. Nie jest też kluczem FIDO2, który uwierzytelnia użytkownika.

W WordPressie

Typowa strona WordPress nie korzysta z HSM-a bezpośrednio. Jej sekrety leżą w plikach. Klucze bezpieczeństwa i sole są zapisane w pliku wp-config.php ^[8]. WordPress używa czterech kluczy i czterech soli; zmiana kluczy unieważnia wszystkie ciasteczka i wymusza ponowne logowanie ^[8]. Kto przejmie odczyt tego pliku, ma klucze w jawnej postaci. Dlatego ważne jest utwardzanie pliku wp-config.php i zarządzanie sekretami.

Strona korzysta jednak z HSM-ów pośrednio, w łańcuchu zaufania. Certyfikat SSL/TLS wystawia urząd certyfikacji, którego klucze powinny być chronione sprzętowo. Let's Encrypt przechowuje klucze prywatne swojego głównego CA i pośrednich CA w HSM-ach ^[6]. Wystawianie certyfikatów z pośrednich CA pozwala trzymać główny CA offline ^[6].

Własny HSM ma sens dopiero przy większych wdrożeniach: przy podpisywaniu kodu, własnej infrastrukturze klucza publicznego albo przy szyfrowaniu danych w usługach chmurowych.

Znaczenie

Klucz trzymany w pliku albo w pamięci serwera może wyciec razem z kopią zapasową, przez błąd typu path traversal albo przez złośliwe oprogramowanie. HSM zmienia model zagrożeń. Atakujący, który przejmie serwer aplikacji, może co najwyżej zlecać operacje, dopóki ma dostęp. Nie wyniesie klucza, by używać go później.

OWASP zaleca, by wszystkie klucze były przechowywane w sejfie kryptograficznym, takim jak HSM albo odizolowana usługa kryptograficzna ^[3]. Klucze powinny być generowane w module zgodnym co najmniej z FIPS 140-2 lub 140-3 ^[3]. Sprzętowe moduły są według OWASP preferowane nad programowymi ^[3]. Wygenerowane klucze, jeśli trzeba je przenieść, powinny wędrować bezpiecznymi kanałami i być używane wyłącznie w modułach zgodnych z tymi normami ^[3]. HSM nie chroni jednak przed nadużyciem uprawnień: kto ma dostęp do interfejsu urządzenia, może zlecić podpis albo odszyfrowanie. Dlatego ważne jest uwierzytelnianie wieloskładnikowe operatorów.

Dobre praktyki

• Generować klucze wewnątrz HSM-a i oznaczać je jako nieeksportowalne ^[4].
• Kopie zapasowe kluczy szyfrować modułem z walidacją FIPS 140-2 albo 140-3 ^[3].
• Dostęp do HSM-a traktować jak dostęp uprzywilejowany; zob. zasada najmniejszych uprawnień.
• Planować rotację kluczy i procedurę ich wycofania.

Historia i przykłady

Let's Encrypt opisał w 2020 roku ceremonię wydania nowych certyfikatów głównych i pośrednich ^[7]. Zespół zbudował replikę sieci z HSM-ami i kilka razy przećwiczył ceremonię ^[7]. Właściwą ceremonię przeprowadzono 3 września w bezpiecznym centrum danych, z udziałem dyrektora wykonawczego i inżynierów ^[7].