Tekijät: Jennifer Brady ja Apurva Varalikar

Tähän mennessä olemme laatineet suunnitellun FIPS 140-3 -siirtymän odotetun aikataulun (Key FIPS 140-3 -päivämäärät) sekä tärkeimmät termit ja määritelmät, jotka sinun on tiedettävä (osa 1: Avaintermit ja määritelmät). Tänään blogisarjamme jatkuu eroilla FIPS 140-2: n ja FIPS 140-3: n välillä. Tämä viesti koskee ISO / IEC 19790 / ISO / IEC 24759: n (jota kutsutaan FIPS 140-3: ksi) yksittäisiä osioita ja yksilöidään, miten ne kartoitetaan ja eroavat FIPS 140-2 -standardin ja nykyisten IG: n osioista. . Tämä viesti keskittyy FIPS 140-2: n ja siihen liittyvien IG: n kolmeen ensimmäiseen osioon ja ISO / IEC 19790: n osiin 7.2-7.4, nimittäin salausteknisten moduulien määrityksiin, salausmoduulien liitännöihin ja rooleihin sekä Palvelut ja todennus -osiin.

Salausmoduulien määrittely

Salausmoduulien tyypit / Salausraja

FIPS 140-2 -standardi (julkaistu 2001) kirjoitettiin alun perin ajatuksella, että kaikki moduulit olivat laitteistomoduuleja. Vasta myöhemmin erityyppiset moduulit (hybridi, ohjelmistot ja laiteohjelmistot) lisättiin ja määriteltiin IG: ssä (IG: t 1.9, 1.16 ja 1.17). Lisäksi FIPS 140-2 IG 1.9 rajoitti hybridimoduulit FIPS 140-2: n tason 1 validointiin.

FIPS 140-3 sisältää laitteistomoduulin, laiteohjelmistomoduulin, ohjelmistomoduulin, hybridi-ohjelmistomoduulin ja hybridi-laiteohjelmistomoduuli. Se määrittelee erikseen kutakin moduulityyppiä standardin kohdassa 7.2.2. Ei ole myöskään rajoituksia sille, millä tasolla hybridimoduuli voidaan validoida uudessa standardissa. Tämä on hieno uutinen toimittajille, joilla on hybridimoduuleja ja jotka haluavat validoida korkeammalla tasolla kuin taso 1!

Toimintatilat

Kaksi uutta termiä; ”Normaali toiminta” ja ”Heikentynyt toiminta” on otettu käyttöön FIPS 140-3 19790: ssä ja mainittu edellisessä blogissa.

Normaalin toiminnan avulla salausmoduulin kaikki toiminnot ovat käytettävissä ja / tai konfiguroitavissa, eli kaikki algoritmit, suojaustoiminnot ja palvelut.

Heikentynyt toiminta on toimintojen osajoukko, joka on käytettävissä ja / tai konfiguroitavissa virhetilasta tehdyn uudelleenmäärityksen seurauksena.

Jos moduuli tukee heikentynyttä toimintaa, huonontunut toiminto toimintatilaan voidaan siirtyä vasta, kun moduuli poistuu virhetilasta. Mitä tuo tarkoittaa? Mekanismi tai toiminto on epäonnistunut, ja moduuli on siirtynyt virhetilaan ja antaa virheilmoituksen. Kun virhetila on, tätä heikentynyttä toimintaa tukeva moduuli voi siirtyä huonontuneeseen toimintatilaan ja jatkaa toimintaansa rajoitetuilla ominaisuuksilla. Tässä on muutama lisävaatimus, jotka kannattaa muistaa valmistellessasi moduuleitasi uutta standardia varten. Moduulin on annettava tilatiedot, kun heikentynyt toimintatila on syötetty, epäonnistunut toiminto on eristettävä, kaikki ehdolliset itsetestit on suoritettava ennen minkään salaustoiminnon käyttöä heikentyneessä tilassa, ja viimeisenä mutta ei vähäisimpänä, jos yritetään huonossa toimintatilassa käyttää ei-operatiivista algoritmia, suojaustoimintoa tai prosessia; palveluiden on ilmoitettava, että tällainen yritys on tehty.

Tässä on vielä yksi kommentti heikentyneestä toiminnasta, kuten FIPS 140-3: ssa todetaan. Kohdan 7.2.4.3 viimeisessä virkkeessä todetaan: ”Jos moduuli epäonnistuu ennen operatiivista itsetestausta, moduuli ei saa siirtyä huonontuneeseen toimintaan.” No odota, sanot, ajattelin, että heikentynyttä toimintoa oli tarkoitus käyttää, kun jokin kuten itsetesti epäonnistui, mutta tässä sanotaan, että et voi kirjoittaa sitä? Muista, että voit siirtyä huonontuneeseen tilaan vain virhetilasta. , moduulin on ensin syötettävä virhetila ja sen jälkeen huonontunut toiminto samalla, kun se täyttää myös muut yllä mainitut vaatimukset.

Lisäkäsitteet

Pidä silmällä SP: tä 800–140 asiakirjaa, joita CMVP julkaisee tulevina kuukausina selvittääkseen, käsitelläänkö FIPS 140-2: n IG: itä, joita ei ole käsitelty ISO 19790: 2012 / ISO 24759: 2014 -standardissa, yhdessä erityisjulkaisuista. osa yksi voi imeytyä web-pohjaiseen CMVP-hallintakäsikirjaan, kun taas toisia voidaan edelleen käsitellä IG: nä.

Salausmoduulien liitännät

Edellinen blogi kosketti rajapintatyyppejä käyttöön ISO-asiakirjassa (HMI: Hardware Module Interface, SFMI: Software or Firmware Module Interface, HSMI : Hybrid Software Module Interface tai HFMI: Hybrid Firmware Module Interface), joten emme aio keskustella niistä tällä hetkellä. Sen sijaan aiomme koskettaa tulo- ja lähtöliitäntöjä.

Perinteiset ja uudet käyttöliittymät

FIPS 140-2 ja FIPS 140-3 sisältävät molemmat: neljä loogisen käyttöliittymän tietojen syöttöä, datan ulostuloa, ohjaustuloa ja tilan ulostuloa. FIPS 140-3 esittelee viidennen käyttöliittymän, jota kutsutaan ohjauslähtöliitännäksi. Ohjauslähtöliitäntää käytetään komentojen tulostamiseen. Signaaleja ja ohjaustietoja käytetään toimintatilan ohjaamiseen tai osoittamiseen. Tämä ohjauslähtö voi olla tietoa, joka lähetetään toiseen salausmoduuliin. Virtaliitäntä on myös käyttöliittymä, jota vaaditaan kaikille paitsi ohjelmistomoduuleille.

Luotettu kanava

Toinen FIPS 140-3 -käyttöjärjestelmässä käyttöön otettu käsite on ”luotettu kanava”, joka on samanlainen kuin luotettavan polun FIPS 140-2 -käsite (kohdat 4.7.4 ja IG 2.1). Se on suojattu yhteys linkitysmoduulin ja päätelaitteen välillä, joka lähettää tietoja moduulille ja vastaanottaa tietoja moduulista tarkoituksena suojata suojaamattomat palveluntarjoajat.

Samanlainen kuin FIPS 140-2 IG 2.1, luotettavan kanavan käyttöä ei vaadita FIPS 140-3: n suojaustasoilla 1 ja 2. FIPS 140-3: lla on useita vaatimuksia suojaustasoille 3 ja 4, kuten: suojaamattomat selkokieliset CSP: t, avainkomponentit ja todennustiedot, joiden on käytettävä luotettua kanavaa siirrettäessä moduulin ja lähettimen / vastaanottimen välillä. Luotetun kanavan on estettävä luvaton muokkaaminen, korvaaminen ja paljastaminen. Luotettua kanavaa käyttävien palvelujen on käytettävä henkilöllisyyspohjaista todennusta, ja moduulin on annettava tilailmaisin luotettua kanavaa käytettäessä.

FIPS 140-3 asettaa lisävaatimuksen luotettua kanavaa käyttävälle moduulille osoitteessa turvallisuustaso 4, jota emme nähneet edellisessä FIPS 140-2- tai IG 2.1 -käyttöjärjestelmässä. Luotettua kanavaa käyttävän tason 4 moduulin on käytettävä monivaiheista identiteettiin perustuvaa todennusta kaikissa luotettua kanavaa käyttävissä palveluissa.

Roolit, palvelut ja todennus

Roolit

FIPS 140-2 -standardi (osa 4.3.1) edellyttää, että moduuli tukee sekä salausvirkailijan roolia että käyttäjän roolia, ja ylläpitoroolin tuki oli valinnainen. FIPS 140-3: lla on edelleen nämä samat kolme roolia, mutta vaaditaan vain salausvirkailijan rooli (osa 7.4.2). Käyttäjärooli ja ylläpitorooli ovat nyt valinnaisia.

Palvelut

Vaaditut palvelut

FIPS 140-2 -standardissa on kolme vaadittavaa palvelua: näytä tila , suorittaa itsetestauksia ja suorittaa hyväksytty turvatoiminto (4.3.2 kohta). Näitä samoja kolmea palvelua vaaditaan FIPS 140-3 -ohjelmassa kahden vaaditun lisäpalvelun lisäksi: näytä moduulien versiotiedot ja nollaus (osa 7.4.3.1). ”Näytä moduulin versiotiedot” edellyttää, että salausmoduuli antaa moduulin nimen / tunnisteen ja versiotiedot, jotka voidaan todentaa validointivarmenteen perusteella. Nollauspalvelun tekniset tiedot on määritelty kohdassa 7.9.7 ja niihin osoitetaan tuleva blogi.

Ohituspalvelu

Sekä FIPS 140-2 että FIPS 140-3 sisältävät valinnaisen ohituspalvelun. FIPS 140-3 kehottaa erityisesti, että operaattori, joka voi määrittää ohituksen, Vaikka FIPS 140-2 -standardi ei nimenomaisesti maininnut tätä vaatimusta, suurin osa oletetusta todennuksesta valtuutettuun rooliin oli välttämätöntä, koska palvelua voitiin käyttää paljastamaan palveluntarjoajat ja / vaikuttamaan suojattujen tietojen turvallisuuteen. moduulin (IG 3.1) avulla.

Itse aloitettu salausulostus

Uusi ominaisuus, joka on osoitettu FIPS 140-3: ssa, on ”Itse aloitettu salauksen tulostusominaisuus”. Tässä moduuli voi suorittaa salaustoimintoja tai muita hyväksyttyjä turvatoimintoja ilman käyttäjän toimia. Salausvirkailija voi määrittää tämän ominaisuuden, kun taas tämä kokoonpano voi olla jatkuva uudelleenkäynnistyksen aikana. Palvelun aktivoimiseksi tarvitaan kaksi sisäistä toimintoa, ja moduulin on ilmoitettava, että palvelu on aktivoitu.

Ohjelmisto / laiteohjelmiston lataus

Ohjelmisto / laiteohjelmiston lataus on käsitelty FIPS 140-2: ssä standardissa ja IG 9.7: ssä vaaditun itsetestauksen yhteydessä ohjelmistoja / laiteohjelmistoja ladattaessa. FIPS 140-2 ei käsittele sitä palveluna, kuten näemme FIPS 140-3: ssa (kohta 7.4.3.4). Jotkut asiakirjassa esitetyistä vaatimuksista sisältävät, että jotta moduuli pysyisi validoituna moduulina, kaikkien ladattujen ohjelmistojen / laiteohjelmistojen on oltava validointivalvontaviranomaisten vahvistamia. Tällöin kaikki tiedonsiirto on estettävä, kunnes ohjelmisto / laiteohjelmisto on suoritettu onnistuneesti; ohjelmiston / laiteohjelmiston lataustesti on suoritettava ennen koodin suorittamista; moduuli ei saa suorittaa ladattua koodia ennen kuin operatiiviset itsetestit on suoritettu onnistuneesti, ja viimeisenä mutta ei vähäisimpänä moduulien versiotiedot on päivitettävä vastaamaan ohjelmiston / laiteohjelmiston lisäystä / päivitystä.

Lisäkommentit

Tunnistamattomia palveluita ei käsitellä nimenomaisesti FIPS 140-3: ssa, joten meidän on tarkastettava, siirretäänkö tätä nykyisessä IG 3.1: ssä käsiteltyä käsitettä mihin tahansa SP800-140-asiakirjaan. Lisää tästä käsitellään tulevissa blogeissa.

Authentication

FIPS 140-3 on samanlainen kuin FIPS 140-2 todentamiseen suojaustasoilla 1-3: (ISO 19790: Level 1 – ei todennusvaatimuksia; Taso 2 – vähimmäisroolipohjainen todennus; Taso 3 – identiteettiin perustuva todennus). Suurin ero on se, että tasolle 2 lisättiin sanan ”minimi” lisäys, joka yhdistyy selitykseen, jota käsitellään IG 3.4: ssä. Tason 4 todennus, ISO-pohjaisessa FIPS 140-3 -standardissa, vie todennuksen taso edellyttämällä paitsi henkilöllisyyspohjaista todennusta. Tason 4 todennusta varten sen on oltava monitekijäinen henkilöllisyyspohjainen.

Tässä osassa on huomioitava muutama lisäasio, että FIPS 140-2 määritti moduulin edellyttämän todennuksen voimakkuuden. Vahvuutta ei ole määritelty FIPS 140-3: ssa, mutta se on määritettävä moduulin suojauskäytännössä. Todennäköisesti kukin vahvistusviranomainen sisällyttää todennuksen vahvuuden lisädokumentaatioonsa.

Hyväksyttyjä todennusmekanismeja ei voida toteuttaa dokumentoiduilla menettelyillä tai suojaussäännöillä (ts. käytännöllä). Tämä tarkoittaa, että moduulin on määritettävä ja valvottava salasanan koon rajoituksia. Tämä voi vaikuttaa useiden nykyisten moduulien toimintaan. , ole tietoinen tästä valmistellessasi moduuleitasi ISO-vaatimuksia varten.

Lyhyesti

FIPS 140-2: n ja FIPS 140-3: n välillä on paljon opittavaa. Vaikka yhtäläisyyksiä on lukemattomia, muutoksia on myös melko paljon. Tätä aihetta käsittelevä sarjamme jatkuu, ja jokainen viesti koskee uutta aluetta. Kuten aina, jos sinulla on kysyttävää, ota rohkeasti yhteyttä meihin. Tiimimme on aina valmiina auttamaan.