FIPS 140-2 a FIPS 140-3: What’s the Diff? – Část 2: Cítím se tak ponížená!

Autoři: Jennifer Brady a Apurva Varalikar

Dosud jsme stanovili očekávanou časovou osu plánovaného přechodu FIPS 140-3 (klíč FIPS 140-3 Data) a klíčové pojmy a definice, které potřebujete znát (Část 1: Klíčové pojmy a definice). Dnes naše série blogů pokračuje v rozdílech mezi FIPS 140-2 a FIPS 140-3. Tento příspěvek se věnuje jednotlivým částem normy ISO / IEC 19790 / ISO / IEC 24759 (kterou budeme označovat jako FIPS 140-3) a identifikuje, jak se mapují a liší od částí standardu FIPS 140-2 a aktuálních IG . Tento příspěvek se zaměří na první tři sekce FIPS 140-2 a související IG, a na ISO / IEC 19790 sekce 7.2-7.4, konkrétně – Specifikace kryptografického modulu, Rozhraní a role kryptografických modulů a sekce Služby a Ověřování.

Specifikace kryptografických modulů

Typy kryptografických modulů / kryptografická hranice

Standard FIPS 140-2 (vydaný 2001) byl původně napsán s myšlenkou, že všechny moduly byly hardwarové moduly. Teprve později byly do IG přidány a definovány různé typy modulů (hybridní, softwarové a firmwarové) (IGs 1.9, 1.16 a 1.17). Kromě toho hybridní moduly FIPS 140-2 IG 1.9 s omezeným přístupem k ověření FIPS 140-2 úrovně 1.

FIPS 140-3 bude zahrnovat hardwarový modul, modul firmwaru, softwarový modul, hybridní softwarový modul a hybridní firmwarový modul. Výslovně definuje každý typ modulu v oddíle 7.2.2 normy. Rovněž neexistuje žádné omezení, pokud jde o úroveň, na které může být hybridní modul ověřen v nové normě. To je skvělá zpráva pro prodejce s hybridními moduly, kteří chtějí být ověřeni na vyšší úrovni než na úrovni 1!

Provozní režimy

Dva nové pojmy; „Normální provoz“ a „Degradovaný provoz“ byly zavedeny v FIPS 140-3 19790 a jsou uvedeny v předchozím blogu.

Normální provoz je místo, kde je k dispozici a / nebo konfigurovatelná úplná funkce kryptografického modulu, tj. všechny algoritmy, bezpečnostní funkce a služby.

Degradovaná operace je místo, kde je k dispozici a / nebo lze konfigurovat podmnožinu funkcí v důsledku rekonfigurace z chybového stavu.

Pokud modul podporuje degradovanou operaci, pak degradovaná operace provozní režim lze zadat pouze v případě, že modul opustí chybový stav. Co to znamená? Mechanismus nebo funkce selhala a modul vstoupil do chybového stavu a vydává indikátor chyby. Jakmile je v chybovém stavu, modul, který podporuje tuto zhoršenou operaci, může přejít do zhoršeného provozního režimu a pokračovat v provozu se sníženými schopnostmi. Zde je několik dalších požadavků, které si budete pamatovat při přípravě modulů na nový standard. Modul musí poskytnout informace o stavu při vstupu do zhoršeného provozního režimu, musí být izolována funkce, která selhala, musí být provedeny všechny podmíněné autotesty, před použitím jakékoli kryptografické funkce v zhoršeném režimu, a v neposlední řadě, pokud dojde k pokusu o použití neprovozního algoritmu, bezpečnostní funkce nebo procesu v režimu zhoršené činnosti; služby musí naznačovat, že k takovému pokusu došlo.

Zde je ještě jeden komentář ke zhoršené operaci, jak je uvedeno v FIPS 140-3. Poslední věta v oddíle 7.2.4.3 uvádí: „Pokud modul neprojde předoperačními samočinnými testy, modul nesmí vstoupit do zhoršeného provozu.“ Počkejte, říkáte, myslel jsem si, že degradovaná operace se má použít, když selže něco jako autotest, ale tady se říká, že do ní nemůžete vstoupit? Pamatujte, že do degradovaného režimu můžete vstoupit pouze z chybového stavu. , modul musí nejprve zadat chybový stav a poté zadat zhoršenou operaci a zároveň splnit další požadavky, jak je uvedeno výše.

Další koncepty

Dávejte pozor na SP 800–140 dokumentů, které CMVP vydá v příštích měsících, aby zjistil, zda jsou IG v FIPS 140-2, které nebyly uvedeny v normě ISO 19790: 2012 / ISO 24759: 2014, řešeny v jedné ze zvláštních publikací. Několik IG z první část se může vstřebat do webové příručky pro správu CMVP, zatímco ostatní mohou být nadále označováni jako IG.

Rozhraní kryptografických modulů

Předchozí blog se dotýkal typů rozhraní zavedeno v dokumentu ISO (HMI: Hardware Module Interface, SFMI: Software or Firmware Module Interface, HSMI : Hybrid Software Module Interface nebo HFMI: Hybrid Firmware Module Interface), takže o nich v tuto chvíli nebudeme diskutovat. Místo toho se dotkneme vstupního a výstupního rozhraní.

Tradiční a nová rozhraní

FIPS 140-2 a FIPS 140-3 obsahují: čtyři datové vstupy logického rozhraní, datový výstup, řídicí vstup a stavový výstup. FIPS 140-3 zavádí páté rozhraní, které se nazývá ovládací výstupní rozhraní. Pro výstup příkazů se používá rozhraní výstupního řízení. Signály a řídicí data se používají k řízení nebo indikaci stavu provozu. Tímto řídicím výstupem mohou být informace, které se odesílají do jiného kryptografického modulu. Napájecí rozhraní je také rozhraním vyžadovaným pro všechny kromě softwarových modulů.

Důvěryhodný kanál

Další koncept zavedený ve FIPS 140-3 je koncept „důvěryhodného kanálu“, který je podobný konceptu „důvěryhodné cesty“ FIPS 140-2 (část 4.7.4 a IG 2.1). Jedná se o zabezpečené komunikační spojení mezi kryptografickým modulem a koncovým zařízením, které odesílá data do modulu a přijímá z něj data, s cílem zajistit nechráněné CSP.

Podobně jako FIPS 140-2 IG 2.1, ve FIPS 140-3 neexistují žádné požadavky na použití důvěryhodného kanálu pro úrovně zabezpečení 1 a 2. FIPS 140-3 má několik požadavků na úrovně zabezpečení 3 a 4, například: nechráněné prosté CSP, klíčové komponenty a autentizační data, které musí při přenosu mezi modulem a odesílatelem / přijímačem používat důvěryhodný kanál. Důvěryhodný kanál musí zabránit neoprávněným úpravám, nahrazování a zveřejňování. Služby využívající důvěryhodný kanál musí využívat autentizaci založenou na identitě a modul musí při použití důvěryhodného kanálu poskytovat indikátor stavu.

FIPS 140-3 klade další požadavek na modul využívající důvěryhodný kanál na úroveň zabezpečení 4, kterou jsme v předchozích FIPS 140-2 nebo IG 2.1 neviděli. Modul úrovně 4 využívající důvěryhodný kanál musí používat vícefaktorové ověřování založené na identitě pro všechny služby využívající důvěryhodný kanál.

Role, služby a ověřování

Role

Standard FIPS 140-2 (část 4.3.1) vyžaduje, aby modul podporoval roli kryptografického důstojníka i roli uživatele a podpora role údržby byla volitelná. FIPS 140-3 má stále stejné tři role, ale je vyžadována pouze role kryptografického důstojníka (část 7.4.2). Role uživatele a role údržby jsou nyní volitelné.

Služby

Požadované služby

Ve standardu FIPS 140-2 existují tři povinné služby: zobrazit stav , provádět autotesty a provádět schválenou bezpečnostní funkci (část 4.3.2). Tyto stejné tři služby jsou vyžadovány v FIPS 140-3, kromě dvou dalších požadovaných služeb: zobrazit informace o verzích modulů a provést nulování (část 7.4.3.1). „Zobrazit informace o verzích modulu“ vyžaduje, aby kryptografický modul vydal název / identifikátor modulu a informace o verzi, které lze ověřit pomocí ověřovacího certifikátu. Specifikace nulovací služby jsou definovány v části 7.9.7 a budou řešeny v budoucí blog.

Bypass Service

Jak FIPS 140-2, tak FIPS 140-3 obsahují volitelnou bypass službu. FIPS 140-3 specificky volá, že operátor, který může konfigurovat bypass Schopnost modulu musí převzít autorizovanou roli. Zatímco standard FIPS 140-2 tento požadavek výslovně nestanovil, většina předpokládaných autentizací k autorizované roli byla nutná, protože služba mohla být použita, odhalit CSP a / ovlivnit bezpečnost chráněných informací modulem (IG 3.1).

Kryptografický výstup s vlastní inicializací

Nová funkce, kterou řeší FIPS 140-3, je „Schopnost kryptografického výstupu s vlastním zahájením“. Zde modul může provádět kryptografické operace nebo jiné schválené bezpečnostní funkce bez jakéhokoli zásahu operátora. Krypto-důstojník může tuto schopnost konfigurovat, zatímco tato konfigurace může být při restartování trvalá. K aktivaci služby jsou vyžadovány dvě interní akce a modul musí indikovat, že je služba aktivována.

Načtení softwaru / firmwaru

Načtení softwaru / firmwaru je řešeno ve FIPS 140-2 standardu a v IG 9.7, v kontextu požadovaného autotestu při načítání softwaru / firmwaru. FIPS 140-2 jej neřeší jako službu, jak vidíme ve FIPS 140-3 (část 7.4.3.4). Některé z požadavků, které jsou uvedeny v dokumentu, zahrnují to, aby modul zůstal ověřeným modulem, veškerý načtený software / firmware musí být ověřen ověřovacím orgánem. Zde je třeba blokovat veškerý datový výstup, dokud nebude software / firmware úspěšně dokončen; před spuštěním kódu musí být proveden test načtení softwaru / firmwaru; modul nesmí spustit načtený kód, dokud nebudou úspěšně provedeny předoperační autotesty a v neposlední řadě musí být aktualizovány informace o verzích modulů, aby odrážely přidání / aktualizaci softwaru / firmwaru.

Další komentář

Neoprávněné služby nejsou ve FIPS 140-3 výslovně řešeny, takže budeme muset zjistit, zda je tento koncept, kterému se věnuje aktuální IG 3.1, přenesen do některého z dokumentů SP800-140. Více o tom se budeme zabývat v budoucích blogech.

Ověřování

FIPS 140-3 je podobný FIPS 140-2 pro ověřování na úrovních zabezpečení 1-3: (ISO 19790: Úroveň 1 – žádné požadavky na ověřování; úroveň 2 – minimální ověřování na základě rolí; úroveň 3 – ověřování na základě identity). Největší rozdíl spočívá v tom, že pro úroveň 2 bylo přidáno přidání slova „minimum“, které mapuje objasnění, které je řešeno v IG 3.4. Ověřování úrovně 4, ve standardu FIPS 140-3 založeném na ISO, ověřuje úroveň, a to nejen vyžadováním ověřování na základě identity. Pro ověřování na úrovni 4 musí být založeno na vícefaktorové identitě.

V této části je třeba poznamenat několik dalších položek, že FIPS 140-2 specifikoval sílu autentizace požadovanou modulem. Intenzita není definována v FIPS 140-3, ale musí být specifikována v zásadách zabezpečení modulu. S největší pravděpodobností každý ověřovací orgán zahrne sílu autentizace do své další dokumentace.

Schválené ověřovací mechanismy nelze implementovat zdokumentovanými postupy nebo bezpečnostními pravidly (tj. zásadami). To znamená, že modul musí konfigurovat a vynucovat omezení velikosti hesla. To může ovlivnit způsob fungování několika současných modulů. Takže , uvědomte si to při přípravě svých modulů na požadavky ISO.

Ve zkratce

O rozdílech mezi FIPS 140-2 a FIPS 140-3 se toho můžete hodně naučit. I když existuje nesčetné množství podobností, existuje také poměrně málo změn. Naše série na toto téma bude pokračovat a každým příspěvkem se budeme zabývat novou oblastí. Jako vždy, pokud máte jakékoli dotazy, neváhejte nás kontaktovat přímo. Náš tým je vždy připraven pomoci.

Write a Comment

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *