Nos dicen que podemos y que no podemos instalar en nuestro PC.
Cada día más medidas privativas de nuestra libertad. Hagamos del 2013 el año del software libre. Participa!!!
Unete a la campaña de la Fundación de Software Libre, y pide a los fabricantes de Hardware que liberen tu PC!!!
– http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement
En este artículo podrás encontrar la traducción del artículo escrito en inglés por Vojtěch Pavlík: «SUSE and Secure Boot: The Details» una visión interesante de SUSE ante UEFI.
Desde los blogs de SUSE Olaf Kirch y Vojtěch Pavlík nos han dado una visión de los planes de esta empresa de GNU/Linux ante la nueva medida UEFI y Arranque Seguro. Estos son los planteamientos propuestos por SUSE.
openSUSE es una comunidad aparte que puede tomar sus propias decisiones, pero siempre está bien saber qué es lo que dicen los desarrolladores de SUSE y cuales son sus medidas ante esta nueva característica de seguridad.
GRACIAS a Vojtěch Pavlík por permitirme la traducción y la publicación de su artículo. Puedes ver el original en este enlace: www.suse.com/blogs/uefi-secure-boot-details/
GRACIAS también a Javier Llorente, miembro destacado de la comunidad de openSUSE por sacar tiempo de sus múltiples proyectos y su tiempo libre y ayudarme a corregir la traducción, bueno, y por todo!! 😉
Espero que aclare un poco la forma en la que SUSE tratará de mantener la libertad en tu PC y al mismo tiempo no renunciar a la seguridad del mismo. Vamos con la traducción:
En artículos anteriores Olaf Kirch nos ha hecho una introducción sobre el arranque seguro UEFI y el enfoque de SUSE sobre cómo abordar este tema. En este artículo os daré los detalles técnicos de nuestro plan sobre el arranque seguro. Así que prepararos para un artículo un tanto minucioso y técnico.
El objetivo del arranque seguro es prevenir que el malware se esconda de forma embebida durante el proceso de arranque realizando una comprobación de todos los componentes y tareas que se ejecuten durante un arranque en frío de todo el sistema.
Para lograr su objetivo, el arranque seguro debe impedir cualquier modificación del proceso de verificación, de las llaves, o de cualquier otra variable como código no confiable o entidades que no sean de confianza. Un ejemplo de una entidad en la que no se confía podría ser un pirata informático que ha penetrado en el sistema a través de un agujero de seguridad sin parchear en el sistema operativo.
Hay dos tipos de usuarios en los que se puede confiar:
El arranque seguro UEFI ofrece dos tipos de variables para satisfacer las necesidades de los usuarios:
Las diferentes listas de llaves UEFI son del primer tipo, ya que esto permite la actualización on-line, añadir y poner en una lista negra de llaves, huellas digitales de controladores y firmware. El segundo tipo de variables, «variables exclusivas para servicios de arranque» son las que nos ayudarán en nuestra búsqueda de una implementación de arranque seguro que sea a la vez segura y compatible con la filosofía de código abierto. Y compatible con la 
GPLv3.
Como Olaf explicó en el anterior artículo, en SUSE hemos empezado desarrollando una “aplicación cuña” basada en la de Fedora, firmada con un certificado firmado por el KEK de SUSE o con un certificado emitido por Microsoft, basado en las KEK’s que están disponibles en la base de datos de llaves de UEFI del sistema
Esto permite a esta aplicación cuña cargarse y ejecutarse.
Esta aplicación cuña arranca para verificar que el gestor de arranque GRUB2 que quiere arrancar es de confianza. Para ésto no usará ni la KEK de SUSE ni el certificado emitido por Microsoft. En una situación por defecto, la aplicación cuña usará un certificado de SUSE independiente embebido en su código. Además, la aplicación cuña permitirá “grabar” nuevas llaves, reemplazando la llave de SUSE por defecto. A estas las llamaremos “llaves propietarias de la máquina – Machine Owner Keys” lo que para abreviar llamaremos MOKs
El proceso de grabado empieza reiniciando la máquina e interrumpiendo el proceso de arranque (por ejemplo, pulsando una tecla) mientras la aplicación cuña arranca. La aplicación cuña entrará entonces en un modo de grabado, permitiendo al usuario reemplazar la llave por defecto de SUSE con llaves que están en un fichero en la partición de arranque.
Si el usuario elige hacer ésto, la aplicación cuña entonces calculará un nuevo hash de ese archivo y pondrá el resultado en una variable “exclusivas para servicios de arranque”. Ésto permite a la aplicación cuña detectar cualquier cambio del fichero hecho fuera de los servicios de arranque y evitar así la manipulación usando la lista de usuarios autorizados de MOKs.
Un aspecto importante a tener en cuenta es que todo ésto pasa durante el tiempo de arranque, en el cual sólo se ejecuta código verificado. Por lo tanto, sólo un usuario presente delante de la consola puede decir “quiero usar mi propio juego de llaves”. Cosa que no podrían hacer ni un pirata informático ni malware con acceso remoto a nuestro PC, ya que los piratas o el malware sólo pueden cambiar el archivo pero no el hash almacenado en las variables exclusivas para los servicios de arranque.
Una vez cargado y verificado GRUB2 por la aplicación cuña, volverá a llamar a esta aplicación cuña cuando quiera verificar el kernel, para evitar la duplicación de verificación de código. La cuña utilizará la misma lista que MOKs para esto y dirá a GRUB2 si se puede cargar el kernel o no.
¡Y ésto es todo!
Ésto es todo lo que necesitas para ser capaz de trabajar mejorando el kernel o el gestor de arranque. Instalar un nuevo juego de llaves y autorizarlas in situ durante el primer reinicio.
También gracias a que los MOKs son una lista y no una sola MOK, puedes hacer que el proceso intermedio o cuña valide llaves de varios fabricantes diferentes, permitiendo un arranque no sólo dual, sino múltiple desde el GRUB2 del gestor de arranque.
Al final la implementación real de este sistema puede ser algo más complicada, por ejemplo, proteger con contraseña la autorización de MOK para permitir una actualización autentificada y segura de la lista de MOKs desde el propio sistema operativo, pero este es el quid de la cuestión, y como puedes modificar libremente el GRUB2 y el kernel de una máquina, puedes estar tranquilo ya que tu máquina seguirá cumpliendo la licencia GPLv3 y no será tivoizada (saltarse a la torera la licencia)
Quizás te preguntes si ésto va en contra de lo que permiten las especificaciones UEFI o de los requisitos del logo de Win8 de Microsoft o de cualquier otro contrato relacionado.
Yo no creo eso – incluso las especificaciones de la UEFI permiten, pero no obligan, que la implementación UEFI permita a un usuario autorizar código EFI con una firma no válida añadiendo un hash a una variable especial.
Y la Linux Foundation ha preguntado a los fabricantes para asegurarse de que incluyan una manera de limpiar los PK para permitir a el usuario grabar su propio juego de llaves.
Nuestro enfoque es simplemente asegurarse que una característica como ésta está disponible en todas partes. Y mantener libre la plataforma “PC”.
—————————————————-
Si quieres, puedes descargarte el documento traducido en PDF pinchando en este botón: 
NOTA:
Por este blog ya he hablado de UEFI y el Arranque Seguro, una medida que pretende hacer más seguros nuestros Pc’s, pero que esconde una cara poco amable y que atenta directamente contra la libertad del usuario de utilizar e instalar el software que le venga en gana. La comunidad de Software Libre y los usuarios de GNU/Linux somos la parte más afectada, debido a cómo crece y se desarrolla esta comunidad esta medida constituye un atraso considerable.
Las distintas comunidades de GNU/Linux se han propuesto adoptar fórmulas que sean beneficiosas para todos. En este caso la comunidad de SUSE ha escrito una serie de notas en las que detallan sus planes. Olaf Kirch ha escrito unas primeras notas contando los planes de SUSE, la comunidad de openSUSE se rige de manera independiente a esta, pero siempre está bien conocer estas propuestas y tomarlas en consideración.
Así que para ello he traducido del inglés los dos primeros artículos de Olaf, que me ha permitido que los publique.
Puedes ver el original del primer artículo en este enlace: uefi-secure-boot-overview/ y en este la traducción que he hecho: victorhckinthefreeworld.wordpress.com/suse-opensuse-ante-uefi-y-el-arranque-seguro
Ahora te traigo traducido el segundo de los artículos escrito por Olaf, gracias de nuevo por permitir la difusión de su trabajo, puedes ver el original en este enlace: uefi-secure-boot-plan/ y si quieres ver la traducción sigue leyendo!
—
Este nuevo artículo es una continuación de este primer artículo. Describiré nuestros planes frente a UEFI y el Arranque Seguro (Secure Boot). Ten en cuenta que cuando digo “SUSE” en realidad me estoy refiriendo a dos distribuciones de GNU/Linux muy distintas: SUSE Linux Enterprise por un lado, y openSUSE por otro. Esta última al ser un proyecto comunitario es bastante independiente a la hora de abordar esta situación. Así que la descripción que sigue debe ser considerada como el actual Plan de Registro para SUSE Linux Enterprise, pero en lo referido a openSUSE, puede considerarse sólo una propuesta más para tener en cuenta por la comunidad.
Tal como se explicó en el anterior artículo, UEFI y el Arranque Seguro es una tecnología útil, Que hace que sea más difícil para los atacantes el esconder malware en la cadena de arranque.
Y al mismo tiempo, por la manera en que está basada esta operación – estableciendo una sólo raíz de confianza – entra de lleno en conflicto con el desarrollo del Código Abierto, que debe ser independiente y distribuido para que funcione.
Además de todo lo anterior, hay algunas lagunas en lo referente a licencias y cuestiones legales, para quien quiera utilizar este Arranque Seguro en forma por defecto. La clausula GPL v3 es una de esas, otra es la redacción del contrato SysDev de Microsoft que se opone a la firma de la GPLv3 binarios con un certificado proporcionado por Microsoft.
En la actualidad, los primeros sistemas de escritorio se están lanzando con soporte de arranque seguro, y esperamos que se vaya introduciendo en todos los PC nuevos vendidos hacia el final de este año. Y por supuesto, esperamos que todos los que se envía con llave de Microsoft Exchange ( Microsoft’s Key Exchange Key – KEK) instalado por defecto.
Algunas de estas nuevas máquinas, lo más probable es que tengan una manera de deshabilitar de una manera fácil el arranque seguro; en otras esto puede que también sea posible pero de una manera un poco más complicada; y en otras será totalmente imposible sin perder otras funcionalidades.
El soporte a UEFI y el Arranque Seguro esencialmente se reduce a tener un gestor de arranque con una firma digital que el firmware reconoce como una llave de confianza, y con el fin de ser útil a los clientes empresariales, esa llave será de confianza a priori por el firmware, sin necesidad de ninguna intervención o manipulación manual.
Hay 2 maneras de conseguir esto. Una es tabajar junto con los vendedores de hardware, para que avalen una llave SUSE con la que podremos firmar el cargador de arranque. Y la otra forma sería a través del programa de certificación del logo de Windows, para tener una certificación en el proceso de arranque y que Microsoft reconozca nuestra llave (por ejemplo tendría que estar firmada con su KEK). Actualmente estamos evaluando las dos propuestas, y puede que se realicen las 2 en paralelo.
En la capa de implementación, tenemos la intención de utilizar un primer cargador (N.del T: se podría traducir como “cargador cuña”) desarrollado originalmente por Fedora – es una solución inteligente que evita varios problemas legales desagradables, y simplifica considerablemente el paso de certificación / firma. El trabajo de este primer cargador es cargar grub2 y verificarlo, esta versión de grub2 a su vez, cargaría núcleos únicamente firmados por una llave de SUSE. Estamos estudiando la posibilidad de ofrecer esta funcionalidad con SLE11 SP3 para nuevas instalaciones con la presencia de UEFI Arranque Seguro.
Ahora quizás este claro porque esta primera medida ofrece el nivel de seguridad que promete UEFI Arranque Seguro, hay una cadena irrompible de verificación, asegurándose de que sólo código confiable y firmado será ejecutado antes de dar el control al kernel del sistema operativo.
Lo que no está tan claro es cómo los desarrolladores de Código libre y abierto van a hacer funcionar sus propios kernels, o cargadores de arranque para este caso, o cómo se va a cumplir la licencia GPL v3. En próximas series de estos blogs, explicaremos cómo pretendemos proporcionar esto con nuestra propia versión de un primer cargador de arranque o “cargador cuña”.
—
Espero que te sea útil. Si tienes sugerencias de una mejor traducción o alguna errata no dudes en comentarlo para corregirlo. openSUSE es una comunidad abierta, sientete libre de expresar tu punto de vista a la comunidad y dar tu opinión.
NOTA:
———————————————
Quizás hayas oído hablar de UEFI y Secure Boot (Arranque seguro), una nueva medida de seguridad que puede hacer que los fabricantes de PC’s decidan qué puedes y qué no puedes instalar en tu PC.
La comunidad GNU/Linux sale al quite para que los usuarios no pirdan la libertad de elección.
Como seguro ya has leído, Windows 8 (siguiendo con sus políticas de monopolio encubierto) quiere imponer a los fabricantes de PC’s que si estos quieren incluir el logo de compatibilidad con este sistema operativo, deben incluir una medida de seguridad llamada Secure Boot, lo que podríamos traducir por: Arranque Seguro. Aunque existen muchas sospechas que lo que quieren hacer es un «Arranque restringido». Las medidas de seguridad siempre son buenas, pero en este caso, en nombre de la seguridad quieren que los usuarios perdamos parte de nuestra libertad.
Y uno de los colectivos afectados somos los usuarios de GNU/Linux. De plantearse la medida como quieren no podrás instalar nada en tu PC, que los fabricantes de PC’s no hayan aceptado antes! Es decir que puedes desarrollar un nuevo sistema operativo, pero como este no está «firmado» por los fabricantes, entonces no es reconocido, y basándose en ese arranque seguro, no te dejarían instalarlo en PC’s que tengan implementado esta medida.
La Fundación de Software Libre, ya empezó una campaña (pincha aqui para verla) para que los usuarios firmáramos, y pidiéramos que ese arranque seguro no merme las libertades de los usuarios, independientemente del sistema operativo que utilizásemos.
Las diversas comunidades de GNU/Linux han dado su opinión para que ésta medida sea implementada de la mejor manera, no de forma unilateral por parte de Windows, y con el consenso de todos los usuarios. No estamos en contra de la medida de seguridad, estamos en contra de los modos y maneras en las que se quiere implementar.
La comunidad de SUSE y openSUSE, tambien ha dado su opinión, por medio de artículos. En estos artículos se expone qué es esta medidad y que piensa la comunidad de SUSE al respecto. La comunidad de openSUSE es independiente de aquella, pero quizás sus puntos de vista son interesantes y merecen tenerse en cuenta.
Olaf Kirch ha escrito un primer artículo en el que se detalla, y se hace un primer acercamiento a UEFI y el Secure Boot o Arranque Seguro. Puedes ver el original en inglés en el siguiente enlace: www.suse.com/blogs/uefi-secure-boot-overview/ o puedes leer a continuación la traducción que he hecho. Gracias a Olaf por permitirme publicar la traducción, a él pertenece el mérito del trabajo.
—
En el caso en que todavía no sepas a que se refieren estos dos términos: UEFI es “Unified Extensible Firmware Interface” y “Secure Boot” es uno de las más recientes características que está causando un gran revuelo dentro del mundo del código libre y abierto.
En SUSE hemos estado observando UEFI y Secure boot durante mucho tiempo y de forma minuciosa.
Por un lado, estamos de acuerdo en que el cierre de algunas de las lagunas en el proceso de arranque es una meta que vale la pena. Durante décadas, hemos aceptado que este proceso ha sido una de los puntos débiles que no pueden ser solucionados fácilmente sin un cambio profundo en la BIOS. Ahora que este cambio está llegando, estamos dispuestos a aceptarlo. Y también estamos contentos de ver que un cambio mucho mayor está sucediendo como parte de esto, que es el establecimiento de UEFI como estandar en el firmware de todas las plataformas x86.
Por otro lado, como una compañía de Linux, estamos viendo un buen número de comentarios que nos están causando dolores de cabeza, a los que queríamos resolver antes de expresar públicamente nuestros planes en este sentido.
A fin de explicar nuestras inquietudes, vamos a echar un breve vistazo a lo que realmente hace de arranque seguro, en pocas palabras. En el mundo de UEFI, asegurar el proceso de arranque significa establecer una cadena de confianza. La «plataforma» es la raíz de esta cadena de confianza, me inclino a pensar que es la placa base y la memoria firmware de la ROM que esté montada. O, dicho de forma ligeramente diferente, es el proveedor de hardware, y la cadena de confianza que se deriva de proveedor de hardware serían los fabricantes de componentes, los proveedores de sistemas operativos, etc
Desde un punto de vista legal, esta confianza se establece por una gran cantidad de contratos y papeleo legal. En el nivel de bits y bytes, esta confianza se expresa a través de la criptografía de clave pública. El fabricante pone una clave en la ROM, lo que representa la raíz de confianza. Las relaciones de confianza con los proveedores de sistemas operativos y otros se documenta mediante la firma de las claves de la plataforma ROM.
Finalmente, la seguridad se establece al exigir que ningún código será ejecutado por el firmware a menos que haya sido firmado por una de estas claves «de confianza» – ya sea un sistema operativo del gestor de arranque, algún controlador que se encuentra en la ROM de alguna tarjeta PCI Express, o ya sea una actualización del firmware de la misma.
Por supuesto, se podría hacer de esto una cadena muy larga, al exigir que todo lo se ejecute alguna vez en tu máquina este firmado digitalmente: el propio sistema operativo, los módulos que carga, los binarios y las bibliotecas compartidas que carga, todos los scripts ejecutados por cualquier intérprete al azar, e incluso los comandos que se teclea en una sesión de shell.
Así que, es obvio, que esta candena tiene que parar en alguna parte; y en la especificación UEFI, ese punto se alcanza cuando el firmware pasa el control al sistema operativo. Básicamente, si deseas utilizar el arranque seguro, necesitas tener el cargador del sistema operativo firmado con una clave de confianza por el firmware, y necesitas que el gestor de arranque compruebe que carga un kernel en el que se puede confiar.
Es cierto que se estan pasando muchos detalles por alto, pero no son de relevancia para esta discusión.
El quid de la cuestión es que esto entra en conflicto con la forma en que la comunidad de código libre y abierto se viene desarrollando desde hace varias décadas. El movimiento de Código abierto comenzó como un acto de emancipación de los proveedores de sistemas operativos de la época. El Código abierto y libre fue y todavía es y trata de la libertad, no de un modo dogmático, pero sí en realidad en un sentido muy práctico. La comunidad de Linux está donde está hoy porque la gente podía empezar su propia distribución, construir su propio cargador de arranque y el kernel, y formar una comunidad. Se está prosperando la forma en que está prosperando hoy en día porque hay miles de personas en todo el mundo que la desarrollan su núcleo o kernel diez veces al día para corregir errores, para agregar mejoras, o para ejecutar su instrumento de prueba en la última serie de cambios. Y sólo se nutrirá de esta manera si seguimos así.
Desde este punto de vista, Secure Boot está muy en desacuerdo con el modelo de desarrollo de GNU/Linux.
Sólo para que conste, no creo que esto sea una conspiración o una tentativa siniestra para matar a Linux. Eso no va a suceder. Pero al mismo tiempo este Secure Boot puede ser una mejora significativa para muchos, que sin duda crea obstáculos para la comunidad Linux.
Por supuesto, la certificación del logotipo de Windows 8 requiere que los proveedores de BIOS pueda permitir a los usuarios desactivar el arranque seguro en las plataformas x86, y tenemos esperanza de que todos los proveedores de BIOS realmente pongan en práctica esto de una manera que funcione bien para los desarrolladores de Linux. Pero lo ideal sería que, los desarrolladores de Linux no debe ser obligados a quitar una característica de seguridad como esta para ejecutar su sistema operativo.
Por lo tanto, en los últimos meses, nuestras preguntas cuando hemos tratado el tema del “arranque seguro” han sido, ¿cómo podemos hacer que funcione para nuestros clientes, y cómo podemos conciliar las exigencias de arranque seguro con las necesidades de la comunidad Linux.
Tenemos la intención de continuar con esta serie de entradas de blog en breve con una visión general de la forma en que la intención de apoyar de arranque seguro en SUSE Linux Enterprise, y las soluciones que proponemos a la comunidad openSUSE.
—
He tratado de hacer la traducción lo mejor posible, aunque todo es susceptible de mejora, si crees que hay algo que se pueda mejorar o alguna errata por favor coméntalo y se corregirá si es necesario. Tengo intención de traducir los otros 2 artículos escritos al respecto, si estás interesado permanece a la «escucha»!!
NOTA:
————————————-
La fundación de software libre (free software foundation) está pidiendo que los usuarios de software libre se unan a su campaña para decir a Microsoft que rechazamos la política que quiere implantar de «arranque seguro» que mejor se debería llamar «arranque restringido»
Pásate por su página en este enlace: www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement y firma la petición. Distribuciones de GNU/Linux como Debian ya se han unido, y otras estan viendo de qué manera pueden ayudar…
Yo ya me he apuntado y he firmado, te tienes que registrar y despues ya podrás firmar. Te traigo aqui la traducción al español del manifiesto que ha hecho la fsf.
Por tu derecho a usar software libre en máquinas con hardware libre!!
Microsoft ha anunciado que si los fabricantes de ordenadores quieren distribuir sus productos con el logo de compatible con Windows 8, deben implementar una medida llamada “arranque seguro”. Sin embargo, en la actualidad todavía no se sabe si esa tecnología está a la altura del nombre que se le ha puesto, o en vez de eso esconde un arranque restringido.
Usándolo de manera adecuada el “arranque seguro” está diseñado para proteger los equipos contra código malicioso (malware) evitando que se ejecuten programas no autorizados durante el proceso de arranque. En la práctica esto significa que los ordenadores que lleven esta medidano arrancarán sistemas operativos no autorizados., incluyendo tambien sistemas operativos no autorizados, que hayan sido modificados, y que no hayan sido re-aprobados.
Esto podría ser una característica que merezca ese nombre, siempre y cuando el usuario sea capaz de autorizar los programas que quiera usar, así como de ejecutar software libre escrito y modificado por él mismo, o por personas en las que confíe. Sin embargo nos preocupa que Microsoft o los fabricantes de hardware implementen estas restricciones en el arranque como una medida para prevenir que los usuarios no puedan utilizar otra cosa que no sea Windows. En este caso, es mejor llamar a esta tecnología “arranque restringido”, ya que este requisito sería una restricción desastrosa, para los usuarios de ordenadores y de ninguna manera una característica de seguridad.
Por favor añade tu nombre a la siguiente declaración, para mostrar a los fabricantes de ordenadores, goviernos, y a Microsoft que usted se preocupa sobre su propia libertad y trabajará activamente para protegerla:
“Nosotros, los abajo firmantes, instamos a todos los fabricantes de ordenadores que van a implementar el sistema de arranque seguro llamado UEFI, ha hacerlos de manera que permita que puedan instalarse sistemas operativos libres. Para respetar la libertad del usuario, y realmente proteger la seguridad del usuario, los fabricantes deben permitir a los propietarios de los ordenadores a deshabilitar las restricciones del arranque, o proporcionar de una manera segura una alternativa para instalar y ejecutar sistemas operativos libres de su propia elección. Nos comprometemos a que no fomentaremos ni recomendaremos marcas de ordenadores que eliminen esa libertad de elección tan importante, y recomendaremos activamente a la gente de nuestras comunidades a evitar esos sistemas cerrado”
Una vez leído lo puedes firmar en este enlace: www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement
—————————————————
Victorhck in the free world 