In questo momento , in X.509, non esiste il rilevamento di un numero di usi di una determinata chiave. Questo fa parte di ciò che si intende per "X.509 è privo di contesto": la convalida riguarda se il percorso del certificato che hai di fronte è valido o meno, indipendentemente dal fatto che ti sia stato mostrato un percorso simile o qualcosa di diverso 5 minuti fa quando si parlava allo "stesso" server per qualche nozione di "stesso".
Un altro punto importante di X.509 è che CA canaglia non è al suo interno . Questo sembra paradossale, ma l'idea è che quando una CA va sotto controllo ostile, allora quella CA è "persa" e l'unica cosa che può essere fatta con essa è di tagliare l'intero ramo dell'albero, revocando i certificati corrispondenti al compromesso Chiave CA (dove "compromesso" significa "la chiave privata è stata utilizzata per scopi ostili", non necessariamente "una copia della chiave privata è stata rubata"). Per una CA radice compromessa, l'unica correzione possibile è quella di rimuoverla dagli archivi attendibili di tutti i client, poiché la CA radice, essendo auto-emessa, non può essere revocata.
(Quando Microsoft inserisce una patch di Windows che rimuove una CA radice dall'archivio di fiducia predefinito, può essere vista come una sorta di revoca, nel qual caso la CA radice non è realmente "root", mentre la "vera radice" è Microsoft. Ma tutto ciò si verifica al di fuori di X.509.)
Nello scenario che descrivi, qualunque cosa l'autore dell'attacco abbia fatto con la chiave privata di root non può essere rilevata mentre l'attaccante non usa effettivamente il certificato canaglia. Ciò è inevitabile, in un modo matematico strong: se l'attaccante può accedere allo stato completo della CA radice, allora può "clonarlo" e usare la chiave privata sulle proprie macchine; lo stato CA radice non è quindi impercettibile. Quello che stai chiedendo è una magia crittografica che manterrebbe un "contatore d'uso" che l'attaccante non può alterare a piacimento anche quando può vedere lo stato completo. Finché i computer sono quello che sono, questo non è fattibile. Per ottenere una traccia del numero di firme emesse, in modo da rilevare attendibilmente le firme canaglia, avrai bisogno di qualcos'altro, ad es. memorizzare la chiave privata di root in un dispositivo antimanomissione (un HSM) che manterrà il contatore e, ad esempio, utilizzarlo come parte del numero di serie di tutti i certificati emessi (consentendo così l'audit sul lato client). Questo riguarda davvero la modifica del modello, individuando un "core CA radice" che l'utente malintenzionato non può sequestrare.
Concettualmente, potremmo immaginare un sistema di database distribuito (simile a quello utilizzato in Bitcoin) in cui vengono spinte tutte le firme, in un formato che contiene un "contatore delle firme". Ciò presuppone quanto segue:
- L'algoritmo della firma viene modificato in modo che funzioni su h (c || m) invece di h (m) ( c è il contatore, m i dati firmati e h una funzione di hash crittografica).
- Tutti i valori delle firme vengono memorizzati, indicizzati dal firmatario e dal valore del contatore, nel database globale (quindi vengono rilevati duplicati).
- I verificatori (client) non accettano una firma a meno che non possano trovarla nel database.
- I verificatori applicano uno specifico comportamento del contatore, che consente loro di notare quando una CA ha eseguito più firme del previsto.
- Il database distribuito non può essere modificato dagli autori di attacchi.
Nessuno di questi è supportato da X.509, né ora né nel prossimo futuro. Non esiste un database globale dei valori delle firme e poiché X.509 dovrebbe essere utilizzabile in contesti offline, non ce ne sarà uno. Inoltre, in X.509, i verificatori sono senza stato: non tengono traccia della cronologia delle verifiche e questa dovrebbe essere una funzionalità desiderabile.
Gli algoritmi crittografici per rilevare la doppia spesa nei protocolli di cassa elettronici sono in realtà una versione abbreviata del concetto di "database": si verificano a livello di banca, quando la banca vede effettivamente entrambe le transazioni. I protocolli E-cash sono così realizzati in modo che l'identità dello spanditore venga rivelata in caso di doppia spesa, durante questa fase di correlazione .