El porqué del retraso del Secure Boot de la Linux Foundation

Volvemos de nuevo con el tema de UEFI, del que supongo que ya estáis informados. En caso contrario podéis ver de que va la cosa en este enlace
Para poneros en antecedentes, Secure Boot forma parte de UEFI y es lo que impide la ejecución en el cargador de arranque de otros sistemas operativos que no estén autorizados o firmados digitalmente por la autoridad competente, autoridad que se supone es independiente de los de Redmon.
El caso es que la Fundación Linux ya tiene desarrollada una solución para ese problema, llamada Secure Boot Linux, que fue anunciada oficialmente el pasado día 10 de octubre.
James Bottomley, nos explicaba algunas características técnicas de esta solución y se sentía contento de ello:

“En pocas palabras, la Fundación Linux obtendrá una clave de Microsoft para firmar un pequeño precargador de arranque para Linux (o cualquier otro sistema operativo)”

Aparentemente, la solución de la Linux Foundation, no debería tener mayor problema en poder estar presente en nuestros sistemas, si está realizada bajo los cánones que impone esta autoridad independiente. Pero al parecer eso es más fácil decirlo que hacerlo.


Debido a la tardanza y a las preguntas de los usuarios, es el propio James Bottomley, quien de nuevo a través del blog de la fundación nos explica el periplo para conseguir algo que en principio parecía tan sencillo y porqué se están retrasando.

Os lo resumo, ya que es un poco largo:



Lo primero que hicieron era pagar los $99 que cuesta obtener la clave del certificado VeriSign. Esto es necesario para que el sistema sysdev de Microsoft certifique que eres quien dices ser. Después de algunos problemas debido a que te envían un ejecutable para plataformas Windows. Consigue solventar este primer paso con éxito y llega la hora de firmar un complicado contrato donde se excluyen gran parte de las licencias, “incluidas las GPL para los conductores, pero no para los gestores de arranque”. Los abogados dieron el visto bueno con la promesa de Matthew Garrett, “Microsoft está dispuesto a negociar acuerdos especiales con las distribuciones para mitigar algunos de estos problemas”.

Hasta aquí todo más o menos bien, o todo lo bien que se puede esperar de la burocracia.

Con todo preparado, llega la hora de cargar un binario UEFI junto con su firma y aquí es cuando llegan los problemas.

“En primer lugar hay que envolver el binario en un archivo contenedor de Microsoft. Afortunadamente, existe un proyecto de código abierto que puede crear archivos contenedores llamados lcab. Usted tiene que firmar el archivo contenedor con su clave Verisign. Una vez más, hay un proyecto de código abierto que puede hacer esto: osslsigncode. El problema final es que la carga de archivos requiere Silverlight“.

Después de sortear estos pasos, le informan que el binario firmado no puede estar licenciado bajo GPLv3 o similares. “Supongo que el temor aquí es la revelación de la clave, pero no está del todo claro”.
Se cambia el tipo de licencia y se procede a la carga del binario que consta de siete pasos, pero se queda en el paso seis con un error. Después de varios días intentando solucionarlo, se pone en contacto con el soporte de Microsoft vía e-mail y recibe la siguiente respuesta:

“El código de error producido por nuestro proceso de firma es que el archivo no es una aplicación Win32 válida. ¿Es una aplicación Win32 válida? “. Respuesta: Obviamente no, es un binario de 64 bits válido para UEFI. No volvieron a contestar…”

Después de varios intentos, consigue que le envíen el archivo correctamente firmado. Se comprueba que el archivo funciona en la plataforma de arranque seguro y se firma correctamente con la clave.

subject=/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
issuer=/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011

Sin embargo lanza un mensaje de error que dice “la firma fracasó”. Al ponerse de nuevo en contacto con ellos, recibe como única respuesta, “No use ese archivo que no está correctamente firmado. Me pondré en contacto con usted”. Y sigue esperando…

Al parecer la clave es una genérica de Microsoft, en lugar de una específica para la Linux Foundation.

Estos son los motivos por los que aún no es posible disponer de este Secure Boot Linux y no se sabe a ciencia cierta lo que se tardará en tenerlo listo, pero nos asegura que en cuanto estén solventados los problemas se subirá a la web para que esté disponible para todo el mundo.

Podéis ver el articulo completo de James Bottomley, en este enlace. http://blog.hansenpartnership.com/adventures-in-microsoft-uefi-signing/



Fuente: http://linuxzone.es/2012/11/22/el-porque-del-retraso-del-secure-boot-de-la-linux-foundation/