Forfattere: Jennifer Brady og Apurva Varalikar

Indtil videre har vi lagt den forventede tidslinje for den planlagte FIPS 140-3-overgang (nøgle FIPS 140-3 datoer), og de nøgleudtryk og definitioner, du har brug for at vide, (del 1: nøgleudtryk og definitioner). I dag fortsætter vores blog-serie med forskellene mellem FIPS 140-2 og FIPS 140-3. Dette indlæg adresserer de enkelte sektioner i ISO / IEC 19790 / ISO / IEC 24759 (som vi vil henvise til som FIPS 140-3) og identificerer, hvordan de kortlægges til og adskiller sig fra sektionerne i FIPS 140-2 standard og nuværende IG’er. . Dette indlæg vil fokusere på de første tre sektioner i FIPS 140-2 og relaterede IG’er og ISO / IEC 19790 sektionerne 7.2-7.4, nemlig kryptografisk modulspecifikation, kryptografisk modulinterfaces og roller og sektionerne Services og godkendelse.

Specifikation for kryptografisk modul

Kryptografiske moduler / kryptografiske grænser

FIPS 140-2-standarden (udstedt 2001) blev oprindeligt skrevet med den idé, at alle moduler var hardwaremoduler. Det var først senere, at forskellige typer moduler (hybrid, software og firmware) blev tilføjet og defineret i IG (IGs 1.9, 1.16 og 1.17). Desuden begrænsede FIPS 140-2 IG 1.9 hybridmoduler til en FIPS 140-2 niveau 1-validering.

FIPS 140-3 vil omfatte hardwaremodul, firmwaremodul, softwaremodul, hybrid-softwaremodul og hybrid-firmwaremodul. Det definerer eksplicit hver type modul i afsnit 7.2.2 i standarden. Der er heller ingen begrænsning med hensyn til det niveau, hvormed et hybridmodul kan valideres i den nye standard. Dette er en god nyhed for leverandører med hybridmoduler, der ønsker at blive valideret på et højere niveau end niveau 1!

Funktionsmetoder

To nye udtryk; “Normal operation” og “Degraded Operation” er blevet introduceret i FIPS 140-3 19790 og bemærket i den foregående blog.

Normal operation er hvor den komplette funktionalitet i et kryptografisk modul er tilgængeligt og / eller konfigurerbart, dvs. alle algoritmer, sikkerhedsfunktioner og tjenester.

Degraderet operation er, hvor en delmængde af funktionaliteten er tilgængelig og / eller kan konfigureres som et resultat af omkonfiguration fra en fejltilstand.

Hvis et modul understøtter en nedbrudt operation, så nedbrydes det driftstilstand kan kun indtastes, når modulet går ud af en fejltilstand. Hvad betyder det? En mekanisme eller funktion mislykkedes, og modulet har indtastet fejltilstanden og udsender en fejlindikator. Når det er i en fejltilstand, kan modulet, der understøtter denne nedbrudte operation, gå over til nedbrudt driftsform og fortsætte med at fungere med reducerede muligheder. Her er et par yderligere krav, du vil huske, når du forbereder dine moduler til den nye standard. Modulet skal give statusoplysninger, når den nedbrudte operationelle tilstand indtastes, den funktion, der mislykkedes, skal isoleres, alle betingede selvtests skal udføres, inden der anvendes en kryptografisk funktion i den nedbrudte tilstand, og sidst men ikke mindst, hvis der er et forsøg på at bruge en ikke-operationel algoritme, sikkerhedsfunktion eller proces i nedbrudt driftstilstand; tjenesterne skal angive, at et sådant forsøg blev foretaget.

Her er en yderligere kommentar til den nedbrudte operation som anført i FIPS 140-3. Den sidste sætning i afsnit 7.2.4.3 siger “Hvis modulet fejler de præoperative selvtest, skal modulet ikke gå i forringet drift.” Vent, siger du, jeg troede, at den forringede operation skulle bruges, når noget som en selvtest mislykkes, men her står det, at du ikke kan komme ind i det? Husk, du kan kun gå ind i den nedbrudte tilstand fra en fejltilstand. Så skal modulet først indtaste fejltilstanden og derefter gå ind i den nedbrudte operation, samtidig med at de andre krav, som beskrevet ovenfor, også opfyldes. 800-140 dokumenter, som CMVP frigiver i løbet af de kommende måneder for at se, om IG’erne fra FIPS 140-2, som ikke blev behandlet i ISO 19790: 2012 / ISO 24759: 2014-standarden, er adresseret i en af de specielle publikationer. Flere IG’er fra afsnit et kan blive absorberet i en webbaseret CMVP-styringsvejledning, mens andre fortsat bliver adresseret som IG’er.

Kryptografiske modulgrænseflader

Den forrige blog berørte typer af grænseflader introduceret i ISO-dokumentet (HMI: Hardware Module Interface, SFMI: Software eller Firmware Module Interface, HSMI : Hybrid Software Module Interface eller HFMI: Hybrid Firmware Module Interface), så vi vil ikke diskutere dem på dette tidspunkt. I stedet skal vi røre ved input- og outputgrænsefladerne.

Traditionelle og nye grænseflader

FIPS 140-2 og FIPS 140-3 indeholder begge: de fire logiske interface data input, data output, kontrol input og status output. FIPS 140-3 introducerer en femte grænseflade, kaldet kontroloutputgrænsefladen. Et kontroludgangsinterface bruges til output af kommandoer. Signaler og kontroldata bruges til at kontrollere eller indikere driftstilstanden. Denne kontroloutput kan være information, der sendes til et andet kryptografisk modul. Strømgrænsefladen er også en påkrævet grænseflade på alle undtagen softwaremodulerne.

Trusted Channel

Et andet koncept introduceret i FIPS 140-3 er det for en “betroet kanal”, som er svarer til FIPS 140-2 konceptet med en “betroet sti” (afsnit 4.7.4 og IG 2.1). Det er en sikker kommunikationsforbindelse mellem det kryptografiske modul og slutpunktenheden, der sender data til og modtager data fra modulet med det formål at sikre ubeskyttede CSP’er.

Svarende til FIPS 140-2 IG 2.1, er der ingen krav til brugen af en betroet kanal til sikkerhedsniveauer 1 og 2 i FIPS 140-3. FIPS 140-3 har flere krav til sikkerhedsniveauer 3 og 4, såsom: ubeskyttede CSP’er med almindelig tekst, nøglekomponenter og godkendelsesdata, som skal bruge en pålidelig kanal, når de transmitteres mellem modulet og en afsender / modtager. Den betroede kanal skal forhindre uautoriseret ændring, erstatning og afsløring. Tjenester, der bruger en pålidelig kanal, skal anvende identitetsbaseret godkendelse, og modulet skal give en statusindikator, når du bruger den pålidelige kanal.

FIPS 140-3 stiller et yderligere krav til et modul, der bruger en pålidelig kanal på sikkerhedsniveau 4, som vi ikke så i den forrige FIPS 140-2 eller IG 2.1. Et niveau 4-modul, der bruger pålidelig kanal, skal bruge multi-faktor identitetsbaseret godkendelse til alle tjenester, der bruger den betroede kanal.

Roller, tjenester og godkendelse

Roller

FIPS 140-2-standarden (afsnit 4.3.1) kræver, at et modul understøtter både en crypto officer-rolle og en brugerrolle, og understøttelsen af en vedligeholdelsesrolle var valgfri. FIPS 140-3 har stadig de samme tre roller, men kun crypto officer-rollen kræves (afsnit 7.4.2). Brugerrollen og vedligeholdelsesrollen er nu valgfri.

Services

Påkrævede tjenester

Der er tre påkrævede tjenester i FIPS 140-2-standarden: Vis status , udføre selvtest og udføre godkendt sikkerhedsfunktion (afsnit 4.3.2). De samme tre tjenester kræves i FIPS 140-3, ud over to yderligere nødvendige tjenester: Vis moduleringsversionoplysninger og udfør nulstilling (afsnit 7.4.3.1). “Vis modulets versioneringsoplysninger” kræver, at det kryptografiske modul sender modulnavnet / identifikatoren og versionsoplysninger, som kan verificeres i forhold til et valideringscertifikat. Specifikationerne for nulstillingstjenesten er defineret i afsnit 7.9.7 og vil blive behandlet i en fremtidig blog.

Bypass-service

Både FIPS 140-2 og FIPS 140-3 indeholder den valgfri bypass-tjeneste. FIPS 140-3 kalder specifikt, at en operatør, der kan konfigurere en bypass kapacitet i modulet skal påtage sig en autoriseret rolle. Selvom FIPS 140-2-standarden ikke specifikt anførte dette krav, var mest antaget godkendelse til en autoriseret rolle nødvendig, da tjenesten kunne bruges til at afsløre CSP’er og / påvirke sikkerheden for den beskyttede information af modulet (IG 3.1).

Selvinitieret kryptografisk output

En ny kapacitet, adresseret i FIPS 140-3, er “Selvinitieret kryptografisk outputkapacitet.” Her kan modulet udføre kryptografiske operationer eller andre godkendte sikkerhedsfunktioner uden operatørintervention. Kryptoofficeren kan konfigurere denne kapacitet, mens denne konfiguration kan være vedvarende over genstart. Der kræves to interne handlinger for at aktivere tjenesten, og modulet skal angive, at tjenesten er aktiveret.

Indlæsning af software / firmware

Indlæsning af software / firmware adresseres i FIPS 140-2 standard og i IG 9.7 i forbindelse med den krævede selvtest ved indlæsning af software / firmware. FIPS 140-2 adresserer det ikke som en tjeneste, som vi ser i FIPS 140-3 (afsnit 7.4.3.4). Nogle af kravene, der er angivet i dokumentet, inkluderer, at for at modulet skal forblive et valideret modul, skal enhver software / firmware, der er indlæst, valideres af en valideringsmyndighed. Her skal al dataoutput hæmmes, indtil softwaren / firmwaren er gennemført med succes; software / firmware-belastningstesten skal udføres, før koden udføres modulet må ikke udføre den indlæste kode, før de præoperative selvtest er udført med succes, og sidst men ikke mindst skal modulets versionsoplysninger opdateres for at afspejle tilføjelsen / opdateringen af softwaren / firmwaren.

Yderligere kommentar

Uautentiserede tjenester adresseres ikke eksplicit i FIPS 140-3, så vi bliver nødt til at se, om dette koncept, som er adresseret i den nuværende IG 3.1, overføres i et af SP800-140-dokumenterne. Mere om dette vil blive behandlet i fremtidige blogs.

Autentificering

FIPS 140-3 svarer til FIPS 140-2 for godkendelse på sikkerhedsniveauer 1-3: (ISO 19790: Niveau 1 – ingen godkendelseskrav; niveau 2 – minimum rollebaseret godkendelse; niveau 3 – identitetsbaseret godkendelse). Den største forskel er, at for niveau 2 blev tilføjelsen af ordet “minimum” tilføjet, som kortlægges til den afklaring, der er adresseret i IG 3.4. Niveau 4-godkendelse i den ISO-baserede FIPS 140-3-standard tager autentificering op et niveau ved ikke kun at kræve identitetsbaseret godkendelse. For niveau 4-godkendelse skal det være multi-faktor identitetsbaseret.

Et par ekstra punkter, der skal bemærkes i dette afsnit, er at FIPS 140-2 specificerede styrken af godkendelse, der kræves af modulet. Styrken er ikke defineret i FIPS 140-3, men den skal specificeres i modulets sikkerhedspolitik. Mest sandsynligt vil hver valideringsmyndighed medtage en godkendelsesstyrke i deres yderligere dokumentation.

Godkendte godkendelsesmekanismer kan ikke implementeres ved hjælp af dokumenterede procedurer eller sikkerhedsregler (dvs. politik). Det betyder, at adgangsstørrelsesbegrænsninger skal konfigureres og håndhæves af modulet. Dette kan påvirke den måde, flere af de aktuelle moduler fungerer på. , vær opmærksom på dette, når du forbereder dine moduler til ISO-krav.

Kort sagt

Der er meget at lære om forskellene mellem FIPS 140-2 og FIPS 140-3. Mens der er et utal af ligheder, er der også en hel del ændringer. Vores serie om dette emne vil fortsætte med et nyt område med hvert indlæg. Hvis du har spørgsmål, er du som altid velkommen til at kontakte os direkte. Vores team er altid her for at hjælpe.