Autorzy: Jennifer Brady i Apurva Varalikar

Do tej pory określiliśmy oczekiwany harmonogram planowanego przejścia na FIPS 140-3 (Klucz FIPS 140-3 Daty) oraz kluczowe terminy i definicje, które należy znać (Część 1: Kluczowe terminy i definicje). Dzisiaj nasza seria blogów obejmuje różnice między standardami FIPS 140-2 i FIPS 140-3. Ten post dotyczy poszczególnych sekcji normy ISO / IEC 19790 / ISO / IEC 24759 (którą będziemy nazywać FIPS 140-3) i określa, w jaki sposób odwzorowują one i różnią się od sekcji normy FIPS 140-2 i obecnych IG . Ten post skupi się na pierwszych trzech sekcjach FIPS 140-2 i powiązanych IG, a także na sekcjach 7.2-7.4 ISO / IEC 19790, a mianowicie – specyfikacji modułu kryptograficznego, interfejsach i rolach modułów kryptograficznych oraz sekcjach, odpowiednio, Usługi i Uwierzytelnianie.

Specyfikacja modułu kryptograficznego

Typy modułów kryptograficznych / granica kryptograficzna

Standard FIPS 140-2 (wydany w 2001 r.) został pierwotnie napisany z myślą, że wszystkie moduły były modułami sprzętowymi. Dopiero później dodano i zdefiniowano różne typy modułów (hybrydowe, oprogramowanie i oprogramowanie układowe) w IG (IG 1,9, 1,16 i 1,17). Ponadto, moduły hybrydowe FIPS 140-2 IG 1.9 ograniczone do walidacji FIPS 140-2 Poziom 1.

FIPS 140-3 będzie zawierał moduł sprzętowy, moduł oprogramowania układowego, moduł oprogramowania, moduł oprogramowania hybrydowego i moduł oprogramowania hybrydowego. Wyraźnie definiuje każdy typ modułu w sekcji 7.2.2 normy. Nie ma również ograniczeń co do poziomu, na którym moduł hybrydowy może być walidowany w nowej normie. To świetna wiadomość dla dostawców z modułami hybrydowymi, którzy chcą zostać zweryfikowani na wyższym poziomie niż poziom 1!

Tryby działania

Dwa nowe terminy; „Normalne działanie” i „Zdegradowane działanie” zostały wprowadzone w standardzie FIPS 140-3 19790 i odnotowane w poprzednim blogu.

Normalne działanie oznacza, że pełna funkcjonalność modułu kryptograficznego jest dostępna i / lub konfigurowalna, tj. wszystkie algorytmy, funkcje bezpieczeństwa i usługi.

Zdegradowana operacja ma miejsce, gdy podzbiór funkcji jest dostępny i / lub konfigurowalny w wyniku rekonfiguracji ze stanu błędu.

Jeśli moduł obsługuje zdegradowaną operację, to zdegradowana tryb pracy można wprowadzić dopiero po wyjściu modułu ze stanu błędu. Co to znaczy? Mechanizm lub funkcja uległa awarii, a moduł wszedł w stan błędu i wyświetla wskaźnik błędu. W stanie błędu moduł obsługujący tę zdegradowaną operację może przejść do awaryjnego trybu pracy i kontynuować pracę ze zmniejszonymi możliwościami. Oto kilka dodatkowych wymagań, o których będziesz chciał pamiętać podczas przygotowywania modułów do nowego standardu. Moduł musi podawać informacje o statusie w momencie wejścia w zdegradowany tryb pracy, funkcję, która się nie powiodła, należy wyodrębnić, wszystkie warunkowe autotesty muszą zostać przeprowadzone przed użyciem jakiejkolwiek funkcji kryptograficznej w trybie zdegradowanym i wreszcie, w przypadku podjęcia próby użycia nieoperacyjnego algorytmu, funkcji zabezpieczającej lub procesu w trybie pracy ograniczonej; służby muszą wskazać, że podjęto taką próbę.

Oto jeden dodatkowy komentarz dotyczący zdegradowanej operacji, jak podano w FIPS 140-3. Ostatnie zdanie w sekcji 7.2.4.3 brzmi: „Jeżeli moduł nie przejdzie pomyślnie autotestów przed uruchomieniem, moduł nie powinien przejść do pracy awaryjnej”. Cóż, czekaj, mówisz, myślałem, że zdegradowana operacja ma być używana, gdy coś takiego jak autotest się nie powiedzie, ale tutaj jest napisane, że nie możesz do niej wejść? , moduł musi najpierw wejść w stan błędu, a następnie przejść do zdegradowanej operacji, spełniając jednocześnie inne wymagania omówione powyżej.

Dodatkowe koncepcje

Zwróć uwagę na SP 800-140 dokumentów, które CMVP opublikuje w nadchodzących miesiącach, aby sprawdzić, czy IG z FIPS 140-2, które nie zostały uwzględnione w normie ISO 19790: 2012 / ISO 24759: 2014, są omówione w jednej ze specjalnych publikacji. sekcja pierwsza może zostać wchłonięta przez internetowy podręcznik zarządzania CMVP, podczas gdy inne mogą być nadal traktowane jako IG.

Interfejsy modułów kryptograficznych

W poprzednim blogu poruszono temat typów interfejsów wprowadzone w dokumencie ISO (HMI: interfejs modułu sprzętowego, SFMI: interfejs modułu oprogramowania lub oprogramowania układowego, HSMI : Hybrid Software Module Interface lub HFMI: Hybrid Firmware Module Interface), więc w tej chwili nie będziemy ich omawiać. Zamiast tego zajmiemy się interfejsami wejściowymi i wyjściowymi.

Tradycyjne i nowe interfejsy

Oba interfejsy FIPS 140-2 i FIPS 140-3 zawierają: cztery logiczne wejścia danych interfejsu, wyjście danych, wejście sterujące i wyjście statusu. FIPS 140-3 wprowadza piąty interfejs, nazywany interfejsem wyjściowym sterowania. Interfejs wyjściowy sterowania służy do wyprowadzania poleceń. Sygnały i dane sterujące służą do sterowania lub wskazywania stanu pracy. Tym wyjściem sterującym może być informacja, która jest wysyłana do innego modułu kryptograficznego. Interfejs zasilania jest również interfejsem wymaganym we wszystkich modułach oprócz oprogramowania.

Zaufany kanał

Inną koncepcją wprowadzoną w FIPS 140-3 jest „zaufany kanał”, którym jest podobny do koncepcji „zaufanej ścieżki” w FIPS 140-2 (sekcja 4.7.4 i IG 2.1). Jest to bezpieczne łącze komunikacyjne między modułem kryptograficznym a urządzeniem końcowym, które wysyła dane do modułu i odbiera dane z modułu, w celu zabezpieczenia niezabezpieczonych dostawców CSP.

Podobnie jak w FIPS 140-2 IG 2.1, nie ma wymagań dotyczących korzystania z zaufanego kanału dla poziomów bezpieczeństwa 1 i 2 w standardzie FIPS 140-3. FIPS 140-3 ma kilka wymagań dla poziomów bezpieczeństwa 3 i 4, takich jak: niezabezpieczone dostawcy CSP w postaci zwykłego tekstu, kluczowe komponenty i dane uwierzytelniające, które muszą używać zaufanego kanału podczas przesyłania między modułem a nadawcą / odbiorcą. Zaufany kanał musi zapobiegać nieautoryzowanym modyfikacjom, zastępowaniu i ujawnianiu. Usługi korzystające z zaufanego kanału muszą stosować uwierzytelnianie oparte na tożsamości, a moduł musi zapewniać wskaźnik stanu podczas korzystania z zaufanego kanału.

FIPS 140-3 stawia dodatkowy wymóg dotyczący modułu korzystającego z zaufanego kanału w poziom bezpieczeństwa 4, którego nie widzieliśmy w poprzednim FIPS 140-2 lub IG 2.1. Moduł poziomu 4 korzystający z zaufanego kanału musi używać wieloskładnikowego uwierzytelniania opartego na tożsamości dla wszystkich usług korzystających z zaufanego kanału.

Role, usługi i uwierzytelnianie

Role

Standard FIPS 140-2 (sekcja 4.3.1) wymaga, aby moduł obsługiwał zarówno rolę oficera kryptograficznego, jak i rolę użytkownika, a obsługa roli konserwacyjnej była opcjonalna. FIPS 140-3 nadal ma te same trzy role, ale wymagana jest tylko rola oficera kryptograficznego (sekcja 7.4.2). Rola użytkownika i rola konserwatora są teraz opcjonalne.

Usługi

Wymagane usługi

W standardzie FIPS 140-2 są trzy wymagane usługi: pokaż stan , przeprowadzić autotesty i zatwierdzoną funkcję bezpieczeństwa (sekcja 4.3.2). Te same trzy usługi są wymagane w standardzie FIPS 140-3, oprócz dwóch dodatkowych wymaganych usług: wyświetlanie informacji o wersji modułów i wykonywanie zerowania (sekcja 7.4.3.1). „Pokaż informacje o wersji modułu” wymaga, aby moduł kryptograficzny wyprowadził nazwę / identyfikator modułu oraz informacje o wersji, które można zweryfikować za pomocą certyfikatu walidacyjnego. Specyfikacje usługi zerowania są zdefiniowane w sekcji 7.9.7 i zostaną zaadresowane w przyszły blog.

Usługa obejścia

Zarówno FIPS 140-2, jak i FIPS 140-3 zawierają opcjonalną usługę obejścia. FIPS 140-3 wyraźnie określa, że operator, który może skonfigurować obejście zdolność w module musi przyjąć rolę autoryzowaną. Chociaż standard FIPS 140-2 nie określa konkretnie tego wymagania, większość zakładanych uwierzytelnień do roli autoryzowanej była konieczna, biorąc pod uwagę, że usługa może być wykorzystana do ujawnienia CSP i / wpłynięcia na bezpieczeństwo chronionych informacji przez moduł (IG 3.1).

Samoczynnie inicjowane wyjście kryptograficzne

Nową funkcją, o której mowa w FIPS 140-3, jest „Samoczynnie inicjowane wyjście kryptograficzne”. Tutaj moduł może wykonywać operacje kryptograficzne lub inne zatwierdzone funkcje bezpieczeństwa bez interwencji operatora. Oficer kryptograficzny może skonfigurować tę możliwość, podczas gdy ta konfiguracja może być trwała przy ponownym uruchomieniu. Aby aktywować usługę, wymagane są dwie wewnętrzne akcje, a moduł musi wskazać, że usługa jest aktywna.

Ładowanie oprogramowania / oprogramowania sprzętowego

Ładowanie oprogramowania / oprogramowania układowego jest opisane w standardzie FIPS 140-2 standard oraz w IG 9.7, w kontekście wymaganego autotestu podczas ładowania oprogramowania / oprogramowania układowego. FIPS 140-2 nie traktuje go jako usługi, jak widzimy w FIPS 140-3 (sekcja 7.4.3.4). Niektóre z wymagań określonych w dokumencie obejmują to, że aby moduł pozostał zatwierdzonym modułem, każde ładowane oprogramowanie / oprogramowanie układowe musi zostać zatwierdzone przez organ zatwierdzający. W tym przypadku wszystkie dane wyjściowe muszą zostać zablokowane, dopóki oprogramowanie / oprogramowanie układowe nie zostaną pomyślnie zakończone; test obciążenia oprogramowania / oprogramowania układowego należy przeprowadzić przed wykonaniem kodu; moduł nie wykonuje załadowanego kodu do czasu pomyślnego wykonania przedoperacyjnych autotestów oraz, co nie mniej ważne, informacje o wersji modułu muszą zostać zaktualizowane w celu odzwierciedlenia dodania / aktualizacji oprogramowania / oprogramowania sprzętowego.

Dodatkowy komentarz

Nieuwierzytelnione usługi nie są wyraźnie omówione w FIPS 140-3, więc będziemy musieli sprawdzić, czy ta koncepcja, o której mowa w obecnym IG 3.1, została przeniesiona do dowolnego dokumentu SP800-140. Więcej na ten temat zostanie omówione w przyszłych blogach.

Uwierzytelnianie

FIPS 140-3 jest podobny do FIPS 140-2 dla uwierzytelniania na poziomach bezpieczeństwa 1-3: (ISO 19790: poziom 1 – brak wymagań dotyczących uwierzytelniania; Poziom 2 – minimalne uwierzytelnianie oparte na rolach; Poziom 3 – uwierzytelnianie oparte na tożsamości). Największą różnicą jest to, że dla poziomu 2 dodano słowo „minimum”, co odpowiada wyjaśnieniu opisanemu w IG 3.4. Uwierzytelnianie na poziomie 4 w standardzie FIPS 140-3 opartym na ISO zwiększa uwierzytelnianie poziomu, nie tylko wymagając uwierzytelniania opartego na tożsamości. W przypadku uwierzytelniania na poziomie 4 musi ono być oparte na tożsamości wieloskładnikowej.

Kilka dodatkowych elementów, o których należy pamiętać w tej sekcji, to fakt, że FIPS 140-2 określił siłę uwierzytelniania wymaganą przez moduł. Siła nie jest zdefiniowana w standardzie FIPS 140-3, ale musi być określona w zasadach bezpieczeństwa modułu. Najprawdopodobniej każdy urząd walidacji umieści siłę uwierzytelniania w swojej dodatkowej dokumentacji.

Zatwierdzonych mechanizmów uwierzytelniania nie można zaimplementować za pomocą udokumentowanych procedur lub reguł bezpieczeństwa (np. polityki). Oznacza to, że moduł musi skonfigurować i wymusić ograniczenia rozmiaru hasła. Może to wpłynąć na sposób działania kilku obecnych modułów. , pamiętaj o tym, przygotowując swoje moduły do wymagań ISO.

W skrócie

Wiele można się dowiedzieć o różnicach między FIPS 140-2 i FIPS 140-3. Chociaż istnieje mnóstwo podobieństw, jest też sporo zmian. Nasza seria na ten temat będzie kontynuowana, omawiając nowy obszar w każdym poście. Jak zawsze, w razie jakichkolwiek pytań prosimy o bezpośredni kontakt. Nasz zespół jest zawsze gotowy do pomocy.