Arranque seguro y arranque restringido

Esto es una traducción del artículo “Secure Boot and Restricted Boot” escrito por Matthew Garrett y publicado el 26 de marzo de 2013. El repositorio git que he usado para la traducción sigue activo, por si alguien tiene alguna contribución o quiere iniciar la traducción a otro idioma.

Este fin de semana di una presentación en Libreplanet sobre el tema del arranque seguro y arranque restringido. Hay una copia del vídeo aquí – en algún momento se subirá al sitio de la conferencia. Ha resultado ser en un momento excelente, pues esta mañana, un grupo de España ha demandado a Microsoft ante la Comisión Europea, argumentando que la imposición de Microsoft del arranque seguro en el mercado de PC clientes x86 es anticompetitiva. Sospecho que es improbable que tenga éxito (la Comisión ya ha establecido que la implementación actual parece ser conforme a la ley de la UE), y me temo que esto va a hacer más difícil luchar la batalla real que enfrentamos.

Arranque seguro significa diferentes cosas para diferentes personas. Creo que la definición de la FSF es una definición útil: arranque seguro es cualquier esquema de validación de arranque en el cual el control último está en las manos del propietario del dispositivo, mientras que arranque restringido es cualquier esquema de validación de arranque en el cual el control último está en manos de un tercero. Lo que Microsoft requiere para los dispositivos x86 con Windows 8 cae en la categoría de arranque seguro: asumiendo que las OEMs se ajustan a los requisitos de Microsoft, el usuario debe poder deshabilitar el arranque seguro completamente, y también poder dejar el arranque seguro habilitado, pero con su propia elección de claves y binarios de confianza. Si la FSF establece un servicio de firma para firmar sistemas operativos que cumplan todos sus requisitos de libertad, los requisitos de Microsoft permitirían a un usuario final configurar su sistema de tal manera que rechazara ejecutar software no libre. Mi sistema está configurado para confiar en lo que me envíe Fedora o haya compilado yo en local, una decisión que yo puedo tomar porque Microsoft requiere que las OEMs lo soporten. Cualquier sistema que cumpla con los requisitos de Microsoft es un sistema que respeta la libertad del propietario del ordenador para elegir cómo de restrictiva es la política de arranque de su sistema.

Decir esto no es decir que esto es ideal. La falta de una interfaz de usuario o formatos de clave comunes entre los proveedores de hardware hace difícil para los proveedores de sistemas operativos documentar los pasos que el usuario debe seguir para ejercer esta libertad. La presencia de Microsoft como la única autoridad de claves confiable de manera amplia, deja a las personas preocupadas, de manera justificada, sobre si Microsoft será igual de agresiva en poner en la lista negra sus propios productos que poniendo en la lista negra productos de terceros. Los fallos de implementación en un (muy) pequeño número de sistemas han resultado en sistemas operativos firmados correctamente que fallan al arrancar, requiriendo a los usuarios actualizar su firmware antes de poder instalar cualquier otra cosa distinta a Windows.

Pero concentrarse en estos problemas pierde de vista el punto importante. El mercado x86 permanece como uno donde los usuarios son capaces de ejecutar lo que quieran, pero el mercado x86 se está empequeñeciendo. Los usuarios están comprando tabletas y otros ultraportátiles basados en ARM. Algunos usuarios usan sus teléfonos como su primer dispositivo de tipo ordenador. En contraste con el mercado x86, las políticas de Microsoft para el mercado ARM restringen la libertad del usuario. Requieren que los dispositivos con Windows Phone y Windows RT arranquen solamente binarios firmados, sin opción para el usuario final de deshabilitar la validación de firmas o instalar sus propias claves. Aunque la tecnología que subyace es idéntica, este conjunto distinto de políticas predeterminadas significa que la implementación de Microsoft en ARM se describe mejor como arranque restringido. Los proveedores de hardware y Microsoft definen qué software se ejecutará en esos sistemas. Los propietarios no tienen voz.

Y, desgraciadamente, Microsoft no está sola. Apple, el mayor proveedor individual de este mercado, implementa de manera efectiva restricciones idénticas. Algunos proveedores de Android proporcionan secuencias de inicio desbloqueables, pero otros (ya sea a través de preferencias personales o por imposiciones de las operadoras de telefonía) bloquean sus plataformas. Un usuario naif puede que acabe comprando un dispositivo que, para evitar que se exploten fallos de seguridad, rechace funcionar si algún componente de sistema es modificado. Incluso en casos en los que los componentes que subyacen estén construidos usando software libre, no hay garantía de que el usuario tenga la posibilidad de ejercer esas libertades.

¿Por qué es importante esto? Algunas de esas plataformas (sobre todo Windows RT e iOS, pero también algunos dispositivos basados en Android) rechazarán ejecutar aplicaciones no firmadas. Los usuarios no pueden escribir su propio software y distribuirlo a otros sin tener que acceder a restricciones muchas veces onerosas. Los usuarios con la mala suerte de vivir en el país equivocado pueden incluso tenerlo prohibido. El proveedor puede escoger bloquear aplicaciones que compitan con las suyas propias, reduciendo la innovación. La posibilidad de explorar y cacharrear con los componentes de un sistema se ve restringida, haciendo más difícil a los usuarios aprender cómo funcionan los sistemas operativos modernos. Si yo poseo un teléfono perfectamente funcional que ya no recibe actualizaciones del proveedor, no tengo siquiera la opción de pagar a un tercero para asegurarme de que no voy a estar comprometido por un sitio web malicioso y afronto el riesgo de perder claves o detalles financieros. Se está dañando directamente al usuario con estas restricciones.

No voy a argumentar que no hay beneficios en los ecosistemas de software tutelados. No voy a argumentar siquiera contra los dispositivos que se proporcionan con una política bloqueada de manera predefinida. Voy a argumentar con fuerza que el propietario de un dispositivo debería no sólo tener la libertad de escoger si desea permanecer dentro de esos límites restringidos, sino que también debería tener la libertad para imponer sus propios límites. No debería haber elección obligada entre libertad y seguridad.

Aquellos que argumentan contra el arranque seguro ponen en riesgo nuestra libertad de tomar una decisión personal sobre en quién confiar. Aquellos que argumentan contra el arranque seguro ignorando el arranque restringido ponen en riesgo mucho más para todos nosotros. El mercado tradicional del PC está decreciendo en importancia. A no ser que hagamos algo sobre esto, el software libre estará limitado a un grupo nicho de entusiastas que han escogido con cuidado sus dispositivos de entre un conjunto pequeño de ellos, que respetan las libertades del usuario. Deberíamos haber estado haciendo campañas contra el arranque restringido desde hace 10 años. No lo retrasemos aún más luchando contra implementaciones que sí respetan la libertad del usuario.
26 de Marzo de 2013 07:25 pm

About larjona

My name is Laura Arjona, I am a libre software user and fan of the free culture. If you want to contact me you can write an email to larjona [at] larjona [dot] net I am @larjona at identi.ca in the Pump.io social network. --- Me llamo Laura Arjona, soy usuaria de software libre y fan de la cultura libre. Si quieres contactar conmigo puedes escribir a larjona [en] larjona [punto] net Soy @larjona en el servidor identi.ca, de la red social Pump.io.
This entry was posted in Videos, Writings (translations) and tagged , , , , , , , . Bookmark the permalink.

2 Responses to Arranque seguro y arranque restringido

  1. Brigo says:

    Muy interesante. Gracias por la traducción. Me ha quedado mucho más claro todo lo relativo a UEFI, el concepto arranque seguro versus arranque restringido es la clave.

  2. sosias says:

    Gracias por tu tiempo, es un artículo muy esclarecedor. Muy bien por el repo git🙂

Comments are closed.