Författare: Jennifer Brady och Apurva Varalikar

Hittills har vi lagt fram den förväntade tidslinjen för den planerade FIPS 140-3-övergången (Key FIPS 140-3 datum), och de nyckeltermer och definitioner du behöver veta, (del 1: nyckeltermer och definitioner). Idag fortsätter vår bloggserie med skillnaderna mellan FIPS 140-2 och FIPS 140-3. Det här inlägget adresserar de enskilda avsnitten i ISO / IEC 19790 / ISO / IEC 24759 (som vi kommer att hänvisa till som FIPS 140-3) och identifierar hur de kartläggs till och skiljer sig från sektionerna i FIPS 140-2-standard och nuvarande IG . Det här inlägget kommer att fokusera på de tre första avsnitten i FIPS 140-2 och relaterade IG: er, och ISO / IEC 19790-avsnitten 7.2-7.4, nämligen kryptografisk modulspecifikation, kryptografiska modulgränssnitt och roller respektive sektionerna Tjänster och autentisering.

Specifikation av kryptografimodul

Typer av kryptografiska moduler / kryptografiska gränser

FIPS 140-2-standarden (utgiven 2001) skrevs ursprungligen med tanken att alla moduler var hårdvarumoduler. Det var först senare som olika typer av moduler (hybrid, mjukvara och firmware) lades till och definierades i IG (IGs 1.9, 1.16 och 1.17). Dessutom begränsade FIPS 140-2 IG 1.9 hybridmoduler till FIPS 140-2 nivå 1-validering.

FIPS 140-3 kommer att inkludera hårdvarumodulen, firmwaremodulen, mjukvarumodulen, hybridmjukvarumodulen och hybrid-firmware-modul. Den definierar uttryckligen varje typ av modul i avsnitt 7.2.2 i standarden. Det finns inte heller några begränsningar för nivån vid vilken en hybridmodul kan valideras i den nya standarden. Det här är bra nyheter för leverantörer med hybridmoduler som vill valideras på en högre nivå än nivå 1!

Funktionsmetoder

Två nya termer; ”Normal operation” och ”Degraded Operation” har introducerats i FIPS 140-3 19790 och noterats i föregående blogg.

Normal operation är där den fullständiga funktionen för en kryptografisk modul är tillgänglig och / eller konfigurerbar, dvs. alla algoritmer, säkerhetsfunktioner och tjänster.

Degraded Operation är där en delmängd av funktionaliteten är tillgänglig och / eller kan konfigureras som ett resultat av omkonfigurering från ett felläge.

Om en modul stöder en försämrad operation, så försämras den driftläge kan endast anges när modulen har nått ett felläge. Vad betyder det? En mekanism eller funktion har misslyckats och modulen har gått in i felläget och matar ut en felindikator. En gång i ett felläge kan modulen som stöder denna försämrade operation övergå till försämrat driftläge och fortsätta att fungera med reducerad kapacitet. Här är några ytterligare krav som du vill komma ihåg när du förbereder dina moduler för den nya standarden. Modulen måste tillhandahålla statusinformation när det försämrade driftläget går in, den funktion som misslyckades måste isoleras, alla villkorliga självtester måste utföras innan någon kryptografisk funktion används i det degraderade läget, och sist men inte minst, om det finns ett försök att använda en icke-operativ algoritm, säkerhetsfunktion eller process i det försämrade driftläget; tjänsterna måste ange att ett sådant försök gjordes.

Här är ytterligare en kommentar om den försämrade operationen enligt FIPS 140-3. Den sista meningen i avsnitt 7.2.4.3 säger ”Om modulen misslyckas med de föroperativa självtesterna, ska modulen inte gå i försämrad drift.” Vänta, säger du, jag trodde att den försämrade operationen skulle användas när något som ett självtest misslyckades, men här står det att du inte kan gå in i det? Kom ihåg att du bara kan gå in i det försämrade läget från ett felläge. måste modulen först ange felläget och sedan gå in i den försämrade operationen, samtidigt som de övriga kraven som beskrivs ovan uppfylls.

Ytterligare begrepp

Håll ett öga på SP 800-140 dokument som CMVP kommer att släppa under de kommande månaderna för att se om IG: er från FIPS 140-2 som inte behandlades i ISO 19790: 2012 / ISO 24759: 2014-standarden behandlas i en av de speciella publikationerna. Flera IG från avsnitt ett kan absorberas i en webbaserad CMVP-hanteringshandbok, medan andra kan fortsätta att adresseras som IG: er.

Kryptografiska modulgränssnitt

Den tidigare bloggen berörde typerna av gränssnitt infördes i ISO-dokumentet (HMI: Hardware Module Interface, SFMI: Software or Firmware Module Interface, HSMI : Hybrid Software Module Interface eller HFMI: Hybrid Firmware Module Interface), så vi kommer inte att diskutera dem just nu. Istället kommer vi att beröra ingångs- och utgångsgränssnitten.

Traditionella och nya gränssnitt

FIPS 140-2 och FIPS 140-3 innehåller båda: de fyra logiska gränssnittsdataingångarna, datautmatningen, styringången och statusutmatningen. FIPS 140-3 introducerar ett femte gränssnitt, kallat kontrollutgångsgränssnittet. Ett gränssnitt för kontrollutgång används för utmatning av kommandon. Signaler och styrdata används för att styra eller indikera driftstillståndet. Denna kontrollutgång kan vara information som skickas till en annan kryptografisk modul. Strömgränssnittet är också ett gränssnitt som krävs på alla utom mjukvarumodulerna.

Trusted Channel

Ett annat koncept som introduceras i FIPS 140-3 är det för en ”betrodd kanal” som är liknar FIPS 140-2-konceptet med en ”betrodd väg” (avsnitt 4.7.4 och IG 2.1). Det är en säker kommunikationslänk mellan den kryptografiska modulen och slutpunktenheten som skickar data till och tar emot data från modulen i syfte att säkra oskyddade CSP: er.

Liknar FIPS 140-2 IG 2.1, det finns inga krav för användning av en pålitlig kanal för säkerhetsnivå 1 och 2 i FIPS 140-3. FIPS 140-3 har flera krav på säkerhetsnivå 3 och 4, till exempel: oskyddade CSP: er för enkel text, nyckelkomponenter och autentiseringsdata, som behöver använda en pålitlig kanal när den överförs mellan modulen och en avsändare / mottagare. Den betrodda kanalen måste förhindra obehörig modifiering, substitution och avslöjande. Tjänster som använder en betrodd kanal måste använda identitetsbaserad autentisering, och modulen måste tillhandahålla en statusindikator när du använder den betrodda kanalen.

FIPS 140-3 ställer ett ytterligare krav för en modul som använder en betrodd kanal på säkerhetsnivå 4 som vi inte såg i tidigare FIPS 140-2 eller IG 2.1. En nivå 4-modul som använder pålitlig kanal måste använda identitetsbaserad autentisering med flera faktorer för alla tjänster som använder den betrodda kanalen.

Roller, tjänster och autentisering

Roller

FIPS 140-2-standarden (avsnitt 4.3.1) kräver att en modul stöder både en kryptoofficerroll och en användarroll, och stödet för en underhållsroll var valfritt. FIPS 140-3 har fortfarande samma tre roller, men endast kryptoofficersrollen krävs (avsnitt 7.4.2). Användarrollen och underhållsrollen är nu valfria.

Tjänster

Obligatoriska tjänster

Det finns tre tjänster som krävs i FIPS 140-2-standarden: visa status , utföra självtester och utföra godkänd säkerhetsfunktion (avsnitt 4.3.2). Samma tre tjänster krävs i FIPS 140-3, förutom ytterligare två nödvändiga tjänster: visa moduler versioneringsinformation och utför nollställning (avsnitt 7.4.3.1). ”Visa modulens versioneringsinformation” kräver att den kryptografiska modulen matar ut modulnamnet / identifieraren och versionsinformationen, som kan verifieras mot ett valideringscertifikat. Specifikationerna för nollställningstjänsten definieras i avsnitt 7.9.7 och kommer att behandlas i en framtida blogg.

Bypass-tjänst

Både FIPS 140-2 och FIPS 140-3 innehåller den alternativa förbikopplingstjänsten. FIPS 140-3 kallar specifikt att en operatör som kan konfigurera en förbikoppling kapacitet i modulen måste anta en auktoriserad roll. Även om FIPS 140-2-standarden inte specifikt angav detta krav, var de flesta antagna autentiseringar till en auktoriserad roll nödvändiga med tanke på att tjänsten kunde användas avslöja CSP och / påverka säkerheten för den skyddade information av modulen (IG 3.1).

Självinitierad kryptografisk utdata

En ny kapacitet, adresserad i FIPS 140-3, är ”Självinitierad kryptografisk utmatningsfunktion.” Här kan modulen utföra kryptografiska operationer eller andra godkända säkerhetsfunktioner utan operatörsinblandning. Kryptoofficern kan konfigurera denna funktion, medan den här konfigurationen kan vara beständig vid omstart. Två interna åtgärder krävs för att aktivera tjänsten och modulen måste indikera att tjänsten är aktiverad.

Programvaru- / firmware-belastning

Programvara / firmware-laddning adresseras i FIPS 140-2 standard, och i IG 9.7, i samband med nödvändigt självtest vid laddning av programvara / firmware. FIPS 140-2 adresserar det inte som en tjänst som vi ser i FIPS 140-3 (avsnitt 7.4.3.4). Några av kraven som anges i dokumentet inkluderar att för att modulen ska vara en validerad modul måste all programvara / firmware som laddas valideras av en valideringsmyndighet. Här måste all datautmatning spärras tills programvaran / firmware har slutförts framgångsrikt; laddningstest för programvara / firmware måste utföras innan koden körs; modulen ska inte köra den laddade koden förrän de preoperativa självtesterna har genomförts framgångsrikt och, sist men inte minst, måste modulen versionsinformation uppdateras för att återspegla tillägget / uppdateringen av programvaran / firmware.

Ytterligare kommentar

Oautentiserade tjänster adresseras inte uttryckligen i FIPS 140-3, så vi måste se om detta koncept, som behandlas i nuvarande IG 3.1, överförs i något av SP800-140-dokumenten. Mer om detta kommer att tas upp i framtida bloggar.

Autentisering

FIPS 140-3 liknar FIPS 140-2 för autentisering på säkerhetsnivåerna 1-3: (ISO 19790: Nivå 1 – inga autentiseringskrav; Nivå 2 – minsta rollbaserade autentisering; Nivå 3 – identitetsbaserad autentisering). Den största skillnaden är att för nivå 2 tillsattes tillägget av ordet ”minimum”, vilket kartläggs för att klargöra det som behandlas i IG 3.4. Nivå 4-autentisering, i den ISO-baserade FIPS 140-3-standarden, tar upp autentisering en nivå, genom att inte bara kräva identitetsbaserad autentisering. För nivå 4-autentisering måste den vara multi-factor identitetsbaserad.

Ett par ytterligare poster att notera i detta avsnitt är att FIPS 140-2 specificerade styrkan för autentisering som krävs av modulen. Styrkan definieras inte i FIPS 140-3, men den måste anges i modulens säkerhetspolicy. Troligtvis kommer varje valideringsmyndighet att inkludera en autentiseringsstyrka i deras ytterligare dokumentation.

Godkända autentiseringsmekanismer kan inte implementeras med dokumenterade procedurer eller säkerhetsregler (dvs. policy). Detta innebär att lösenordsstorleksbegränsningar måste konfigureras och tillämpas av modulen. Detta kan påverka hur flera av de nuvarande modulerna fungerar. Så , var medveten om detta när du förbereder dina moduler för ISO-krav.

Kort sagt

Det finns mycket att lära sig om skillnaderna mellan FIPS 140-2 och FIPS 140-3. Även om det finns en myriad av likheter finns det också en hel del förändringar. Vår serie om detta ämne fortsätter och behandlar ett nytt område med varje inlägg. Som alltid, om du har några frågor, är du välkommen att kontakta oss direkt. Vårt team är alltid här för att hjälpa.