Autori: Jennifer Brady și Apurva Varalikar

Până acum, am stabilit cronologia așteptată a tranziției FIPS 140-3 planificate (cheia Date FIPS 140-3) și termenii și definițiile cheie pe care trebuie să le cunoașteți (partea 1: Termeni și definiții cheie). Astăzi, seria noastră de bloguri continuă cu diferențele dintre FIPS 140-2 și FIPS 140-3. Această postare se adresează secțiunilor individuale din ISO / IEC 19790 / ISO / IEC 24759 (la care vom face referire ca FIPS 140-3) și identifică modul în care acestea se mapează și diferă de secțiunile standardului 140-2 și IG-urile actuale . Această postare se va concentra pe primele trei secțiuni ale FIPS 140-2 și IG-urile conexe și pe ISO / IEC 19790 secțiunile 7.2-7.4, și anume – Specificația modulului criptografic, Interfețele și rolurile modulului criptografic, respectiv secțiunile Servicii și autentificare.

Specificații modul criptografic

Tipuri de module criptografice / limită criptografică

Standardul FIPS 140-2 (emis în 2001) a fost inițial scris cu ideea că toate modulele erau module hardware. Abia mai târziu au fost adăugate și definite diferite tipuri de module (hibrid, software și firmware) în IG (IGs 1.9, 1.16 și 1.17). Mai mult, FIPS 140-2 IG 1.9 a restricționat modulele hibride la o validare a nivelului FIPS 140-2.

FIPS 140-3 va include modulul hardware, modulul firmware, modulul software, modulul hibrid-software și modul hibrid-firmware. Acesta definește în mod explicit fiecare tip de modul în secțiunea 7.2.2 din standard. De asemenea, nu există nicio restricție cu privire la nivelul la care un modul hibrid poate fi validat în noul standard. Aceasta este o veste minunată pentru furnizorii cu module hibride care doresc să fie validate la un nivel mai înalt decât nivelul 1!

Moduri de operațiuni

Doi termeni noi; „Funcționare normală” și „Funcționare degradată” au fost introduse în FIPS 140-3 19790 și menționate în blogul precedent.

Funcționarea normală este locul în care funcționalitatea completă a unui modul criptografic este disponibilă și / sau configurabilă, adică toți algoritmii, funcțiile de securitate și serviciile.

Operațiunea degradată este locul în care un subset al funcționalității este disponibil și / sau configurabil ca urmare a reconfigurării dintr-o stare de eroare.

Dacă un modul acceptă o operație degradată, atunci modul de operare poate fi introdus numai după ce modulul iese din starea de eroare. Ce înseamnă asta? Un mecanism sau o funcție a eșuat, iar modulul a intrat în starea de eroare și generează un indicator de eroare. Odată ajuns într-o stare de eroare, modulul care acceptă această operațiune degradată poate trece la modul de operare degradat și poate continua să funcționeze cu capacități reduse. Iată câteva cerințe suplimentare pe care veți dori să le amintiți în timp ce vă pregătiți modulele pentru noul standard. Modulul trebuie să furnizeze informații de stare atunci când este introdus modul operațional degradat, funcția care a eșuat trebuie izolată, trebuie efectuate toate autotestele condiționate, înainte de utilizarea oricărei funcții criptografice în modul degradat și, nu în ultimul rând, dacă există o încercare, în modul de funcționare degradat, de a utiliza un algoritm neoperativ, o funcție de securitate sau un proces; serviciile trebuie să indice că s-a făcut o astfel de încercare.

Iată un comentariu suplimentar cu privire la operația degradată așa cum se menționează în FIPS 140-3. Ultima teză din secțiunea 7.2.4.3 spune „Dacă modulul nu reușește autotestele pre-operaționale, modulul nu va intra în funcțiune degradată.” Ei bine, așteptați, spuneți, am crezut că operația degradată va fi utilizată atunci când eșuează ceva precum un autotest, dar aici se spune că nu puteți intra în el? Amintiți-vă, puteți intra în modul degradat doar dintr-o stare de eroare. , modulul trebuie mai întâi să introducă starea de eroare, apoi să introducă operația degradată, îndeplinind în același timp și celelalte cerințe, așa cum s-a discutat mai sus.

Concepte suplimentare

Fii atent la SP 800-140 de documente pe care CMVP le va elibera în lunile următoare pentru a vedea dacă IG-urile din FIPS 140-2 care nu au fost abordate în standardul ISO 19790: 2012 / ISO 24759: 2014 sunt abordate într-una din publicațiile speciale. secțiunea 1 se poate absorbi într-un manual de gestionare CMVP bazat pe web, în timp ce altele pot continua să fie adresate ca IG-uri.

Interfețe modul criptografic

Blogul anterior a atins tipurile de interfețe introdus în documentul ISO (HMI: Hardware Module Interface, SFMI: Software sau Firmware Module Interface, HSMI : Hybrid Software Module Interface sau HFMI: Hybrid Firmware Module Interface), deci nu vom discuta despre acestea în acest moment. În schimb, vom atinge interfețele de intrare și ieșire.

Interfețe tradiționale și noi

FIPS 140-2 și FIPS 140-3 conțin ambele: cele patru interfețe logice de intrare de date, ieșire de date, intrare de control și ieșire de stare. FIPS 140-3 introduce o a cincea interfață, numită interfață de ieșire de control. O interfață de ieșire de control este utilizată pentru ieșirea comenzilor. Semnalele și datele de control sunt utilizate pentru a controla sau indica starea de funcționare. Această ieșire de control poate fi informație trimisă către un alt modul criptografic. Interfața de alimentare este, de asemenea, o interfață necesară pentru toate modulele software, în afară de acestea.

Trusted Channel

Un alt concept introdus în FIPS 140-3 este cel al unui „canal de încredere” care este similar conceptului FIPS 140-2 de „cale de încredere” (Secțiunea 4.7.4 și IG 2.1). Este o legătură sigură de comunicații între modulul criptografic și dispozitivul de punct final care trimite date către și primește date de la modul, cu scopul de a asigura CSP neprotejate.

Similar cu FIPS 140-2 IG 2.1, nu există cerințe pentru utilizarea unui canal de încredere pentru nivelurile de securitate 1 și 2 în FIPS 140-3. FIPS 140-3 are mai multe cerințe pentru nivelurile de securitate 3 și 4, cum ar fi: CSP-uri în text clar neprotejate, componente cheie și date de autentificare, care trebuie să utilizeze un canal de încredere atunci când sunt transmise între modul și un expeditor / receptor. Canalul de încredere trebuie să prevină modificarea, substituirea și divulgarea neautorizată. Serviciile care utilizează un canal de încredere trebuie să utilizeze autentificare bazată pe identitate, iar modulul trebuie să furnizeze un indicator de stare atunci când se utilizează canalul de încredere.

FIPS 140-3 pune o cerință suplimentară pentru un modul care utilizează un canal de încredere la nivelul de securitate 4 pe care nu l-am văzut în precedentele FIPS 140-2 sau IG 2.1. Un modul de nivel 4 care utilizează canal de încredere trebuie să utilizeze autentificare bazată pe identitate multi-factor pentru toate serviciile care utilizează canalul de încredere.

Roluri, servicii și autentificare

Roluri

Standardul FIPS 140-2 (secțiunea 4.3.1), necesită ca un modul să accepte atât rolul de ofițer criptografic, cât și rolul de utilizator, iar suportul unui rol de întreținere a fost opțional. FIPS 140-3 are încă aceleași trei roluri, dar este necesar doar rolul de ofițer cripto (secțiunea 7.4.2). Rolul utilizatorului și rolul de întreținere sunt acum opționale.

Servicii

Servicii necesare

Există trei servicii necesare în standardul FIPS 140-2: arată starea , efectuează autotesturi și îndeplinesc funcția de securitate aprobată (secțiunea 4.3.2). Aceleași trei servicii sunt necesare în FIPS 140-3, în plus față de două servicii suplimentare necesare: afișați informații de versiune a modulelor și efectuați zero (secțiunea 7.4.3.1). „Afișați informațiile de versiune a modulului” necesită ca modulul criptografic să transmită numele / identificatorul modulului și informațiile de versiune, care pot fi verificate în funcție de un certificat de validare. Specificațiile serviciului de zeroizare sunt definite în secțiunea 7.9.7 și vor fi abordate într-un viitor blog.

Bypass Service

Atât FIPS 140-2 cât și FIPS 140-3 conțin serviciul opțional de bypass. FIPS 140-3 solicită în mod specific ca un operator care poate configura un bypass capacitatea din modul trebuie să-și asume un rol autorizat. În timp ce standardul FIPS 140-2 nu prevedea în mod specific acea cerință, cea mai mare parte a presupunerii autentificării la un rol autorizat era necesară, dat fiind că serviciul ar putea fi folosit să dezvăluie CSP-urile și / să afecteze securitatea informațiilor protejate de către modul (IG 3.1).

Ieșire criptografică auto-inițiată

O nouă capacitate, adresată în FIPS 140-3, este „Capacitatea de ieșire criptografică auto-inițiată”. Aici, modulul poate efectua operațiuni criptografice sau alte funcții de securitate aprobate fără intervenția operatorului. Cripto-ofițerul poate configura această capacitate, în timp ce această configurație poate fi persistentă la reporniri. Sunt necesare două acțiuni interne pentru activarea serviciului, iar modulul trebuie să indice faptul că serviciul este activat.

Încărcare software / firmware

Încărcarea software / firmware este abordată în FIPS 140-2 standard și în IG 9.7, în contextul autotestului necesar la încărcarea software-ului / firmware-ului. FIPS 140-2 nu îl abordează ca un serviciu așa cum vedem în FIPS 140-3 (secțiunea 7.4.3.4). Unele dintre cerințele menționate în document includ că, pentru ca modulul să rămână un modul validat, orice software / firmware încărcat trebuie validat de o autoritate de validare. Aici, toate datele de ieșire trebuie să fie inhibate până când software-ul / firmware-ul se finalizează cu succes; testul de încărcare software / firmware trebuie efectuat înainte de executarea codului; modulul nu va executa codul încărcat până când autotestele pre-operaționale nu s-au executat cu succes și, nu în ultimul rând, informațiile de versiune a modulelor trebuie actualizate pentru a reflecta adăugarea / actualizarea software-ului / firmware-ului.

Comentariu suplimentar

Serviciile neautentificate nu sunt abordate în mod explicit în FIPS 140-3, deci va trebui să vedem dacă acest concept, care este abordat în actualul IG 3.1, este reportat în oricare dintre documentele SP800-140. Mai multe despre acest lucru vor fi abordate în blogurile viitoare.

Autentificare

FIPS 140-3 este similar cu FIPS 140-2 pentru autentificare la nivelurile de securitate 1-3: (ISO 19790: Nivel 1 – fără cerințe de autentificare; Nivelul 2 – autentificare minimă bazată pe rol; Nivelul 3 – autentificare bazată pe identitate). Cea mai mare diferență este că, pentru nivelul 2, a fost adăugată adăugarea cuvântului „minim”, care corespunde clarificării adresate în IG 3.4. Autentificarea de nivel 4, în standardul ISO 140-3 bazat pe ISO, preia autentificarea un nivel, nu numai că necesită autentificare bazată pe identitate. Pentru autentificarea de nivel 4, acesta trebuie să fie bazat pe identitate pe mai mulți factori.

Câteva elemente suplimentare de menționat în această secțiune sunt că FIPS 140-2 a specificat puterea de autentificare cerută de modul. Puterea nu este definită în FIPS 140-3, dar trebuie specificată în politica de securitate a modulului. Cel mai probabil, fiecare autoritate de validare va include o putere de autentificare în documentația lor suplimentară.

Mecanismele de autentificare aprobate nu pot fi puse în aplicare prin proceduri documentate sau reguli de securitate (de exemplu, politică). Aceasta înseamnă că restricțiile privind dimensiunea parolei trebuie să fie configurate și aplicate de modul. Acest lucru poate afecta modul în care funcționează mai multe module curente. Deci , fiți conștienți de acest lucru în timp ce vă pregătiți modulele pentru cerințele ISO.

Pe scurt

Există multe de învățat despre diferențele dintre FIPS 140-2 și FIPS 140-3. În timp ce există o multitudine de similitudini, există, de asemenea, destul de multe schimbări. Seria noastră despre acest subiect va continua, abordând o nouă zonă cu fiecare postare. Ca întotdeauna, dacă aveți întrebări, vă rugăm să ne contactați direct. Echipa noastră este întotdeauna aici pentru a vă ajuta.