c.m.g
04-07-2012, 08:32
mercoledì 4 luglio 2012
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
Roma - 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 (http://punto-informatico.it/3547591/PI/News/secure-boot-ubuntu-avra-sua-chiave.aspx) 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 (http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web) 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 (http://arstechnica.com/information-technology/2012/07/fsf-criticizes-secure-boot-raises-concerns-about-distro-implementations/) 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
Fonte: Punto Informatico (http://punto-informatico.it/3554189/PI/News/secure-boot-non-piace-alla-fsf.aspx)
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
Roma - 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 (http://punto-informatico.it/3547591/PI/News/secure-boot-ubuntu-avra-sua-chiave.aspx) 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 (http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web) 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 (http://arstechnica.com/information-technology/2012/07/fsf-criticizes-secure-boot-raises-concerns-about-distro-implementations/) 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
Fonte: Punto Informatico (http://punto-informatico.it/3554189/PI/News/secure-boot-non-piace-alla-fsf.aspx)