Conformità ai requisiti per la certificazione sulla sicurezza di Certicom e QNX

Gli enti pubblici, le strutture sanitarie e gli enti finanziari utilizzano servizi di rete sempre più complessi e pertanto la gamma di dispositivi per l'accesso a tali sistemi continua ad ampliarsi. Contemporaneamente a questo sviluppo, una sempre maggiore attenzione in questi settori è rivolta alla sicurezza e alla riservatezza delle informazioni: le organizzazioni stanno investendo cifre importanti per soddisfare i requisiti di sicurezza dei dati di server e apparecchiature di rete, laptop, smartphone e stampanti. Ad esempio, nei prossimi cinque anni, il governo federale degli Stati Uniti prevede di investire più di 500 miliardi di dollari USA nell'IT (Information Technology) e una ingente percentuale di questa somma è destinata a programmi di ammodernamento della crittografia e attività relative alla crittografia e alla gestione delle applicazioni chiave.

Per ridurre la complessità e i costi legati all'ampliamento delle reti e alle necessità di sicurezza, il governo federale degli Stati Uniti ha pubblicato rigorosi standard e requisiti di interoperabilità, ovvero i requisiti di sicurezza dello standard FIPS (Federal Information Processing Standard) 140-2 per moduli crittografici. Questo standard di sicurezza crittografica è stato adottato da molti altri governi e sta diventando lo standard di rifermento nel settore sanitario, finanziario e in quello emergente delle reti intelligenti. Il programma di ammodernamento della crittografia del governo degli Stati Uniti prevede una sempre maggiore l'implementazione di tecniche avanzate di crittografia, come l'Elliptic Curve Cryptography2, che influenzeranno il futuro della sicurezza.

Per competere in questi settori, i venditori di software e dispositivi devono dimostrare che i propri prodotti soddisfano i requisiti di crittografia convalidati dallo standard FIPS (Federal Information Processing Standard). Ciò potrebbe risultare un compito estremamente lungo, complesso e costoso, da rivedere con ciascun aggiornamento dei prodotti. I venditori devono inoltre assicurarsi che qualsiasi aggiornamento non comprometta la conformità alla sicurezza FIPS dei prodotti e pertanto devono costantemente monitorare gli standard per verificare che i prodotti siano sempre conformi ai nuovi requisiti. Ad esempio, lo standard FIPS 140-3, destinato a sostituire FIPS 140-2, è già stato redatto.

Dei vari componenti degli odierni sistemi software, due sono i più importanti per la sicurezza:

- un sistema operativo che soddisfi i rigidi requisiti di sicurezza per l'affidabilità

- un modulo di crittografia convalidato con FIPS 

In questo documento verranno esaminate alcune delle sfide principali associate al processo di convalida FIPS 140-2 e verrà illustrato come QNX® Neutrino® RTOS e la libreria crittografica Certicom Security Builder Government Security Edition (GSE) può alleviare il peso dello sviluppo e della fornitura di software conforme a FIPS 140-2. 

COTS e sicurezza

Come le altre organizzazioni, gli enti governativi vorrebbero poter utilizzare i normali prodotti commerciali (COTS) per sfruttare l'esperienza e il risparmio offerti dai venditori della concorrenza. Per risultare idonei all'uso da parte di tali enti, tuttavia, questi prodotti di venditori COTS devono soddisfare i rigidi requisiti di sicurezza stabiliti negli Stati Uniti da organizzazioni quali il Ministero della Difesa (DoD), l'Agenzia per la sicurezza nazionale (NSA) e l'Istituto nazionale di standard e tecnologia (NIST). FIPS 140-2 rappresenta il comune denominatore nella maggior parte delle direttive più importanti per la sicurezza informatica. Il DoD, ad esempio, fa riferimento a questo standard nelle direttivi che regolano la comunicazione di dati sensibili.

Il settore sanitario e quello dei servizi finanziari presentano requisiti analoghi in termini di sicurezza delle informazioni, in particolare se si considera il numero in costante aumento di divulgazioni di informazioni che potrebbero portare all'identificazione delle persone. I requisiti di sicurezza dei dati in questi settori sono stabiliti da normative del governo, fra cui l'Health Insurance Portability and Accountability Act (HIPAA) e l'Health Information Technology for Economic and Clinical Health (HITECH) Act per quanto riguarda il settore sanitario e il Gramm-Leach-Bliley Act (GLBA) relativo alla riservatezza dei dati dei consumatori per le banche e le società finanziarie. Tali requisiti spingono i venditori a prendere come riferimento lo standard FIPS 140-2 per quanto riguarda la crittografia e la sicurezza dei dati.

Le normative HIPAA stabiliscono che i "Processi di crittografia validi per i dati in movimento sono quelli conformi ai requisiti degli standard FIPS (Federal Information Processing Standards) 140-2". In questo documento si specifica anche che i dati a riposo devono essere protetti in base alla NIST Special Publication 800-1116, che consiglia l'utilizzo di algoritmi di crittografia certificati con FIPS. Inoltre, la legge HITECH incoraggia l'uso di tecnologie di sicurezza comprovate, per l'analisi da parte delle organizzazioni che utilizzano prodotti certificati con FIPS.

Tuttavia, l'importanza di FIPS 140-2 non si limita a questi aspetti. Con l'aumento delle connessioni in rete dei sistemi di infrastrutture, come i gasdotti e i sistemi di controllo con rete intelligente, con molta probabilità questi settori adotteranno misure di controllo di pari rigorosità per la crittografia utilizzata per proteggere i dati in transito, creando un'ulteriore richiesta di soluzioni di crittografia certificate con FIPS.

Per acquisire una fetta maggiore di questi mercati in espansione o per mantenere la posizione corrente, i venditori COTS che in genere non richiedevano un alto livello di esperienza in materia di sicurezza devono 

espandere le proprie conoscenze degli standard di sicurezza e delle tecnologie di crittografia esistenti e in via di sviluppo, monitorando al contempo le modifiche ai requisiti FIPS. Devono inoltre vincere la sfida di supportare tali requisiti nei sistemi integrati.

Solidità delle basi

Un requisito fondamentale della sicurezza dei sistemi è l'utilizzo di un sistema operativo affidabile. La creazione di un sistema sicuro su un sistema operativo non affidabile sarebbe come costruire un caveau di una banca su un pavimento instabile. Tale punto di debolezza di base verrà notato e sfruttato.

Le caratteristiche principali che rendono QNX Neutrino RTOS il sistema operativo ideale per la libreria crittografica GSE di Certicom includono:

Garanzie dell'affidabilità in tempo reale: solo un sistema operativo in tempo reale (RTOS) è sviluppato espressamente per i sistemi che devono rispondere correttamente e in modo prevedibile e puntuale alle richieste.

Architettura a microkernel: con l'architettura a microkernel di QNX Neutrino RTOS, le applicazioni, i driver dei dispositivi, i file system e gli stack di rete risiedono all'esterno del kernel in indirizzi separati e pertanto sono isolati dal kernel e fra di loro. Un guasto di un componente non comporterà l'arresto dell'intero sistema e i meccanismi di recupero possono riavviare i processi interrotti.

Chiamate kernel di bassa priorità pre-rilasciabili: per soddisfare i requisiti in tempo reale, QNX Neutrino RTOS consente il pre-rilascio delle chiamate kernel di bassa priorità da parte dei processi con maggiore priorità. Le finestre temporali in cui non è possibile effettuare il pre-rilascio sono estremamente ridotte. Inoltre, vi è un limite superiore sulla durata della sospensione del pre-rilascio e la disabilitazione degli interrupt, consentendo agli sviluppatori di indagare le latenze peggiori.

Priority inheritance: QNX Neutrino RTOS implementa il protocollo Priority Inheritance per impedire le inversioni di priorità (il problema che ha afflitto il progetto Mars Pathfinder nel luglio 1997) assegnando la priorità di un attività bloccata al thread a bassa priorità, bloccandolo finché non viene completata l'attività di blocco.

Partizionamento adattativo: QNX Neutrino RTOS utilizza il partizionamento adattativo per impedire che processi o thread monopolizzino i cicli della CPU, di fatto escludendo altri processi o thread. Con il partizionamento adattativo, gli sviluppatori possono allocare determinati intervalli di tempo della CPU a processi e thread. Inoltre, un algoritmo di pianificazione riassegna in modo dinamico i cicli della CPU non utilizzati a partizioni che necessitano di un maggiore tempo di elaborazione. I budget di partizione vengono applicati solo quando la CPU è utilizzata al massimo delle capacità. Tutti i cicli disponibili vengono utilizzati, quando necessario. Tuttavia, quando i processi di più partizioni li richiedono contemporaneamente, il partizionamento applica i budget di risorse e impedisce che queste vadano esaurite. 

Framework ad alta disponibilità: nessun sistema è a prova di errore. Per garantire una costante disponibilità QNX Neutrino RTOS supporta un framework ad alta disponibilità che include un watchdog che monitora gli eventuali errori dei processi, meccanismi automatici di riavvio dei processi interrotti senza necessità di riavvio, processi mirror costantemente pronti a svolgere il ruolo del watchdog in caso di necessità e un'interfaccia di programmazione che consente al progettista del sistema di stabilire in che modo il watchdog risponderà a errori specifici.

Capacità del multiprocessore: per garantire la stabilità durante la migrazione e successivamente a essa nonché l'efficienza dei sistemi multicore, QNX Neutrino RTOS utilizza il bound multiprocessing (BMP), un'estensione specifica di QNX dell'affinità del processore o del thread che consente agli sviluppatori di specificare l'ereditarietà runmask dei threads. Consentendo agli sviluppatori di impostare runmask che limitano a core particolari non solo i thread specificati, ma anche i thread figli, BMP protegge i sistemi migrati ai multicore da bug latenti o difetti di progettazione, come la pianificazione FIFO, che rendono il codice scritto per processori a core singolo non affidabili sui sistemi multicore. Inoltre risolve problemi, quali il thrashing della cache, in genere associati all'elaborazione multicore simmetrica. Gli sviluppatori che effettuano la migrazione dei sistemi a quelli multicore possono collegare intere gerarchie di thread a un singolo processore per garantire che non vi siano problemi nel nuovo ambiente.

FIPS 140-2

Negli Stati Uniti, i requisiti della sicurezza governativa sono stabiliti dalle pubblicazioni FIPS. NIST sviluppa tali pubblicazioni che vengono utilizzati in tutti gli enti pubblici. Sviluppa e rilascia nuove pubblicazioni FIPS se il governo federale necessita di nuovi standard di sicurezza e interoperabilità.

FIPS 140-2 descrive i requisiti di crittografia del governo federale degli Stati Uniti che i prodotti software e hardware devono soddisfare per un utilizzo sensibile, ma non classificato. FIPS 140-2 si riferisce alla convalida del modulo completo che le applicazioni devono utilizzare per svolgere le funzioni di crittografia specificate. Vedere "Convalida FIPS" di seguito. Altri FIPS, come FIPS 186-2, che descrive l'utilizzo dell'algoritmo ECDSA (Elliptic Curve Digital Signature Algorithm), e FIPS 197, che specifica lo standard AES (Advanced Encryption Standard), sono specifiche implementazioni degli algoritmi di crittografia inclusi in un modulo convalidato FIPS 140-2.

Nel 2002, il Federal Information Security Management Act (FISMA) ha eliminato una disposizione che consentiva agli enti pubblici di rilasciare dichiarazioni di non responsabilità per l'acquisto di prodotti senza approvazione FIPS. Tale eliminazione ha comportato che, da quel momento in poi, la convalida FIPS 140-2 è diventata obbligatoria per tutti i prodotti che implementano la crittografia e che sono venduti al governo federale degli Stati Uniti. Senza la convalida FIPS 140-2, i prodotti non saranno presi in considerazione dai clienti del governo degli Stati Uniti. Inoltre, al di fuori degli Stati Uniti, paesi come il Regno Unito e il Canada, tramite il Communication Security Establishment (CSE), hanno adottato FIPS 140-2 per i propri requisiti di sicurezza.

Analogamente, benché la convalida FIPS non sia sempre richiesta per le applicazioni del settore sanitario e finanziario, è comunque spesso un requisito. Ad esempio, è obbligatoria per le installazioni medicali nelle strutture pubbliche degli Stati Uniti, dove la tecnologia wireless viene utilizzata per trasferire i dati dei pazienti. Se la convalida FIPS non è esplicitamente richiesta, è comunque altamente consigliabile se è necessario garantire la sicurezza dei dati. In breve, i prodotti convalidati con FIPS hanno un vantaggio competitivo in questi settori. 

Convalida FIPS 140-2

Per la maggior parte dei venditori, vi sono due livelli di convalida FIPS. Il primo livello convalida le tecniche di crittografia utilizzate da algoritmi specifici, come quelli menzionati in FIPS 186-2 e FIPS 197. Tali algoritmi includono algoritmi di crittografia simmetrica come AES, DES, 3DES e RSA, algoritmi hash come SHA-1 e firme digitali come RSA ed ECDSA. FIPS specifica in che modo sono definiti tali algoritmi e come devono essere implementati per ottenere la convalida. Il programma Cryptographic Algorithm Validation Program (CAVP) di NIST effettua tali convalide.

La seconda convalida, di livello superiore e più importante, è FIPS 140-2. Questo standard specifica undici aree di sicurezza che devono essere soddisfatte dai moduli di crittografia eseguiti in un sistema sicuro per proteggere le relative informazioni. Questo modulo di crittografia può essere hardware, firmware o software. Si assume la responsabilità dei servizi di sicurezza del sistema in cui è utilizzato, svolgendo funzioni come la crittografia, l'autenticazione e la generazione di numeri casuali. 

FIPS 140-2 definisce quattro livelli di sicurezza, da 1 a 4 (4 è il più sicuro) per ciascuna delle undici aree di sicurezza specificate. Assegna quindi un singolo punteggio complessivo al modulo di sicurezza. Per ulteriori informazioni su tali livelli, vedere la nota dell'applicazione di Certicom "Certicom Security for Government Suppliers", disponibile presso www.certicom.com/fips.

Per ricevere la convalida FIPS 140-2, un modulo di crittografia deve:

  •   avere una delimitazione crittografica ben definita, in modo che tutte le informazioni sensibili sulla sicurezza restino nel core di crittografia del prodotto

  •   utilizzare almeno un algoritmo approvato da FIPS con la corretta implementazione e una delimitazione crittografica intatta

    Il processo di convalida di un algoritmo o di un modulo di crittografia FIPS 140-2 è illustrato nella Figura 1, mostrata sopra. Almeno un algoritmo utilizzato nel modulo FIPS deve essere convalidato dal CAVP prima di accedere al processo di convalida FIPS 140-2 tramite il CMVP. Il modulo FIPS deve quindi essere convalidato con il programma CMVP (Cryptographic Module Validation Program) che, come il CAVP, è gestito da NIST. Tutti i test CMVP vengono eseguiti da uno dei laboratori CMT (Cryptographic Modules Testing) accreditati in base al programma NVLAP (National Voluntary Laboratory Accreditation Program). 

    Ostacoli e problemi legati alla commercializzazione

    Benché il settore governativo sia interessante e con alti profitti, per molti venditori il processo di convalida FIPS rappresenta un ostacolo quasi insormontabile. Le scelte a disposizione dei venditori che desiderano vendere i propri prodotti agli enti governativi, alle strutture sanitarie o a quelle finanziarie sono limitate: possono creare un prodotto da zero oppure acquistare un modulo di crittografia convalidato con FIPS-140-2 da un venditore commerciale.

    Coloro che prevedono di creare un prodotto devono tenere a mente che il processo di convalida richiede da otto a 12 mesi, l'impegno di vari sviluppatori e una spesa approssimativa di 50.000 dollari USA solo per la convalida iniziale. A questa spesa iniziale devono essere aggiunti da 10.000 a 15.000 dollari USA per ciascun successivo invio dello stesso modulo (aggiornamenti, correzioni di bug o di errori iniziali e così via). Pertanto, i costi della convalida di un modulo prodotto in proprio superano con facilità i 100.000 dollari USA.

    Quando invia un modulo di software crittografico per la convalida, il venditore deve presentare la seguente documentazione: policy di sicurezza, macchina di stato finita, descrizioni dei moduli software, elenco del codice della fonte di tutto il software nell'ambito della delimitazione crittografica, descrizione dei ruoli e servizi del modulo, descrizione del ciclo di vita di gestione principale e certificati di conformità degli algoritmi. La convalida è specifica della piattaforma: per ogni piattaforma è necessario un singolo numero di certificato di convalida. Inoltre, eventuali modifiche o aggiunte a un prodotto convalidato richiedono un nuovo ciclo di convalida del prodotto, con conseguenti costi aggiuntivi.

    Inoltre, la creazione di un modulo crittografico in base allo standard FIPS 140-2 non è solo un'operazione complessa, ma è anche ad alto rischio di errore. In base a NIST, il 48% dei moduli crittografici inviati dai nuovi richiedenti e il 20% di quelli inviati da vecchi richiedenti contiene errori di sicurezza. Il 30% degli algoritmi testati da NIST non sono conformi allo standard FIPS. Questa percentuale di fallimenti suggerisce che le aziende potrebbero investire ingenti quantità di tempo e denaro nello sviluppo di una soluzione che richiede la convalida FIPS e nel relativo invio per il test che potrebbe richiedere fino a un anno di attesa per poi apprendere che la soluzione non è corretta e non può essere convalidata con FIPS senza ulteriori modifiche e spese.

    Infine, le spese della convalida FIPS non terminano quando un prodotto la riceve per la prima volta. È sempre necessario avere tecnici all'interno dell'azienda per monitorare le modifiche agli standard di sicurezza e alle tendenze del settore, che potrebbero richiedere che il prodotto venga modificato per soddisfare le richieste di mercato o per tenere il passo con i nuovi requisiti FIPS. Lo standard FIPS 140-2 viene aggiornato ogni cinque anni e vengono aggiunti nuovi algoritmi per migliorarlo, allinearlo alle tendenze del settore e rafforzarlo. Benché le convalide esistenti restino in vigore quando vengono apportate modifiche allo standard FIPS, se un venditore desidera sfruttare i nuovi algoritmi dello standard, dovrà aggiornare il prodotto e inviarlo nuovamente per la convalida.

    Anziché creare i propri moduli crittografici, i venditori possono acquistarne uno pre-convalidato e quindi incorporarlo nei propri 

    prodotti. I vantaggi di questo approccio includono la convalida FIPS 140-2 senza necessità di svolgere il relativo processo, costi di sviluppo minimi, tempi rapidi di commercializzazione e sforzi di sviluppo incentrati sulle competenze fondamentali. Per scegliere correttamente il modulo crittografico, si consiglia di tenere a mente i seguenti punti:

    Architettura espandibile: una piattaforma che con un'interfaccia API comune semplifica il supporto di nuovi algoritmi e protocolli di sicurezza con minime necessità di riscrittura del codice.

    Flessibilità di aggiornamento: i moduli pre-convalidati consentono ai venditori di apportare modifiche ai prodotti o alle soluzioni e di conservare la convalida FIPS riutilizzando lo stesso modulo per la sicurezza. Il fornitore del modulo FIPS si assume la responsabilità di monitorare lo standard FIPS, apportando modifiche al modulo e convalidando la versione aggiornata. Il venditore dovrà semplicemente sostituire il modulo FIPS nel prodotto per mantenere la convalida FIPS.

    Flessibilità della piattaforma: se la convalida FIPS 140-2 è necessaria per più piattaforme di sistema, il fornitore del modulo FIPS deve offrire moduli di sicurezza convalidati per tutte le piattaforme necessarie.

    Vincoli delle risorse: l'utilizzo di un modulo convalidato con FIPS e sviluppato specificatamente per dispositivi con limitazioni delle risorse può migliorare significativamente le prestazioni del sistema riducendo l'ampiezza di banda della CPU e i requisiti di memoria. Questo vantaggio è particolarmente evidente nei dispositivi mobili, in cui la durata della batteria rappresenta una delle principali preoccupazioni.

    Conclusione

    Tenuti in considerazione gli ostacoli e i vantaggi associati allo sviluppo di un prodotto convalidato con FIPS, trovare un'implementazione FIPS affidabile che consente di commercializzare rapidamente il prodotto con il minimo rischio può costituire la differenza fra il successo e il fallimento.

    QNX Software Systems e Certicom collaborano per fornire una libreria condivisa di moduli di oggetti per fornire agli sviluppatori un metodo semplice e conveniente per sfruttare le librerie crittografiche Security Builder GSE di Certicom convalidate con FIPS. Questa soluzione consente ai produttori di dispositivi e ai venditori indipendenti di software di offrire ai propri clienti soluzioni con una tecnologia certificata con FIPS 140-2 su una solida base RTOS. 



Ultime notizie

Sorry, your filter selection returned no results.

Non perderti le ultime novità sull'elettronica

Abbiamo aggiornato la nostra politica sulla privacy. Si prega di prendere un momento per rivedere questi cambiamenti. Cliccando su Accetto, l'utente accetta la Politica sulla privacy e Condizioni di utilizzo di Arrow Electronics.

Il nostro sito web mette i cookies sul vostro dispositivo per migliorare la vostra esperienza e il nostro sito. Leggete altre informazioni sui cookies che usiamo e su come disabilitarli qui. I cookies e le tecnologie di tracking possono essere usati per scopi commerciali.

Con un click su “Accept”, voi consentite l'inserimento dei cookies sul vostro dispositivo e l'uso da parte nostra di tecnologie di tracking. Per avere altre informazioni e istruzioni su come disabilitare i cookies e le tecnologie di tracking, clickate su “Read More” qui sotto. Mentre l'accettazione dei cookies e delle tecnologie di tracking è volontaria, una loro disabilitazione potrebbe determinare un funzionamento non corretto del sito web, ed alcuni messaggi di allarme potrebbero essere per voi meno importanti.

Noi rispettiamo la vostra privacy. Leggete qui la nostra politica relativa alla privacy