Microsoft revoca i certificati usati in Flame, e contestualmente pubblica un approfondimento tecnico sul tema. È periodo di comunicazione, a quanto pare: pochi giorni fa Mikko Hypponen di F-Secure ha firmato un articolo in cui spega in modo molto ragionevole come mai il loro software non ha rilevato Flame e Stuxnet, mettendo in evidenza che “consumer-grade antivirus products can’t protect against targeted malware created by well-resourced nation-states with bulging budgets. They can protect you against run-of-the-mill malware: banking trojans, keystroke loggers and e-mail worms.” Cosa che i tecnici hanno ben presente (e in realtà anche sui trojan bancari ci sono parecchi dubbi), ma che è bene vedere scritto ogni tanto. Certo, avrebbe fatto piacere anche sapere come mai nessuno si è accorto a suo tempo del Sony Rootkit, che è un oggetto ben diverso da Stuxnet, ma lasciamo stare.
Torniamo ai certificati Microsoft, che sono un problema più attuale e interessante. Io ho letto l’approfondimento tecnico, cercando una risposta ad una domanda ovvia, e cioè: se sono stati utilizzati dei certificati Microsoft, come è stato possibile ottenerli?
Bene, la parte clou della spiegazione è questa: “What we found is that certificates issued by our Terminal Services licensing certification authority, which are intended to only be used for license server verification, could also be used to sign code as Microsoft. Specifically, when an enterprise customer requests a Terminal Services activation license, the certificate issued by Microsoft in response to the request allows code signing without accessing Microsoft’s internal PKI infrastructure”
In pratica, se interpreto correttamente la spiegazione, ogni “enterprise” che abbia richiesto una “Terminal Services activation license” in questo momento si trova in mano un certificato valido per firmare software a nome di Microsoft. Sarà meglio installare l’aggiornamento 😉
Il punto interessante però per me non è questo, e non riguarda neanche specificamente Microsoft: riguarda di nuovo l’utilizzo dei certificati come strumento di fiducia. Cosa significa firmare del codice? Significa, nel modello (molto) teorico dei certificati, garantire di aver prodotto o comunque fornito quel codice. Nota, non garantisce l’assenza di bachi, backdoor o altro, ma almeno dovrebbe garantire l’origine del codice. Quindi se io mi fido del produttore installo il codice. Allora, se il produttore non gestisce in modo corretto e sicuro il processo di firma, e di conseguenza io installo del software che mi danneggia, che responsabilità ha il produttore? In generale nulla: non è nemmeno chiaro con chi sia il contratto, visto che quando si installa del software al più si accetta una licenza, che ovviamente ha senso solo se l’origine del software è corretta. Senza approfondire oltre, provate a pensare a chi potrebbe essere responsabile nei confronti dell’utente, e vedrete che di principio non lo è nessuno. Naturalmente mi si dirà che è “il mercato” a garantire che comportamenti inadeguati puniscano il produttore… ma se così fosse, anche in tutti gli altri settori merceologici che non sono software non avremmo bisogno della garanzia, basterebbe il mercato a punire chi produce oggetti difettosi. Diciamocelo, richiamarsi sempre al mercato è nascondersi dietro a un dito, è una scusa per nascondere l’assenza di tutele.
Facciamo però un passo in più e parliamo di firma elettronica, quella in mano a cittadini e aziende. Qui il cittadino si trova con delle Certification Authority che, a differenza del produttore di soft non ha scelto (se una di queste emettesse un certificato a mio nome, io neppure lo saprei) e con delle responsabilità invece molto più pesanti di quelle di un produttore di software. Eppure lo strumento è lo stesso, mentre le competenze tecniche del cittadino sono molto minori.
Serve davvero ragionare su meccanismi alternativi a quello delle Certification Authorities, che permettano di avere le garanzie che servono e che le CA al momento non danno.
