Come distribuire i certificati client senza esporre la chiave privata?

9

Sto desgining un servizio web B2B basato su WCF. Poiché il numero di client è relativamente piccolo e la sicurezza è una priorità, ho scelto di utilizzare i certificati client X509 per l'autenticazione del client.

Sto firmando i certificati client con la mia CA autofirmata (che ovviamente viene tenuta al sicuro). Ho anche verificato che l'installazione funzioni su un set locale di computer.

Un problema continua a infastidirmi. Finché i certificati possono essere "fisici" consegnati non ho alcun problema. Tuttavia non riesco a trovare una soluzione per trasferire in modo sicuro i certificati client ai clienti effettivi. Queste sono le opzioni che ho trovato finora:

1) Crittografare i certificati utilizzando la crittografia simmetrica in formato PFX. Quindi invierò un'e-mail al certificato e invierò la chiave per decrittografare il certificato con una buona vecchia posta ordinaria (ovvero una lettera fisica)

2) Creare un sito Web semplice che consenta ai client di accedere utilizzando un URL temporaneo (credenziali inviate all'indirizzo e-mail) e quindi scaricare il certificato. Il sito sarebbe protetto usando HTTPS. La sicurezza quindi si affida completamente alla sicurezza della posta elettronica dei client e che nessuno raccoglie l'URL dall'e-mail

Tendo a preferire l'opzione 1) come l'unico difetto di sicurezza che ci sarebbe per qualcuno di rubare effettivamente la chiave dalla lettera fisica. Tuttavia sembra un po 'noioso usare una lettera fisica.

Esiste uno standard de facto per risolvere questo problema che sto trascurando che fornisce una sicurezza ragionevole?

    
posta Henrikmh 12.11.2012 - 07:55
fonte

3 risposte

13

Il modo "normale" di fare certificati è che la chiave privata non abbandona mai il sistema client. Le cose vanno così:

  • La coppia di chiavi privata / pubblica viene generata sul sistema client.
  • La chiave pubblica viene inviata alla CA come parte di una richiesta di certificato (in genere formato PKCS # 10).
  • La CA crea e firma il certificato, che viene rinviato al client.

La parte critica ora sta facendo in modo che la CA stia parlando con il cliente giusto al momento dell'emissione; ma, almeno, vengono trasferiti solo i dati pubblici, il che rende le cose più semplici.

Suggerisco di inviare ai potenziali clienti una sola password per posta - non email , ma la più tradizionale posta cartacea. Vengono quindi utilizzati per iscriversi alla CA (ovviamente all'interno di HTTPS). Semplificati la vita: utilizza un prodotto CA che include già il software e il processo necessari.

    
risposta data 12.11.2012 - 13:23
fonte
2

La tua analisi del problema sembra implicare l'idea di una finestra temporale infinita.

Considera la possibilità di trasmettere il certificato tramite HTTPS e il tuo back-end consente il trasferimento del certificato una sola volta. A meno che la connessione di trasferimento non sia MITM, il cliente avrà un certificato che nessun altro ha o sapranno che è stato recuperato da qualcun altro. Finirai per revocare alcuni certificati di importo non trascurabili a causa di problemi di salvataggio dei clienti, ecc. Quando richiederanno riemissioni, ma saprai che solo una persona ha accettato il certificato o che dovrebbe essere invalidato.

    
risposta data 12.11.2012 - 08:10
fonte
2

Potresti avere il client generare una richiesta di firma del certificato e inviarti a te per essere firmato dalla tua CA. La generazione della CSR sul client creerà la coppia di chiavi pubblica / privata e il CSR conterrà solo la chiave pubblica e le informazioni sull'identità. In questo modo la chiave privata non viene mai trasferita sulla rete.

Ci sono prodotti là fuori che faranno proprio questo e hanno integrato l'autenticazione multifactor. Dovrai cercarli.

Se vuoi codificare quanto sopra, i sistemi MS usano un ActiveX e html5 ha una funzione keygen che farà ciò che ho descritto sopra.

    
risposta data 12.11.2012 - 17:15
fonte