In che modo i sistemi proteggono da un certificato di firma del codice rubato dopo la scadenza del certificato?

Questo è il motivo per cui Microsoft consiglia di non rimuovere mai i certificati di firma codice scaduti dai CRL. Uno scenario alternativo: l'attaccante firma il proprio malware prima della scadenza della cert. Se riescono a rimanere al di sotto della scadenza della cert non ancora scoperta, allora il certificato non verrà aggiunto al CRL nemmeno alla scoperta e il loro malware non verrà mai bloccato. Pertanto lo stato di revoca dei certificati di firma del codice deve essere tracciato per sempre .

Da Microsoft Best practice per la firma del codice documento:

In most PKI deployments, only certificates that have not yet expired are placed on the CRL. This means that when a revoked certificate expires, it is eventually removed from the CRL. However, timestamping allows Authenticode signatures to remain valid indefinitely. As a result, revoked code-signing certificates should not be removed from the CRL. This paper recommends always revoking compromised certificates that were used to sign publicly released software and maintaining these entries in the CRL indefinitely.

Microsoft Certificate Server enables administrators to configure the CA to keep all revoked certificates in the CRL. However, the CA does not distinguish between code-signing certificates and other certificates. For this reason, administrators should dedicate a CA for the sole purpose of handling code-signing production certificates.

Quindi per rispondere alla tua domanda - sì, il malware può essere eseguito di nuovo se il CRL per i certificati di firma del codice non è gestito correttamente.

Gestire le firme digitali è più complesso di quanto possiamo supporre a prima vista.

Il tuo scenario è corretto: se non hai una prova della data / ora della firma non puoi essere sicuro che non sia stato fatto dopo la revoca e la scadenza del certificato. Puoi anche notare che, anche se il certificato non è stato revocato, una firma fatta dopo la scadenza del certificato non dovrebbe essere considerata valida.

Prima soluzione

Aggiunta di una marca temporale alla firma del software. Il timestamp è denominato signature time stamp . Questo timestamp fornisce una prova che la firma esisteva in una determinata data. Esso garantisce che la firma sia stata calcolata prima della scadenza del certificato. Ma non risolve il secondo problema: cosa succede se il certificato è stato revocato?

Seconda soluzione

Insieme al timestamp della firma è anche possibile allegare una copia del CRL (o una risposta OCSP) alla firma. Dimostrerà che il certificato non è stato revocato quando è stata prodotta la firma.

Ma i token con timestamp e CRL sono anche oggetti firmati. Devono anche essere convalidati. Quindi, dovremmo ottenere anche il CRL che dimostra che il timbro temporale della firma è stato firmato da un certificato valido? Risposta breve: Sì, le cose sembrano essere più complicate.

Terza soluzione

Alcuni standard di firma (come CAdES ) hanno proposto una soluzione migliore: insieme al timestamp della firma , dovresti raccogliere tutti gli elementi necessari per convalidare la firma off-line (cioè essere in grado di convalidare il certificato senza dover scaricare alcun oggetto aggiuntivo). Include tutti i certificati e i CRL CA intermedi. Questo non è un processo infinito dato che alla fine si arriverà a una o più CA di root, ma potrebbe essere piuttosto complesso (si noti che un buon algoritmo di validazione X.509 dovrebbe generare tutti questi elementi insieme allo stato di validità del certificato). E dopo aver recuperato tutti questi oggetti, devi inserire una data / ora. Questo timestamp è chiamato time-stamp dell'archivio

Ora il processo di convalida della firma è il seguente:

1. Convalidi la data / ora globale online . Significa che scarichi tutti gli elementi necessari per garantire che la firma del timestamp sia valida. Ora hai una prova che tutti gli oggetti inclusi (CRL ...) esistevano alla data di scadenza dell'archivio.
2. Convalidi la firma off-line solo con gli elementi che erano coperti dal timestamp dell'archivio come se la data corrente fosse la data del timestamp dell'archivio .

Con questa soluzione lo scenario che stavi presentando non è possibile poiché il verificatore della firma ha una prova della scadenza e dello stato di validità del certificato alla data della firma.

Questa soluzione è attualmente implementata per la convalida della firma di documenti a lungo termine, ma sfortunatamente, per quanto ne so, non per la convalida della firma del codice. Oggi i fornitori utilizzano altri meccanismi come blacklist rubate, che sono più facili da implementare.

AGGIORNAMENTO, 25 settembre 2014 (dopo aver letto il commento @maureen)

In primo luogo, la comprensione del processo è corretta: poiché ogni certificato viene rimosso dal CRL dopo la data di scadenza, non è possibile valutare se un certificato è stato revocato o meno in passato. Quindi non è possibile convalidare una firma dopo la scadenza di un certificato.

Ma anche se un certificato è stato compromesso (o semplicemente revocato perché, ad esempio, il cliente ha perso il suo cripto-token USB), tutte le firme create prima dovrebbero essere considerate valide. Il processo che ho descritto nella mia risposta cerca di spiegare come è possibile rispondere oggi (cioè anche dopo la scadenza del certificato) alla domanda: "La firma era valida era stata creata".