Secure Boot non piace alla FSF

Secure Boot non piace alla FSF

La fondazione del software libero si esprime in maniera diretta sulla nuova funzionalità di sicurezza prevista da Windows 8: la teoria ci piace, la sua implementazione pratica no
La fondazione del software libero si esprime in maniera diretta sulla nuova funzionalità di sicurezza prevista da Windows 8: la teoria ci piace, la sua implementazione pratica no

In attesa di conoscere finalmente le prime implementazioni concrete di Secure Boot, l’intera industria dell’IT continua a confrontarsi sulla discussa funzionalità di sicurezza che farà il suo debutto sul mercato assieme a Windows 8 (x86 e ARM/RT).

Ultima ma non ultima si pronuncia sulla questione la Free Software Foundation: l’organizzazione del software “libre” dedica a Secure Boot un whitepaper in cui analizza la tecnologia in sé e le implementazioni disponibili, apprezzando le intenzioni teoriche del meccanismo ma criticandone le implicazioni pratiche – soprattutto dal lato delle aziende FOSS .

In teoria, dice FSF, Secure Boot è un meccanismo di sicurezza che “ingloba il punto di vista del software libero sulla sicurezza” perché dà all’utente il pieno controllo della sua macchina. In pratica, l’obbligo di cifrare il bootloader e di verificare la firma crittografica attraverso un apposito modulo caricato nel firmware UEFI (ex-BIOS) è tutto fuorché positivo per il FOSS e per l’utente.

In particolare FSF ce l’ha con le aziende open che hanno già garantito il loro supporto a Secure Boot, nella fattispecie Red Hat e Canonical: nel primo caso la scelta di appoggiarsi a Microsoft/Verisign per la concessione di una chiave crittografica è altamente criticabile, dice la Fondazione, nel secondo caso un po’ meno. La casa di Ubuntu, infatti, ha già detto che genererà una sua chiave personale e la fornirà ai produttori OEM.

Anche così, a ogni modo, per FSF Canonical sbaglia approccio: è pessima la decisione di abbandonare il bootloader libero GRUB 2 in favore di efilinux, mentre la licenza GPLv3 potrebbe generare situazioni in cui i produttori OEM (o persino Canonical) potrebbero essere costretti a rendere pubblica la chiave crittografica usata per firmare il bootloader, rendendo completamente vano l’intero meccanismo di sicurezza.

Alfonso Maruccia

Link copiato negli appunti

Ti potrebbe interessare

Pubblicato il 4 lug 2012
Link copiato negli appunti