Ricordo con un certo fastidio la voce perennemente seccata di mia madre che, per l’ennesima volta, mi ricordava di controllare dove avessi messo le chiavi di casa, che dovevano essere in un posto sicuro, che dovessi tenerle sempre con me e via così.
Tante raccomandazioni per nulla, in quanto persi le chiavi in almeno un paio di occasioni. Questa settimana scopro che non sono stato l’unico a fare questo. Microsoft ha fatto più o meno la stessa cosa, solo che ha combinato un guaio un po’ più grosso di quello che combinai io…
Partiamo dall’inizio. Ad un certo punto Intel decise di progettare una nuova futuristica architettura per superare i limiti della propria architettura IA32, presentata con il processore 80386. Avrebbe dovuto essere l’architettura del futuro in quanto si liberava di un pesante fardello ovvero quello della compatibilità con i sistemi precedenti, IA16, IA32 e i loro sistemi operativi tra cui MS-DOS e le versioni di Windows non proveniente da NT.
Fu presentato un nuovo processore, Itanium, una nuova serie di specifiche, una nuova struttura di boot basata su un Firmware Estensibile (EFI), piuttosto che sul vetusto BIOS con le sue innumerevoli limitazioni. Fu presentato anche un nuovo sistema di partizionamento, GPT, molto più efficiente e moderno del raffazzonato MBR.
Fu un flop clamoroso. Nessuno voleva Itanium, se non per applicazioni di nicchia sconosciute al grande pubblico. Tutta l’architettura IA64 fu buttata a mare quando AMD presentò la sua versione, molto più semplice e con il vantaggio di essere invece compatibile con il passato, ovvero x86_64. Questa architettura, seppur evoluta nel corso del tempo è alla base di tutti i PC attuali (e Intel paga fior di Royalty a AMD).
Apple, bloccata con lo sviluppo dei PowerPC, decise di sviluppare una propria architettura basata su processori Intel Core (con architettura x86_64), ma riesumò alcune delle idee presentate da Intel con Itanium. Il firmware EFI divenne UEFI, il sistema GPT sostituì il vetusto APM dei precedenti MacOS.
L’idea piacque talmente tanto che i costruttori di PC iniziarono ad adottare una soluzione ibrida dove, a fianco di un BIOS a 16 bit tradizionale, affiancavano la possibilità di avere un sistema UEFI per una gestione più efficiente del boot dei vari sistemi operativi.
Con le nuove versioni di Windows si iniziò poi ad usare GPT come sistema di partizionamento. Microsoft inoltre sviluppò un sistema per rendere sicura la fase di boot dei propri sistemi operativi. La scusa ufficiale era quella di evitare che dei malware si potessero caricare durante la fase di boot sfuggendo così alle policy di controllo del sistema operativo. Avrebbe dovuto essere la fine specialmente di spyware come keylogger e similari.
L’idea era buona, peccato che avesse come effetto collaterale quello di rendere praticamente impossibile il boot di sistemi operativi alternativi come ad esempio GNU/Linux. Questo grazie anche ad alcuni accordi “sottobanco” con alcuni produttori di PC con i quali Microsoft si garantì l’esclusiva per il boot unicamente dei suoi sistemi.
Fu un periodo di rivolte da parte della comunità Open Source, e di decisioni impopolari, come quelle di Red Hat e SuSE che scesero a patti con Microsoft per poter permettere il boot delle proprie distribuzioni attraverso Secure Boot.
Alla fine vari produttori tornarono sui propri passi e permisero o di disabilitare il secure boot (e di permettere il boot di altri sistemi attraverso le chiamate al vetusto BIOS) o di caricare chaivi crittografiche diverse da quelle di Microsoft.
E qui arriviamo al punto cruciale. Secure Boot funziona attraverso un uso estensivo della crittografia e dei sistemi di firma digitale. Semplificando all’osso, il meccanismo di Secure Boot funziona con un sistema a chiave pubblica/privata. Il certificato contenente la chiave pubblica viene caricato all’interno del sistema UEFI (in pratica nel firmware della scheda madre). Durante tutti i passaggi della fase di boot, ogni volta che viene caricato un nuovo modulo, dal boot loader fino al kernel, l’eseguibile, che è stato firmato digitalmente, viene verificato con il certificato presente nel firmware. Se la verifica va a buon fine si passa alla successiva fase di boot, altrimenti il sistema si rifiuta di proseguire.
Appare chiaro quindi che qualunque eseguibile che non sia stato precedentemente firmato attraverso la chiave privata di Microsoft non possa funzionare. Questo meccanismo è alla base di molti meccanismi di antitamper che rendono sicuri molti PC moderni, i Surface, e altri.
Se gli Smartphone Windows Phone sono attualmente un incubo per forze di polizia, intelligence ed esperti di Digital Forensics è proprio perché, oltre ai meccanismi di protezioni del sistema operativo, il Secure Boot impedisce il sideload di sistemi operativi alternativi con i quali si possano aggirare le protezioni ed estrarre i dati contenuti al loro interno.
Microsoft si è persa quindi le chiavi private? Questo è quello che molti hanno capito dagli articoli apparsi recentemente su Internet.
Per fortuna non è così (!!!) altrimenti la cosa avrebbe messo a rischio milioni di sistemi e avrebbe potuto essere risolta solo aggiornando i loro firmware (cosa peraltro praticamente impossibile).
Ciò che Microsoft si è fatta sfuggire è una policy. Tale policy è un particolare boot policy che permette agli sviluppatori (non tutti parliamo di sviluppatori che lavorino a bassissimo livello nel sistema operativo), di testare i propri binari facendo in modo che il secure boot ignori i controlli di firma digitale.
Vi ricordate il famoso problema relativo all’iPhone della strage di San Bernardino? Quello che ha scatenato tutte le polemiche e che ha messo contro FBI e Apple?
Bene sostituite l’iPhone con un Lumia e portate il caso a oggi. Con questo scivolone di Microsoft l’FBI potrebbe caricare un binario in fase di boot capace di inibire la richiesta di PIN e permettere di estrarre tutte le informazioni contenute nello smartphone. Se magari, e dico magari, l’FBI potrebbe usare tale conoscenza solo per fini investigativi, vari servizi di intelligence di nazioni più o meno democratiche, le organizzazioni criminali potrebbero usarli per fini ben diversi.
Prima di strapparsi i capelli è bene ricordare che Microsoft ha già fatto uscire due patch, che sono pronte nuove patch previste per Settembre e probabilmente firmware per i suoi Surface e Lumia. Inoltre per portare un attacco è necessario effettuare avere fisicamente in mano il sistema sia esso un PC, un tablet o uno smartphone.
Sta di fatto che, con un solo errore, Microsoft ha vanificato anni di lavoro in fatto di sicurezza e messo a repentaglio anni di R&D nel campo della sicurezza.
Un po’ più di attenzione non sarebbe male in futuro.
Per restare sempre aggiornato sulle ultime novità scarica la nostra APP ufficiale oppure iscriviti alle nostre notifiche istantanee oppure seguici su Facebook, Twitter, Telegram e Instagram!
magati é stata persa apposta per lasciare alla comunità la possibilità di testare nuove strade… Mah..
Finalmente uno che ha fatto luce sulla questione! Io a dire la verità non sono affatto un’esperta del settore, anzi! Però, le notizie che avevo di recente letto sui vari blog mi avevano da un lato allarmato e dall’altro no, in quanto non pensavo fosse possibile una “falla” dalle dimensioni descritte.
Fatto sta che di certo non è una buona notizia per Microsoft ne tanto meno per la nostra sicurezza, ma non è affatto una situazione critica come volevano farci credere…!
…Dunque, allora la situazione non sarebbe così critica ? E questa golden key allora??
Non è una golden key ma possiamo dire che questa policy funziona come tale
Uhm …ok
Eccellente, ora è tutto piu chiaro! Bello l esempio con le chiavi di casa XD e ottima tutta la parte storica 😉
Comments are closed.