it-swarm.dev

Criteri per la selezione di un HSM

Un'applicazione molto sensibile deve proteggere diverse forme di dati, come password, carte di credito e documenti segreti, e ovviamente chiavi di crittografia.
In alternativa allo sviluppo di una soluzione personalizzata intorno ai processi di crittografia (standard) e di gestione delle chiavi, è in corso l'acquisto di un HSM ( modulo di sicurezza hardware ).

Ovviamente ciò dipenderebbe (almeno in parte) dall'applicazione specifica, dall'azienda, dai tipi di dati, dalle tecnologie e dal budget, ma vorrei mantenere questo generico, quindi lo lascio ad una vista di alto livello e ignoro una specifica flusso di lavoro.

Supponiamo solo che ci siano dati segreti che devono essere crittografati e stiamo cercando soluzioni basate su hardware per gestire la complessità e la probabile insicurezza della gestione delle chiavi su misura e mitigare le ovvie minacce contro la crittografia e le chiavi basate su software.

Quali sono i fattori e i criteri che dovrebbero essere considerati, quando si confronta e si seleziona un HSM? E quali sono le considerazioni per ciascuno?

Per esempio:

  • Ovviamente il costo è un fattore, ma ci sono diversi modelli di prezzo? Cosa dovrebbe essere preso in considerazione?
  • Alcuni prodotti sono più adatti a diverse forme di crittografia (ad es. Simmetrico vs asimmetrico, blocco vs flusso, ecc.)?
  • Lo stesso vale per diversi flussi di lavoro e cicli di vita
  • Quale livello di affidabilità, ad es. quale livello di FIPS 140-2, è richiesto quando?
  • Collegato in rete vs collegato al server
  • eccetera

PER ESSERE CHIARI : NON sto cercando consigli sui prodotti qui, piuttosto solo su come valutare nessun prodotto specifico. Sentiti libero di nominare i prodotti nei commenti, o meglio ancora nel chatroom ...

47
AviD

Alcuni fattori tecnici che potrebbero essere rilevanti:

  1. Prestazioni: su qualsiasi argomento per la tua applicazione (se presente): crittografia/decodifica/generazione di chiavi/firma, simmetrica, asimmetrica, EC, ...
  2. Scala:
    • Esiste un limite al numero di chiavi supportate e potrebbe essere un problema?
    • Quanto è facile aggiungere un altro HSM quando l'applicazione diventa più esigente (dimensioni, velocità, distribuzione geografica ...)
  3. Ridondanza: quando un HSM si rompe, quanto impatto ha sulle tue operazioni, quanto è facile da sostituire senza perdita di servizio, ecc.
  4. Backup: quanto è facile automatizzare e ripristinare? È necessario proteggere in modo indipendente la riservatezza e/o l'integrità del backup o il prodotto lo garantisce? Con quale probabilità finirai in una posizione in cui hai perso irrimediabilmente i tuoi dati (quanti fattori devono essere persi/dimenticati, i HSM sono morti, ecc.).
  5. Supporto API:
    • MS CAPI/ CNG (facile da programmare da un ambiente Windows);
    • JCA (facile da sviluppare per l'utilizzo di Java. Quale versione è supportata?);
    • PKCS # 11 (e una versione recente? Ampio supporto tra le applicazioni, anche se viene fornito con problemi di sicurezza noti );
    • proprietario del fornitore (probabilmente il più flessibile/potente/sicuro-se-sai-cosa-stai facendo, ma aumenta i costi per passare a un altro fornitore), e mentre C è probabilmente un dato di fatto, ha vincoli per il tuo preferito linguaggio?
    • una nota correlata: esistono indicazioni sull'integrazione con l'applicazione (ad es. DBMS, servizi OS)?
  6. Supporto OS/hardware
  7. Opzioni di gestione - quali strumenti della GUI/riga di comando ci sono per svolgere attività di gestione - cioè qualsiasi cosa tu faccia abbastanza di rado da non voler automatizzare (generazione di chiavi?; Gestione dei fattori di autenticazione?). I tuoi amministratori devono essere fisicamente presenti per mettere in servizio il dispositivo o eseguire attività aggiuntive dopo la messa in servizio?
  8. Programmabilità: la maggior parte del tuo sviluppo sarà probabilmente dall'altra parte di una delle API, ma a volte è utile poter scrivere applicazioni in esecuzione sul dispositivo per una maggiore flessibilità o velocità (vedi risposta di Thomas )
  9. Sicurezza fisica: quanto deve essere resistente la tua soluzione all'attacco fisico diretto (tenendo conto non solo dell'HSM ma dell'intera soluzione)? Se per qualsiasi motivo decidi che è particolarmente importante (il tuo HSM è esposto ma i tuoi clienti non lo sono, o la divulgazione delle chiavi è molto peggio della semplice capacità di usare le chiavi per scopi nefasti - ref DigiNotar ?) quindi potresti voler cercare il rilevamento e la risposta di manomissione attivi, non solo la resistenza e le prove di manomissione passive.
  10. Modello logico di sicurezza: le entità dannose sulla rete possono abusare del tuo HSM? Processi dannosi sul PC host?
  11. Algoritmi: HSM supporta la crittografia che si desidera utilizzare (primitive, modalità di funzionamento e parametri, ad esempio curve, dimensioni dei tasti)?
  12. Opzioni di autenticazione - password; quorum; n-fattori; Smart card; OTP; ... Probabilmente dovresti almeno cercare qualcosa che può richiedere una dimensione quorum configurabile di token + utenti autenticati da password prima di consentire le operazioni utilizzando una chiave.
  13. Opzioni della politica - potresti voler essere in grado di definire politiche come controllare se: le chiavi possono essere esportate dall'HSM (con o senza crittografia); una chiave può essere utilizzata solo per la firma/crittografia/decrittografia/...; è richiesta l'autenticazione per la firma ma non la verifica; eccetera.
  14. Funzionalità di controllo - comprese entrambe le operazioni simili a HSM (chiave generata, firma qualcosa con chiave Y) e gestione degli arresti anomali (commento di ref g3k). Quanto sarà facile integrare i log in qualcosa di simile a Splunk (formato log logico, syslog/snmp/altra rete accessibile - o almeno non proprietaria - output)?
  15. Fattore di forma:
    • reteallegato (per distribuzioni su larga scala, in particolare laddove più applicazioni/server/client debbano utilizzare le chiavi);
    • desktop (per uso individuale; prestazioni, disponibilità e scalabilità non sono un grosso problema ma i costi lo sono, soprattutto se la tua soluzione richiede che molte persone necessitino dell'accesso diretto a un HSM);
    • PCI (-express) (più economico della rete collegata; maggiore impegno nella messa a disposizione di più applicazioni);
    • token USB (facile aggiornamento del server; economico e lento (e facile da rubare!));
    • scheda PC (come da desktop, ma buono per utenti laptop). (Le PC Card sono piuttosto morte ora)

Alcuni fattori non tecnici:

  1. Certificazioni: ne hai bisogno/ne vuoi perché ti danno fiducia nella sicurezza del prodotto? Ignorando ciò che bisogno per motivi di regolamentazione:
    • FIPS 140-2 fornisce un'utile conferma che gli algoritmi approvati dal NIST funzionano e hanno test di risposta noti in fase di esecuzione (controlla la politica di sicurezza per vedere quali alg sono stati approvati), ma non mettere molto stock in esso altrimenti mostrando il il prodotto è sicuro; la mia regola empirica per la sicurezza hardware di livello 3 implica che le persone con solo un paio di minuti di accesso al dispositivo avranno difficoltà a comprometterlo. FIPS 140-2 Livello 3 è la certificazione di base di fatto per gli HSM - fai attenzione se non ne ha uno (anche se questo non vuol dire che devi usarlo in un FIPS).
    • Le valutazioni dei criteri comuni sono flessibili nell'assicurazione che forniscono: leggi l'obiettivo di sicurezza! Non ci sono ancora profili di protezione HSM decenti, quindi almeno dovrete leggere la definizione del problema di sicurezza (minacce e ipotesi) prima di avere un'idea di ciò che la valutazione sta fornendo.
    • PCI-HSM sarà utile se sei nel settore rilevante
  2. A parte le certificazioni, come appare la sicurezza del fornitore? Avere CC EAL4 certs è un buon punto di partenza, ma ricorda che anche Win2k ne ha ... Esistono rumori convincenti sull'integrità della catena di fornitura, il ciclo di vita dello sviluppo del software sicuro, ISO2700x o qualcosa del genere Il framework di fornitori di tecnologia affidabile del gruppo aperto ?
  3. Ti piace la politica del venditore sulla divulgazione?
  4. Supporto (opzioni, reputazione, disponibile nella tua lingua)
  5. Servizi: se hai esigenze complesse, potrebbe essere vantaggioso coinvolgere il fornitore nella configurazione/programmazione.
  6. Documentazione:
    • Documentazione di alto livello: gli HSM sono prodotti complessi per scopi generici che possono richiedere una gestione un po 'implicata; una buona documentazione è importante per permetterti di sviluppare un processo sicuro e praticabile attorno a loro (vedi risposta di Thomas per ulteriori discussioni).
    • Documentazione API - buona copertura, preferibilmente includendo buoni esempi di attività comuni (e complesse)
  7. Costo (unità + manutenzione)
  8. Tempi di consegna
  9. Politica/frequenza delle patch del fornitore (+ supporto e facilità di aggiornamento del firmware)
  10. Paese di progettazione e/o fabbricazione: potresti essere un governo o una società che in particolare (dis) confida in determinati paesi
  11. Stabilità del fornitore: è probabile che siano in giro a supportare il prodotto per tutto il tempo in cui lo utilizzerai?
  12. Qual è la roadmap dei prodotti del fornitore, ha qualcosa di prezioso per te e avrai accesso alle versioni future tramite l'aggiornamento del firmware?
  13. Quanto è stato buono lo Swag che te ne sei andato a RSA

Probabilmente ce ne sono molti altri.

L'istituto SANS ha un buon documento introduttivo che descrive perché potresti voler un HSM, gli attributi positivi che dovrebbe (e) avere e alcuni degli aspetti negativi.

Sembra che un fornitore HSM sia d'accordo con la maggior parte di questo elenco e abbia prodotto il proprio (non attribuito) versione di esso .

37
Michael

Un HSM non eviterà la complessità; piuttosto, aggiungerà molta complessità all'intero sistema.

Ciò che HSM fa meglio è key storage: la chiave è nell'HSM e non ne esce mai, mai. Tuttavia, devi ancora preoccuparti del ciclo di vita chiave. Con una chiave "software", memorizzata in un file o nelle viscere del sistema operativo, i backup sono una vulnerabilità (non si desidera avere molte copie della chiave fluttuanti). Con HSM, questa vulnerabilità viene evitata, ma i backup diventano un grosso mal di testa: perdere la chiave è anche un rischio maggiore, specialmente per la crittografia (se si perde la chiave di crittografia, si perdono i dati) . Quindi questo è un primo elemento da considerare per HSM: procedure di backup . Ho una certa esperienza con Thales (nCipher) HSM, che lo fa in questo modo: le chiavi sono effettivamente memorizzate come file crittografati (che possono essere salvati proprio come qualsiasi file) e la chiave di decrittazione per that = la chiave può essere ricostruita con un quorum di smart card dell'amministratore (all'interno di un nuovo HSM).

HSM raramente esegue una crittografia simmetrica in blocco. In realtà, non ha molto senso eseguire la crittografia simmetrica con un HSM: si utilizza la crittografia perché dati è riservato. Logicamente, se la necessità della segretezza è tale che la chiave simmetrica non deve lasciare l'HSM, allora i dati stessi non dovrebbero lasciarla neanche. Inoltre, la crittografia simmetrica significa che sia la crittografia che la decrittografia utilizzano la stessa chiave: se tale chiave si trova nell'HSM, allora sia la crittografia che la decrittografia dovranno attraversarla.

HSM è meglio utilizzato con crittografia ibrida : l'HSM memorizza e utilizza la chiave privata di un sistema di crittografia asimmetrica; quando i dati devono essere crittografati, chiunque disponga dei dati genera una chiave simmetrica casuale [~ # ~] k [~ # ~], crittografa i dati con [~ # ~] k [~ # ~] e crittografa [~ # ~] k [~ # ~] con la chiave pubblica corrispondente al Chiave privata memorizzata HSM. In tal senso, HSM opera come (sovradimensionato, troppo caro) smart card .

Naturalmente, c'è un altro estremo, in cui si adatta l'intera applicazione all'interno dell'HSM. Ciò richiede un programmabile HSM , e questo è un contesto completamente diverso. Thales HSM lo consente come opzione (si chiama "CodeSafe" e "SEE"), che non offrono gratuitamente ... e non si aspettano di eseguire il codice tradizionale in questo. HSM ha acceleratori di crittografia, ma sono comunque sistemi embedded piuttosto limitati (pensa 60 MHz ARM CPU al massimo: la schermatura HSM è in contrasto con la dissipazione del calore). Puoi inserire un codice relativamente complesso in un HSM (che lo consente) ma è uno sforzo di programmazione specifico. Inoltre, alcuni HSM non lo consentono affatto.

Sebbene l'HSM sia costoso, il costo maggiore in un HSM è operazioni: comportano molte procedure per l'installazione, la configurazione, il funzionamento, il ripristino e il ritiro. Avrai bisogno di persone. Il mio criterio principale sarebbe quindi: procedure . Un buon HSM verrà fornito con un manuale d'uso dettagliato che descrive come le cose dovrebbero essere fatte. Non è l'hardware che conta, ma come lo usi.

Certificazioni, come EAL 4+ o FIPS 140-2 Livello 3, possono essere richieste a fini normativi. Raramente scegli se ne hai bisogno o no; questo è un requisito dal contesto d'uso previsto. una tale certificazione è un processo molto lungo e costoso, quindi non lo farai da solo. D'altra parte, potresti voler ampliare la tua area commerciale: se HSM sono principalmente grandi smart card, le smart card potrebbero essere utilizzabili al posto di dell'HSM. A smart card da 20 EUR può essere FIPS 140-2 Livello 3; calcolerà solo una decrittazione RSA-2048 al secondo anziché 500, ma potrebbe essere sufficiente per te.

23
Thomas Pornin