Verifica dei file firmati crittograficamente quando la chiave è stata revocata

7

Questa è principalmente una domanda per curiosità oziosa. Se uso la mia chiave privata per firmare un file oggi, formando una firma, e distribuire quella firma con il documento a qualcuno, possono usare la mia chiave pubblica (che hanno ottenuto fuori banda in modo sicuro) e il firma e verifica che il documento rimanga inalterato. Fin qui tutto bene.

Ma se il passaggio di verifica avviene solo qualche tempo dopo, e nel frattempo revoco la mia chiave, come dovrebbe essere gestita?

Da un lato, il file è stato firmato in buona fede in un determinato momento e se il file è in qualche modo timestamp e il timestamp è precedente alla data di revoca e la revoca non è a causa di una chiave compromessa, quindi la revoca non dovrebbe significa automaticamente sfiducia nella firma.

D'altra parte, supponendo che la chiave sia stata revocata perché è stata compromessa, qualcun altro avrebbe potuto usare la mia chiave privata compromessa per firmare un file con un timestamp falso entro l'immissione entro il periodo attivo della chiave.

Per quanto ho capito, più a lungo una chiave rimane 'attiva', meno è sicura, perché più tempo c'è stato per forzare la forza e più ha firmato / crittografato, più informazioni sono disponibili per l'uso in vari attacchi. Ora capisco che teoricamente la forzatura brutale di una chiave dovrebbe richiedere più tempo di quanto occorrerà per l'universo a subire la morte termica, ma è sempre possibile che si possano trovare scorciatoie in futuro. Quindi immagino che uno vorrebbe revocare le chiavi regolarmente.

C'è un modo per dire la differenza tra le due situazioni sopra descritte?

C'è un modo per dire le differenze tra una revoca a causa del ciclismo e una revoca a causa di un compromesso?

Sembra (da questa domanda ) che la normale revoca delle chiavi non è più una buona pratica, ma non sono sicuro al 100% che sto leggendo bene. Al giorno d'oggi invece si usano Trust-on-first-use e "pinning". Anche le risposte e i commenti in questa domanda chiariscono che non esiste un meccanismo per scadere una chiave. Avendo fatto alcune brevi letture su TOFU e pinning però, e non sembra influenzare la mia domanda.

Per evitare che questo venga chiuso con un reclamo "XY", lasciami essere più esplicito. Nella situazione di una chiave compromessa di cui sopra, non riesco a pensare a un modo per verificare in modo affidabile il documento anche se è stato firmato da una chiave senza compromessi al momento. Questo potrebbe facilmente essere un vuoto nella mia conoscenza, e voglio sapere se ci sono tecniche per farlo in modo affidabile?

    
posta sirlark 01.07.2015 - 13:59
fonte

2 risposte

2

Is there way to tell the differences between a revocation because of cycling and a revocation because of compromise?

Certificati .
I certificati di solito includono i tempi di validità, durante i quali la chiave pubblica associata è valida per l'uso. La maggior parte dei certificati viene rilasciata per 1 fino a 3 anni e successivamente è necessario ciclizzare il certificato (e anche la chiave associata). Con i migliori TOFU e appuntando schemi continuerai a vedere e controllare il certificato e non solo a fidarti della chiave bloccata, per assicurarti che la chiave sia effettivamente ancora valida e non scaduta né revocata (gestita tramite OCSP e CRL s).

But if the verification step only happens some time later, and in the mean time I revoke my key, how should this be handled?

Questo è in realtà un problema complesso, che richiede alcune (2) modifiche al modo in cui i documenti e i dati sono firmati e verificati.

Per prima cosa, dobbiamo cambiare i risponditori OCSP. Al momento, di solito ottieni solo "buono", "sconosciuto", "revocato" o "sospeso" dalla CA come risposta. Questo chiaramente non è sufficiente, poiché è necessario sapere quando il certificato è stato revocato o sospeso. Date queste informazioni puoi effettivamente verificare se la firma è stata emessa prima la chiave è stata compromessa . Naturalmente questo lascia ancora il problema che chiunque potrebbe semplicemente usare una data di pre-revoca per la firma dei dati.

Per risolvere questo problema, hai bisogno di qualche altro modo affidabile di stampare i dati temporali piuttosto che lasciare che il timestamp sia creato dal firmatario. È necessario esternalizzare il timestamp, facendo in modo che un servizio di fiducia firmi una combinazione dell'hash e dell'ora corrente, agganciando abilmente gli hash come avviene con Trasparenza certificato o inserisci una voce nella catena di blocchi.

Non appena hai una firma (dall'aspetto valido) con un timestamp attendibile prima della data di revoca, puoi essere certo che la firma è valida, ma tieni presente che la firma deve essere inclusa dall'hash inviato all'ora servizio di timbratura per garantire che nessuno lo abbia strappato e sostituito.

La soluzione alternativa possibile è sbarazzarsi dell'intero sistema di revoca e solo (esclusivamente) utilizzare certificati di breve durata in cui si può essere sicuri che se fosse stato revocato, tutti i dati in questo breve periodo avrebbero potuto essere firmati maliziosamente.

    
risposta data 22.03.2016 - 15:28
fonte
0

Supponendo che non ci sia tempo di ritardo tra la compromissione della chiave privata e la revoca della chiave pubblica e che ci sia un modo per scoprire in modo affidabile quando la chiave è stata revocata, questo potrebbe funzionare se si firma la firma a tempo, non la file. In questo modo, è possibile dimostrare che la firma è stata creata prima di aver perso la tua chiave privata.

Tuttavia, i tipici protocolli di revoca delle chiavi non soddisfano questa applicazione. Il database di revoche avrebbe bisogno di un timestamp per la ricezione della revoca e dovrebbe firmare una dichiarazione da te che indica fino a che momento le firme possono essere attendibili, ad es. la prima volta in cui il tuo sistema potrebbe essere stato intruso.

    
risposta data 27.07.2015 - 14:02
fonte

Leggi altre domande sui tag