Autori: Jennifer Brady e Apurva Varalikar

Finora abbiamo delineato la tempistica prevista per la transizione FIPS 140-3 pianificata (chiave FIPS 140-3 Date) e i termini e le definizioni chiave che è necessario conoscere (Parte 1: Termini e definizioni chiave). Oggi, la nostra serie di blog continua con le differenze tra FIPS 140-2 e FIPS 140-3. Questo post affronta le singole sezioni della ISO / IEC 19790 / ISO / IEC 24759 (a cui ci riferiremo come FIPS 140-3) e identifica come si associano e differiscono dalle sezioni dello standard FIPS 140-2 e degli IG attuali . Questo post si concentrerà sulle prime tre sezioni di FIPS 140-2 e sugli IG correlati e sulle sezioni 7.2-7.4 dell’ISO / IEC 19790, vale a dire: le specifiche del modulo crittografico, le interfacce ei ruoli del modulo crittografico e le sezioni Servizi e Autenticazione.

Specifiche del modulo crittografico

Tipi di moduli crittografici / confine crittografico

Lo standard FIPS 140-2 (pubblicato nel 2001) è stato originariamente scritto con l’idea che tutti i moduli erano moduli hardware. Solo successivamente sono stati aggiunti e definiti diversi tipi di moduli (ibridi, software e firmware) nell’IG (IG 1.9, 1.16 e 1.17). Inoltre, FIPS 140-2 IG 1.9 ha limitato i moduli ibridi a una convalida FIPS 140-2 di livello 1.

FIPS 140-3 includerà il modulo hardware, il modulo firmware, il modulo software, il modulo software ibrido e modulo firmware ibrido. Definisce esplicitamente ogni tipo di modulo nella sezione 7.2.2 dello standard. Non vi è inoltre alcuna restrizione al livello al quale un modulo ibrido può essere convalidato nel nuovo standard. Questa è un’ottima notizia per i fornitori con moduli ibridi che desiderano essere convalidati a un livello superiore al livello 1!

Modalità operative

Due nuovi termini; “Operazione normale” e “Operazione degradata” sono state introdotte in FIPS 140-3 19790 e indicate nel blog precedente.

Operazione normale è dove la funzionalità completa di un modulo crittografico è disponibile e / o configurabile, ovvero tutti gli algoritmi, le funzioni di sicurezza e i servizi.

Operazione degradata è dove un sottoinsieme della funzionalità è disponibile e / o configurabile come risultato della riconfigurazione da uno stato di errore.

Se un modulo supporta un’operazione degradata, allora il degrado la modalità di funzionamento può essere inserita solo una volta che il modulo esce da uno stato di errore. Cosa significa? Un meccanismo o una funzione non è riuscita e il modulo è entrato in stato di errore e genera un indicatore di errore. Una volta in uno stato di errore, il modulo che supporta questa operazione degradata può passare alla modalità operativa degradata e continuare a funzionare con capacità ridotte. Ecco un paio di requisiti aggiuntivi che vorrai ricordare mentre prepari i tuoi moduli per il nuovo standard. Il modulo deve fornire informazioni sullo stato quando si accede alla modalità operativa degradata, la funzione che ha avuto esito negativo deve essere isolata, tutti gli autotest condizionali devono essere eseguiti prima dell’uso di qualsiasi funzione crittografica in modalità degradata e, ultimo ma non meno importante, se c’è un tentativo, mentre si è in modalità di funzionamento degradato, di utilizzare un algoritmo, una funzione di sicurezza o un processo non operativo; i servizi devono indicare che tale tentativo è stato effettuato.

Ecco un ulteriore commento sull’operazione degradata come dichiarato in FIPS 140-3. L’ultima frase nella sezione 7.2.4.3 afferma “Se il modulo non supera gli autotest preoperativi, il modulo non deve entrare in funzionamento degradato.” Bene, aspetta, dici, pensavo che l’operazione degradata dovesse essere utilizzata quando qualcosa come un autotest fallisce, ma qui sta dicendo che non puoi accedervi? Ricorda, puoi entrare nella modalità degradata solo da uno stato di errore. Quindi , il modulo deve prima entrare nello stato di errore, quindi entrare nell’operazione degradata, soddisfacendo anche gli altri requisiti come discusso sopra.

Concetti aggiuntivi

Tieni d’occhio il SP 800-140 documenti che CMVP rilascerà nei prossimi mesi per vedere se gli IG da FIPS 140-2 che non erano trattati nello standard ISO 19790: 2012 / ISO 24759: 2014 sono trattati in una delle pubblicazioni speciali. una sezione può essere assorbita in un manuale di gestione CMVP basato sul web, mentre altri possono continuare a essere indirizzati come IG.

Interfacce del modulo crittografico

Il blog precedente ha toccato i tipi di interfacce introdotto nel documento ISO (HMI: Hardware Module Interface, SFMI: Software or Firmware Module Interface, HSMI : Hybrid Software Module Interface o HFMI: Hybrid Firmware Module Interface), quindi non ne parleremo in questo momento. Invece, toccheremo le interfacce di input e output.

Interfacce tradizionali e nuove

FIPS 140-2 e FIPS 140-3 contengono entrambe: le quattro interfacce logiche: input dei dati, output dei dati, input di controllo e output di stato. FIPS 140-3 introduce una quinta interfaccia, chiamata interfaccia dell’uscita di controllo. Un’interfaccia di uscita di controllo viene utilizzata per l’emissione dei comandi. Segnali e dati di controllo vengono utilizzati per controllare o indicare lo stato di funzionamento. Questo output di controllo può essere un’informazione inviata a un altro modulo crittografico. L’interfaccia di alimentazione è anche un’interfaccia richiesta su tutti tranne i moduli software.

Canale affidabile

Un altro concetto introdotto in FIPS 140-3 è quello di “canale affidabile” che è simile al concetto FIPS 140-2 di un “percorso affidabile” (Sezione 4.7.4 e IG 2.1). È un collegamento di comunicazione sicuro tra il modulo crittografico e il dispositivo endpoint che invia e riceve dati dal modulo, con l’obiettivo di proteggere CSP non protetti.

Simile a FIPS 140-2 IG 2.1, non ci sono requisiti per l’utilizzo di un canale affidabile per i livelli di sicurezza 1 e 2 in FIPS 140-3. FIPS 140-3 ha diversi requisiti per i livelli di sicurezza 3 e 4, come ad esempio: CSP in chiaro non protetti, componenti chiave e dati di autenticazione, che devono utilizzare un canale affidabile quando vengono trasmessi tra il modulo e un mittente / destinatario. Il canale affidabile deve impedire modifiche, sostituzioni e divulgazioni non autorizzate. I servizi che utilizzano un canale affidabile devono impiegare l’autenticazione basata sull’identità e il modulo deve fornire un indicatore di stato quando si utilizza il canale affidabile.

FIPS 140-3 pone un requisito aggiuntivo per un modulo che utilizza un canale affidabile a livello di sicurezza 4 che non abbiamo visto nel precedente FIPS 140-2 o IG 2.1. Un modulo di livello 4 che utilizza un canale attendibile deve utilizzare l’autenticazione basata sull’identità a più fattori per tutti i servizi che utilizzano il canale attendibile.

Ruoli, servizi e autenticazione

Ruoli

Lo standard FIPS 140-2 (sezione 4.3.1) richiede che un modulo supporti sia un ruolo di crypto officer sia un ruolo utente e il supporto di un ruolo di manutenzione era facoltativo. FIPS 140-3 ha ancora gli stessi tre ruoli, ma è richiesto solo il ruolo di crypto officer (sezione 7.4.2). Il ruolo utente e il ruolo di manutenzione ora sono facoltativi.

Servizi

Servizi richiesti

Ci sono tre servizi richiesti nello standard FIPS 140-2: mostra stato , eseguire autotest ed eseguire funzioni di sicurezza approvate (sezione 4.3.2). Questi stessi tre servizi sono richiesti in FIPS 140-3, oltre a due servizi richiesti aggiuntivi: mostrare le informazioni sul controllo delle versioni dei moduli ed eseguire l’azzeramento (sezione 7.4.3.1). La “mostra le informazioni sul controllo della versione del modulo” richiede che il modulo crittografico emetta il nome / identificatore del modulo e le informazioni sul controllo della versione, che possono essere verificate rispetto a un certificato di convalida. Le specifiche del servizio di azzeramento sono definite nella sezione 7.9.7 e saranno affrontate in un futuro blog.

Servizio di bypass

Sia FIPS 140-2 che FIPS 140-3 contengono il servizio di bypass opzionale. FIPS 140-3 specifica che un operatore che può configurare un bypass la capacità nel modulo deve assumere un ruolo autorizzato. Sebbene lo standard FIPS 140-2 non stabilisca specificamente tale requisito, la maggior parte presunta l’autenticazione a un ruolo autorizzato era necessaria dato che il servizio poteva essere utilizzato per divulgare CSP e / influenzare la sicurezza delle informazioni protette dal modulo (IG 3.1).

Output crittografico autoiniziato

Una nuova funzionalità, affrontata in FIPS 140-3, è la “capacità di output crittografico autoiniziato”. Qui, il modulo può eseguire operazioni crittografiche o altre funzioni di sicurezza approvate senza alcun intervento da parte dell’operatore. Il crypto-officer può configurare questa capacità, mentre questa configurazione può essere persistente ai riavvii. Sono necessarie due azioni interne per attivare il servizio e il modulo deve indicare che il servizio è attivato.

Caricamento di software / firmware

Il caricamento di software / firmware è indirizzato in FIPS 140-2 standard, e in IG 9.7, nel contesto dell’autotest richiesto durante il caricamento del software / firmware. FIPS 140-2 non lo affronta come un servizio come si vede in FIPS 140-3 (sezione 7.4.3.4). Alcuni dei requisiti indicati nel documento includono che, affinché il modulo rimanga un modulo convalidato, qualsiasi software / firmware caricato deve essere convalidato da un’autorità di convalida. Qui, tutti i dati in uscita devono essere inibiti fino a quando il software / firmware non è stato completato con successo; il test di caricamento del software / firmware deve essere eseguito prima dell’esecuzione del codice; il modulo non deve eseguire il codice caricato fino a quando gli autotest preoperativi non sono stati eseguiti con successo e, ultimo ma non meno importante, le informazioni sulla versione dei moduli devono essere aggiornate per riflettere l’aggiunta / aggiornamento del software / firmware.

Commento aggiuntivo

I servizi non autenticati non sono esplicitamente affrontati in FIPS 140-3, quindi avremo bisogno di vedere se questo concetto, affrontato nell’attuale IG 3.1, viene trasferito in uno qualsiasi dei documenti SP800-140. Ulteriori informazioni su questo argomento saranno affrontate nei blog futuri.

Autenticazione

FIPS 140-3 è simile a FIPS 140-2 per l’autenticazione ai livelli di sicurezza 1-3: (ISO 19790: livello 1 – nessun requisito di autenticazione; Livello 2 – autenticazione minima basata sui ruoli; Livello 3 – autenticazione basata sull’identità). La differenza più grande è che per il livello 2 è stata aggiunta l’aggiunta della parola “minimo”, che corrisponde al chiarimento affrontato in IG 3.4. L’autenticazione di livello 4, nello standard FIPS 140-3 basato su ISO, accetta l’autenticazione un livello, non solo richiedendo l’autenticazione basata sull’identità. Per l’autenticazione di livello 4, deve essere basata sull’identità a più fattori.

Un paio di elementi aggiuntivi da notare in questa sezione è che FIPS 140-2 ha specificato la forza di autenticazione richiesta dal modulo. La forza non è definita in FIPS 140-3, ma deve essere specificata nella politica di sicurezza del modulo. Molto probabilmente, ogni autorità di convalida includerà un livello di autenticazione nella propria documentazione aggiuntiva.

I meccanismi di autenticazione approvati non possono essere implementati da procedure documentate o regole di sicurezza (es. policy). Ciò significa che le restrizioni sulla dimensione della password devono essere configurate e applicate dal modulo. Ciò potrebbe influenzare il modo in cui funzionano molti dei moduli correnti. , sii consapevole di questo mentre prepari i tuoi moduli per i requisiti ISO.

In breve

C’è molto da imparare sulle differenze tra FIPS 140-2 e FIPS 140-3. Sebbene ci siano una miriade di somiglianze, ci sono anche alcuni cambiamenti. La nostra serie su questo argomento continuerà, affrontando una nuova area con ogni post. Come sempre, se hai domande, non esitare a contattarci direttamente. Il nostro team è sempre qui per aiutarti.