Forfattere: Jennifer Brady og Apurva Varalikar

Så langt har vi lagt ut den forventede tidslinjen for den planlagte FIPS 140-3-overgangen (Key FIPS 140-3 datoer), og nøkkelordene og definisjonene du trenger å vite, (del 1: nøkkelord og definisjoner). I dag fortsetter bloggserien vår med forskjellene mellom FIPS 140-2 og FIPS 140-3. Dette innlegget adresserer de enkelte delene av ISO / IEC 19790 / ISO / IEC 24759 (som vi vil referere til som FIPS 140-3) og identifiserer hvordan de tilordnes og skiller seg fra delene av FIPS 140-2 standard og nåværende IG. . Dette innlegget vil fokusere på de tre første seksjonene i FIPS 140-2 og relaterte IG-er, og ISO / IEC 19790-seksjonene 7.2-7.4, nemlig kryptografisk modulspesifikasjon, kryptografisk modulgrensesnitt og roller og henholdsvis tjenester og autentisering.

Spesifikasjon av kryptografimodul

Typer av kryptografiske moduler / kryptografisk grense

FIPS 140-2-standarden (utgitt 2001) ble opprinnelig skrevet med den ideen at alle moduler var maskinvaremoduler. Det var først senere at forskjellige typer moduler (hybrid, programvare og firmware) ble lagt til og definert i IG (IGs 1.9, 1.16 og 1.17). Videre begrenset FIPS 140-2 IG 1.9 hybridmoduler til en FIPS 140-2 nivå 1-validering.

FIPS 140-3 vil omfatte maskinvaremodulen, firmwaremodulen, programvaremodulen, hybrid-programvaremodulen og hybrid-firmwaremodul. Den definerer eksplisitt hver type modul i avsnitt 7.2.2 i standarden. Det er heller ingen begrensninger for nivået der en hybridmodul kan valideres i den nye standarden. Dette er gode nyheter for leverandører med hybridmoduler som ønsker å bli validert på et høyere nivå enn nivå 1!

Operasjonsmåter

To nye termer; «Normal drift» og «Degradert drift» er introdusert i FIPS 140-3 19790 og notert i forrige blogg.

Normal drift er der den komplette funksjonaliteten til en kryptografisk modul er tilgjengelig og / eller konfigurerbar, dvs. alle algoritmer, sikkerhetsfunksjoner og tjenester.

Degradert drift er der en delmengde av funksjonaliteten er tilgjengelig og / eller kan konfigureres som et resultat av omkonfigurering fra en feiltilstand.

Hvis en modul støtter en degradert operasjon, så blir den driftsmodus kan bare angis når modulen går ut av en feiltilstand. Hva betyr det? En mekanisme eller funksjon mislyktes, og modulen har gått inn i feiltilstanden og sender ut en feilindikator. En gang i feiltilstand kan modulen som støtter denne degraderte operasjonen, gå over til degradert driftsmodus og fortsette å operere med reduserte evner. Her er et par tilleggskrav du vil huske når du forbereder modulene for den nye standarden. Modulen trenger å gi statusinformasjon når den degraderte operasjonsmodusen er inn, funksjonen som mislyktes må isoleres, alle betingede selvtester må utføres før bruk av kryptografisk funksjon i nedbrutt modus, og sist men ikke minst, hvis det er et forsøk på å bruke en ikke-operativ algoritme, sikkerhetsfunksjon eller prosess i nedbrutt driftsmodus; tjenestene må indikere at et slikt forsøk ble gjort.

Her er en ekstra kommentar til den forringede operasjonen som angitt i FIPS 140-3. Den siste setningen i avsnitt 7.2.4.3 sier «Hvis modulen mislykkes de preoperasjonelle selvtestene, skal modulen ikke gå i degradert drift.» Vel, vent, sier du, jeg trodde at den degraderte operasjonen skulle brukes når noe som en selvtest mislykkes, men her er det å si at du ikke kan gå inn i den? Husk at du bare kan gå inn i degradert modus fra en feiltilstand. , må modulen først gå inn i feiltilstand, og deretter gå inn i den degraderte operasjonen, samtidig som den oppfyller de andre kravene som diskutert ovenfor.

Tilleggskonsepter

Hold øye med SP 800-140 dokumenter som CMVP vil gi ut de neste månedene for å se om IG-ene fra FIPS 140-2 som ikke ble adressert i ISO 19790: 2012 / ISO 24759: 2014-standarden er adressert i en av spesialpublikasjonene. Flere IG-er fra seksjon en kan bli absorbert i en nettbasert CMVP-håndbok, mens andre kan fortsette å bli adressert som IG-er.

Kryptografiske modulgrensesnitt

Den forrige bloggen berørte typene grensesnitt introdusert 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 ikke til å diskutere disse på dette tidspunktet. I stedet skal vi berøre inngangs- og utgangsgrensesnittene.

Tradisjonelle og nye grensesnitt

FIPS 140-2 og FIPS 140-3 inneholder begge: de fire logiske grensesnittets datainngang, datautgang, kontrollinngang og statusutgang. FIPS 140-3 introduserer et femte grensesnitt, kalt kontrollutgangsgrensesnittet. Et kontrollutgangsgrensesnitt brukes til utdata fra kommandoer. Signaler og kontrolldata brukes til å kontrollere eller indikere driftstilstanden. Denne kontrollutgangen kan være informasjon som sendes til en annen kryptografisk modul. Strømgrensesnittet er også et grensesnitt som kreves på alle programvaremodulene unntatt.

Trusted Channel

Et annet konsept introdusert i FIPS 140-3 er det som er en «klarert kanal» som er ligner FIPS 140-2-konseptet med en «klarert bane» (avsnitt 4.7.4 og IG 2.1). Det er en sikker kommunikasjonsforbindelse mellom den kryptografiske modulen og sluttpunktenheten som sender data til og mottar data fra modulen, med sikte på å sikre ubeskyttede CSPer.

I likhet med FIPS 140-2 IG 2.1, er det ingen krav for bruk av en klarert kanal for sikkerhetsnivå 1 og 2 i FIPS 140-3. FIPS 140-3 har flere krav til sikkerhetsnivå 3 og 4, for eksempel: ubeskyttede CSPer med ren tekst, nøkkelkomponenter og autentiseringsdata, som trenger å bruke en klarert kanal når de overføres mellom modulen og en avsender / mottaker. Den pålitelige kanalen må forhindre uautorisert endring, erstatning og avsløring. Tjenester som bruker en pålitelig kanal, må bruke identitetsbasert autentisering, og modulen må gi en statusindikator når du bruker den pålitelige kanalen.

FIPS 140-3 stiller et tilleggskrav til en modul som bruker en pålitelig kanal på sikkerhetsnivå 4 som vi ikke så i forrige FIPS 140-2 eller IG 2.1. En nivå 4-modul som bruker pålitelig kanal, må bruke multi-faktor identitetsbasert autentisering for alle tjenester som bruker den pålitelige kanalen.

Roller, tjenester og autentisering

Roller

FIPS 140-2-standarden (avsnitt 4.3.1) krever at en modul støtter både en rolle som en cryptooffiser og en brukerrolle, og støtten til en vedlikeholdsrolle var valgfri. FIPS 140-3 har fremdeles de samme tre rollene, men bare rollen som cryptoofficer er nødvendig (avsnitt 7.4.2). Brukerrollen og vedlikeholdsrollen er nå valgfri.

Tjenester

Nødvendige tjenester

Det er tre nødvendige tjenester i FIPS 140-2-standarden: vis status , utføre selvtester og utføre godkjent sikkerhetsfunksjon (avsnitt 4.3.2). Disse samme tre tjenestene kreves i FIPS 140-3, i tillegg til to ekstra nødvendige tjenester: Vis modulversjonsinformasjon, og utfør nullstilling (avsnitt 7.4.3.1). «Vis modulens versjonsinformasjon» krever at den kryptografiske modulen sender ut modulnavnet / identifikatoren og versjonsinformasjonen, som kan verifiseres mot et valideringssertifikat. Spesifikasjonene til nulliseringstjenesten er definert i avsnitt 7.9.7 og vil bli adressert i en fremtidig blogg.

Bypass-tjeneste

Både FIPS 140-2 og FIPS 140-3 inneholder valgfri bypass-tjeneste. FIPS 140-3 ringer spesifikt til at en operatør som kan konfigurere en bypass evnen i modulen må påta seg en autorisert rolle. Selv om FIPS 140-2-standarden ikke spesifikt uttalte dette kravet, var de fleste antatte autentiseringer til en autorisert rolle nødvendig, siden tjenesten kunne brukes, avslører CSP og / påvirker sikkerheten til den beskyttede informasjonen av modulen (IG 3.1).

Selvinitiert kryptografisk utgang

En ny evne, adressert i FIPS 140-3, er «Selvinitiert kryptografisk utdataevne.» Her kan modulen utføre kryptografiske operasjoner eller andre godkjente sikkerhetsfunksjoner uten operatørinnblanding. Kryptooffiseren kan konfigurere denne muligheten, mens denne konfigurasjonen kan være vedvarende over omstart. Det kreves to interne handlinger for å aktivere tjenesten, og modulen må indikere at tjenesten er aktivert.

Lasting av programvare / fastvare

Lasting av programvare / fastvare adresseres i FIPS 140-2 standard, og i IG 9.7, i sammenheng med den nødvendige selvtesten når du laster inn programvare / firmware. FIPS 140-2 adresserer det ikke som en tjeneste som vi ser i FIPS 140-3 (avsnitt 7.4.3.4). Noen av kravene som er angitt i dokumentet inkluderer at for at modulen skal forbli en validert modul, må all programvare / firmware som lastes inn, valideres av en valideringsmyndighet. Her må all datautgang hemmes til programvaren / firmwaren er fullført. belastningstesten for programvare / firmware må utføres før koden kjøres; modulen skal ikke utføre den lastede koden før de preoperasjonelle selvtestene er vellykket utført, og sist, men ikke minst, må modulversjonsinformasjonen oppdateres for å gjenspeile tillegg / oppdatering av programvaren / firmware.

Ytterligere kommentar

Uautentiserte tjenester blir ikke eksplisitt adressert i FIPS 140-3, så vi må se om dette konseptet, som er adressert i dagens IG 3.1, blir overført inn i noen av SP800-140-dokumentene. Mer om dette vil bli adressert i fremtidige blogger.

Autentisering

FIPS 140-3 ligner FIPS 140-2 for autentisering på sikkerhetsnivå 1-3: (ISO 19790: Nivå 1 – ingen autentiseringskrav; Nivå 2 – minimum rollebasert autentisering; Nivå 3 – identitetsbasert autentisering). Den største forskjellen er at for nivå 2 ble tilføyelsen av ordet «minimum» lagt til, noe som kartlegges for avklaringen som er adressert i IG 3.4. Nivå 4-autentisering, i ISO-baserte FIPS 140-3-standarden, tar autentisering opp et nivå, ved ikke bare å kreve identitetsbasert autentisering. For nivå 4-autentisering må det være multi-faktor identitetsbasert.

Et par ekstra elementer å merke seg i denne delen er at FIPS 140-2 spesifiserte styrken for autentisering som kreves av modulen. Styrken er ikke definert i FIPS 140-3, men den må spesifiseres i modulens sikkerhetspolicy. Mest sannsynlig vil hver valideringsmyndighet inkludere en autentiseringsstyrke i tilleggsdokumentasjonen.

Godkjente autentiseringsmekanismer kan ikke implementeres av dokumenterte prosedyrer eller sikkerhetsregler (dvs. policy). Dette betyr at passordstørrelsesbegrensninger må konfigureres og håndheves av modulen. Dette kan påvirke måten flere av de nåværende modulene fungerer på. , vær oppmerksom på dette når du forbereder modulene dine for ISO-krav.

Kort fortalt

Det er mye å lære om forskjellene mellom FIPS 140-2 og FIPS 140-3. Selv om det er et utall likheter, er det også ganske mange endringer. Serien vår om dette emnet vil fortsette og adresserer et nytt område med hvert innlegg. Hvis du har spørsmål, er du alltid velkommen til å kontakte oss direkte. Teamet vårt er alltid her for å hjelpe.