Voglio progettare un sistema basato su ECDSA. Tutti i messaggi sono firmati usando l'algoritmo, e questo è usato per prevenire lo spoofing.
Tuttavia, se un utente dovesse in qualche modo perdere il controllo della propria chiave, sarebbe costretto a creare una nuova chiave per firmare i propri messaggi.
Esistono meccanismi che possono essere implementati per trasferire le persone alla nuova chiave di firma in modo sicuro e automatico? Inoltre, come si potrebbe "revocare" la vecchia chiave?
Sì, ma ci sono potenzialmente conseguenze di vasta portata. Ho intenzione di rispondere alla tua domanda più in generale.
La semplice risposta è revocare la chiave di firma. Facile come quella risposta è per una chiave utente, ci sono ancora problemi. Ad esempio, chiunque potrebbe fare affidamento su quella firma sottoscritta e aggiornata in base al nostro CRL? In caso contrario, la revoca della chiave non ha alcun effetto reale.
Se dovessimo riformularlo solo un po ', e parleremo di una firma del codice o di una chiave per la firma del certificato, il problema è più grande. Puoi ancora "semplicemente" revocare la chiave ... ma l'impatto è che tutti quelli che fanno riferimento al nostro CRL non si fidano più di qualsiasi cosa firmata da quella chiave di firma! Come puoi immaginare, questo porterà a una notevole quantità di lavoro per rassegnare le dimissioni.
Il modo in cui revochi la chiave dipenderà, ovviamente, dal pacchetto specifico che stai utilizzando. In genere implica la compilazione di dati sulla chiave compromessa in un elenco di revoche di certificati che deve quindi essere distribuito a tutte le entità fidate.
Come vengono migrati automaticamente su una nuova chiave? Bene, se hanno perso il controllo della chiave è difficile immaginarlo come un processo automatico; è davvero più una reazione a un incidente. Per le normali modifiche alle chiavi, tuttavia, molti prodotti gestiscono automaticamente questo problema (Microsoft Certificate Services con autoenrollment, ad esempio, o con rinnovo certificato self-service) e con altri è piuttosto manuale (PGP, OpenSSL) anche se è possibile automatizzarlo un grado.
La difficoltà nella creazione di un sistema simile da zero è che, in genere, preferirai -non- per generare o memorizzare la chiave privata per il certificato, in particolare per un certificato utente; ti piacerebbe davvero che generassero la parte privata della chiave. Questo di solito significa che dovranno essere coinvolti in qualche modo.
Sia PGP che PKI SSL globale risolvono questo problema più o meno allo stesso modo. Crei una super-chiave "fidata" con una lunga scadenza che custodisci con fervore religioso; la chiave rimane criptata, nascosta in un tempio sacro, solo mai intravista da un CSO debitamente unto, quel genere di cose. È quello di cui ti fidi. Non lo usi.
Quindi con quella chiave, firmi la chiave "ogni giorno". Ha una scadenza relativamente breve, ma comunque segui le migliori pratiche di sicurezza. Eppure, va dove è necessario andare.
Se sospetti che la chiave "ogni giorno" sia stata compromessa, la revochi e ne firmi una nuova con la chiave del tempio sacro.
La revoca è semplice come mantenere un elenco di chiavi revocate (probabilmente i loro hash) in una posizione globalmente visibile. Quella lista dovrebbe essere firmata. Quando qualcuno controlla se fidarsi di una chiave, controlla il percorso della firma della chiave fino a una radice attendibile. Controllano anche l'elenco di revoche.
Le prestazioni del controllo delle revoche delle chiavi sono un problema, ma se l'infrastruttura della chiave è piccola, puoi facilmente avere solo un elenco di revoche globale che invii a tutti su base regolare.
Usando PGP, la risposta è usare una sottochiave di firma, è quindi possibile collegare la sottochiave a una chiave master inutilizzabile ("stub") e utilizzarla nel lavoro quotidiano. Se tale chiave viene persa, la chiave di certificazione può essere utilizzata per designare una nuova sottochiave di firma; tuttavia, il destinatario dovrà aggiornare la chiave da un server delle chiavi.
Con X.509, nessun meccanismo di questo tipo esiste.
Per entrambi, è possibile migliorare la sicurezza mantenendo la chiave su una smart card, dalla quale non può essere esportata. La smart card OpenPGP non ha nemmeno un comando per esportare una chiave, mentre le smartcard per l'uso con X.509 hanno un attributo "non esportabile" sui tasti che può essere resettato solo cancellando lo slot della chiave.
Le smartcard sono indurite contro i comuni vettori di attacco come radiazioni ionizzanti, sovra / sottotensione e over- / underclocking e richiedono all'utente di presentare il PIN corretto, limitando il numero di tentativi.
Per requisiti di sicurezza ancora più rigorosi:
un lettore di smartcard "Classe 2" dispone di una propria tastiera per l'inserimento del PIN della smart card, quindi non può essere intercettato sul PC. Questo può essere usato con le smartcard standard.
un lettore di smartcard "Classe 3" dispone di una propria tastiera per l'inserimento del PIN e di un display alfanumerico controllato solo dalla carta, pertanto i dati da firmare possono essere visualizzati prima della voce PIN. Qui, sulla smartcard è necessario un codice personalizzato, che rappresenta un costo di sviluppo significativo.
Leggi altre domande sui tag digital-signature key-management