Come proteggere un certificato internamente

4

Dire che ho un certificato che uso per firmare il software che spedisco. Questo accade nella build (giornaliera o più) sul buildserver (macchina Windows). La soluzione più semplice sarebbe quella di mettere il file del certificato (pfx) sul buildserver e semplicemente usarlo lì.

Ma in questo modo, potrebbe essere rubato da qualsiasi ragazzo in azienda (pensa .. frustrato lasciando un ragazzo) o da un virus o altro. Ciò potrebbe portare a un disastro.

Attualmente il certificato è archiviato nell'archivio certificati come "non esportabile", che dovrebbe essere un po 'più sicuro. Ma quanto è sicura questa cosa "inesorabile" in realtà? Il server è una VM, quindi immagino che qualcuno possa semplicemente copiare l'intera cosa, portarla con sé e venderla o usarla per firmare qualsiasi cosa.

Naturalmente chiunque abbia accesso al buildserver potrebbe usarlo per firmare qualcosa lì, ma immagino che non ci sia davvero un modo per risolverlo. (E andare in ufficio a firmare malware (o qualsiasi altra cosa) sembra molto più improbabile che vendere il certificato o qualcosa del genere, quindi si presume che sia molto più improbabile)

Quindi le mie domande sono:

  • Quanto è sicura la cosa "inesattabile"?
  • Dovrebbe essere messo su una macchina hardware per rendere più difficile rubare / copiare l'intera cosa?
  • C'è un modo migliore / più sicuro per gestirlo?
posta Flo 05.02.2013 - 11:17
fonte

1 risposta

5

"Inesportabile" significa che le funzioni dedicate dal sistema operativo si rifiuteranno di esportare la chiave privata. Tuttavia, è ovviamente lì; questo è solo software, quindi la chiave privata, quando usata, esiste necessariamente in un punto della RAM con tutta la sua struttura. Il contrassegno della chiave come "non esportabile" è un sistema di sicurezza solo contro gli attaccanti che non hanno diritti di amministratore e deve agire entro i limiti dell'API. In caso contrario, l'esportazione è piuttosto semplice . Del resto, un semplice backup dell'intero sistema sarebbe sufficiente per ottenere la chiave privata.

Per rendere l'archiviazione delle chiavi solida contro gli attaccanti locali (persone che hanno accesso alla macchina e che sono tecnologicamente competenti), è necessario un Hardware Modulo di sicurezza . Questo è un costoso pezzo di hardware, che non darà mai via una chiave che gli è stata affidata; distruggerà attivamente le chiavi se rileva una violazione fisica. Inoltre, registrerà tutti gli usi delle chiavi private. Qualcuno che accede fisicamente all'HSM potrebbe comunque ottenere tutte le firme che desidera, ma tutte saranno registrate e non avranno la chiave stessa (quindi non sarà in grado di firmare in seguito ). Una versione più economica (ma un po 'meno robusta) sarebbe una smart card.

Il solito metodo per proteggere l'accesso alle chiavi per la firma del codice è avere due chiavi; una "chiave di sviluppo" che viene utilizzata per lo sviluppo e una "chiave di produzione" che viene utilizzata solo quando un prodotto reale sta per essere spedito. Le macchine degli sviluppatori sono configurate per accettare la chiave di sviluppo come valida, in modo che gli sviluppatori possano lavorare con il codice firmato con la chiave di sviluppo, ma ovviamente nella chiave dell'utente viene distribuita solo la chiave pubblica di produzione. L'idea è che la firma con la chiave di produzione dovrebbe essere sufficientemente rara da poter essere eseguita in modo non automatizzato, sotto controllo fisico della gestione e utilizzando hardware dedicato (ad esempio una smart card normalmente conservata in una cassastrong).

(Quando si utilizza un hardware speciale per archiviare una chiave privata, i backup possono essere un problema. Dovresti aver cura di tenere una copia sicura della chiave da qualche parte, o di essere in grado di ottenerne una nuova entro un breve preavviso.)

    
risposta data 05.02.2013 - 12:40
fonte

Leggi altre domande sui tag