Filosofía de la ingeniería: Joanna Rutkowska

Puntos clave

• Construyó un sistema operativo de escritorio partiendo del supuesto de que sería comprometido. Joanna Rutkowska es la investigadora de seguridad polaca que creó Qubes OS – “un sistema operativo razonablemente seguro” – en torno al principio de seguridad por compartimentación. En lugar de intentar que el sistema esté libre de errores, Qubes divide tu vida digital en máquinas virtuales aisladas llamadas “qubes” (trabajo, personal, banca, no confiable), de modo que una brecha en una queda contenida y no puede alcanzar a las demás.¹²
• Su reputación ofensiva llegó primero – rompe sistemas para aprender a aislarlos. En la Black Hat de 2006 presentó Blue Pill, un rootkit de prueba de concepto que usaba la virtualización por hardware de AMD para deslizar un fino hipervisor malicioso por debajo de un sistema operativo en ejecución, atrapándolo dentro de una máquina virtual que no podía ver. Atacar las capas más profundas de la plataforma es lo que le enseñó en qué capas nunca debes confiar.³
• Convirtió “desconfía de la infraestructura” en arquitectura. En una conferencia magistral titulada “Security Through Distrusting”, Rutkowska sostuvo que el hábito de la industria de hacer “confiables” los componentes es ingenuo y no escala – es mejor tratar cualquier componente individual como potencialmente comprometido, desconfiar de casi todos y no tener ningún punto único de fallo.⁵ Qubes es ese argumento compilado en un escritorio funcional.²
• Sondeó las capas de la plataforma en las que todos los demás confiaban ciegamente. Más allá de Blue Pill, realizó un trabajo pionero atacando el System Management Mode y la Intel Trusted Execution Technology, y en 2009 acuñó el ataque de la “Doncella Malvada” (Evil Maid), venciendo el cifrado de disco completo como TrueCrypt mediante un breve acceso físico. Cada ataque trazaba un límite de confianza que resultaba ser una mentira.¹⁴

El principio

“Todo software contiene errores… En lugar de intentar prevenir cada posible explotación, Qubes asume que la explotación ocurrirá y se centra en contener el daño.” – la introducción de Qubes OS, parafraseando su justificación fundacional²

La mayor parte de la ingeniería de seguridad persigue un objetivo imposible. Auditas el código, parcheas los agujeros, refuerzas la configuración y te dices que, si eres lo bastante cuidadoso, el sistema será seguro. La trayectoria de Rutkowska es una demostración larga y paciente de que ese objetivo es un espejismo. Un escritorio moderno ejecuta decenas de millones de líneas de código – núcleo, controladores, navegador, lector de PDF, firmware – y cada una de esas líneas es un lugar donde puede esconderse un error. No los encontrarás todos, y a tu adversario solo le hace falta uno. Así que la pregunta honesta no es “¿cómo hago que esto esté libre de errores?”, sino “cuando – no si – algo entre, ¿hasta dónde puede llegar?”²

La respuesta que Rutkowska construyó es la seguridad por aislamiento. Si no puedes prevenir un compromiso, puedes decidir de antemano hasta dónde se propaga. Qubes divide la máquina en máquinas virtuales separadas – una para el trabajo, una para la banca, una para la navegación personal, una para abrir archivos adjuntos sospechosos – cada una ejecutándose sobre el hipervisor Xen con su propio límite. Abre un enlace malicioso en la qube no confiable y el malware aterriza en una sala sellada. Nunca compartió un límite de confianza con tu qube de banca, así que no puede alcanzar tus credenciales, y simplemente puedes desechar la qube comprometida.¹² El mundo físico ya funciona así: no votas, duermes y guardas dinero en la misma habitación sin dividir, y Qubes se pregunta por qué tu computadora sí lo hace.²

Hay una segunda mitad del principio, y es la más difícil: desconfía de la infraestructura y reduce aquello en lo que te ves obligado a confiar. En su conferencia “Security Through Distrusting”, Rutkowska sostuvo que llamar a un componente “confiable” no es un cumplido – es admitir que el componente es “capaz de destruir toda mi integridad de seguridad” si falla.⁵ Así que la disciplina consiste en tratar casi todos los componentes como potencialmente comprometidos, eliminar los puntos únicos de fallo y mantener la base de computación confiable – el código de cuya corrección depende todo lo demás – tan pequeña como te sea posible.⁵² Al final confiarás en algo. El arte está en hacer que ese algo sea diminuto, inspeccionable y escaso.

Contexto

Joanna Rutkowska nació en 1981 en Varsovia, Polonia, y obtuvo una maestría en informática en la Universidad Tecnológica de Varsovia.¹ No surgió como defensora sino como investigadora ofensiva, y una famosamente buena – a mediados de la década de 2000 estaba sondeando las capas más bajas y de mayor confianza de la plataforma x86, las capas que la seguridad defensiva suele tratar como terreno firme.

Su gran momento fue Blue Pill, demostrado en las Black Hat Briefings el 3 de agosto de 2006, junto con un trabajo que mostraba cómo vencer los mecanismos de protección del núcleo de Windows Vista. eWeek la nombró una de los “Cinco hackers que dejaron huella en 2006”.¹³ En abril de 2007 fundó Invisible Things Lab en Varsovia, la consultoría y el taller de investigación que se convirtió en el hogar de su trabajo en seguridad de plataformas.¹ Durante los años siguientes, ella y sus colaboradores – Alexander Tereshkin y Rafal Wojtczuk entre ellos – publicaron ataques contra el hipervisor Xen, contra la Intel Trusted Execution Technology y contra el System Management Mode, el modo de ejecución profundamente privilegiado de “ring -2” situado por debajo incluso del núcleo del sistema operativo.¹ En 2009 acuñó el ataque de la Doncella Malvada, una técnica de acceso físico que compromete el proceso de arranque de una laptop para robar la frase de contraseña del cifrado de disco completo, como TrueCrypt.⁴

Entonces hizo lo que los investigadores ofensivos rara vez hacen: construyó la defensa. El trabajo en Qubes OS comenzó alrededor de 2010 con Wojtczuk, y Qubes 1.0 se lanzó el 3 de septiembre de 2012, construido sobre el principio de la seguridad por compartimentación.¹ Lideró el proyecto durante años, y el enfoque obtuvo respaldos públicos de figuras tan diversas como Edward Snowden y el criptógrafo Daniel J. Bernstein.² En años posteriores se orientó hacia el trabajo en privacidad y descentralización; los detalles de sus proyectos más recientes se leen mejor en sus propios canales actuales que resumidos de segunda mano, y este artículo se atiene a lo que está firmemente documentado.¹

El trabajo

Qubes OS: seguridad por compartimentación

Empieza por aquí, porque Qubes es el principio convertido en algo que de verdad puedes ejecutar. El diseño parte por conceder la guerra que la mayoría de las herramientas de seguridad fingen estar ganando: todo software tiene errores, y algunos de esos errores son explotables.² Qubes no intenta ser el sistema irrompible. Intenta ser el sistema donde una ruptura no importa demasiado.

El mecanismo es el hipervisor Xen. Por debajo de todo se asienta un fino hipervisor y un dominio administrativo especial llamado dom0, que controla la pantalla y el hardware pero se mantiene deliberadamente fuera de la red. Por encima de él se ejecutan tus qubes – máquinas virtuales ligeras, cada una acotada a un propósito y un nivel de confianza.¹² Podrías mantener una qube de “trabajo”, una qube de “banca”, una qube “personal” y una qube “no confiable” para abrir cualquier cosa que haya llegado de un desconocido. Las ventanas de cada qube llevan un borde de color infalsificable, de modo que puedes ver de un vistazo a qué dominio de seguridad pertenece una ventana dada.² De manera crucial, las qubes comparten sistemas de archivos raíz mediante un sistema de plantillas, así que se mantienen ligeras y se parchean en conjunto, mientras que sus datos privados permanecen aislados.² Y para las tareas más arriesgadas existen las qubes desechables – máquinas virtuales que se levantan para abrir un solo PDF o un solo enlace y luego se autodestruyen, llevándose consigo cualquier infección.²

Por qué importa como ingeniería: Qubes redefine la unidad de seguridad pasándola de “la máquina” al “dominio”. En un escritorio normal, cada aplicación que ejecutas comparte un único espacio de confianza – tu navegador, tu software de impuestos y el archivo adjunto que no deberías haber abierto están todos a un mal error de distancia entre sí. Qubes convierte el límite entre dominios en un muro impuesto por hardware en lugar de una convención esperanzada. El costo es real – más RAM, más fricción, la disciplina de decidir a qué qube pertenece una tarea – y Rutkowska es sincera al reconocer que la seguridad mediante la desconfianza “no es una panacea” porque se negocia con la usabilidad.⁵ Pero la recompensa es que el peor de los casos deja de ser catastrófico. Un compromiso ya no es “se apoderan de mi computadora”. Es “se apoderan de una sala desechable que estoy a punto de eliminar”.

Romper la plataforma: Blue Pill, SMM y la Doncella Malvada

No puedes diseñar buenos límites de aislamiento hasta que sabes exactamente qué límites son falsos, y Rutkowska lo aprendió atacándolos. Blue Pill, su demostración en la Black Hat de 2006, es el caso más claro. Era un rootkit de prueba de concepto que explotaba la virtualización por hardware de AMD (AMD-V) para hacer algo audaz: arrancar un fino hipervisor en una máquina en ejecución y migrar el sistema operativo vivo a una máquina virtual por debajo de él, sobre la marcha.³ Desde dentro de esa máquina virtual, el sistema operativo vería un mundo normal – pero el hipervisor situado debajo podía interceptar “interrupciones de hardware, peticiones de datos e incluso la hora del sistema”, entregando al sistema operativo atrapado las respuestas que quisiera.³

Vale la pena ser preciso sobre lo que Blue Pill era y no era. Era una prueba de concepto, no malware encontrado en circulación, y su afirmación más audaz – que tal rootkit de hipervisor podía hacerse “100 % indetectable” – fue disputada, ya que otros investigadores propusieron una detección basada en tiempos.³ Pero el titular controvertido no es la lección. La lección es la superficie de ataque que expuso: el supuesto, horneado en cada sistema operativo, de que la capa sobre la que se ejecuta es benigna. Blue Pill demostró que la virtualización podía convertir la capa de mayor privilegio en el territorio propio del atacante – y que aquello en lo que confías que está “debajo” de ti es exactamente lo que no puedes verificar desde “arriba”.

El mismo instinto guió el resto de su trabajo ofensivo. Con colaboradores atacó el System Management Mode, el oscuro y ultraprivilegiado modo de firmware que se ejecuta por debajo del núcleo, y la Intel Trusted Execution Technology, una funcionalidad cuyo propósito entero era establecer la confianza.¹ Y en 2009 acuñó el ataque de la Doncella Malvada: deja una laptop cifrada desatendida en la habitación de un hotel, y una “doncella” con un breve acceso físico puede manipular el cargador de arranque no cifrado para que capture tu frase de contraseña la próxima vez que la teclees.⁴ El cifrado de disco completo como TrueCrypt era vulnerable porque el código de arranque no podía autenticarse ante el usuario – no tenías forma de saber si el cargador que pedía tu frase de contraseña seguía siendo el tuyo.⁴ Cada uno de estos ataques es un mapa de un límite de confianza que no se sostuvo. La arquitecta defensiva que más tarde construyó Qubes ya sabía, desde dentro, qué muros eran de carga y cuáles estaban pintados encima.

Desconfía de la infraestructura: reducir la base de computación confiable

Qubes no es solo “ejecuta todo en máquinas virtuales”. El principio de diseño más profundo es minimizar y desconfiar de la base de computación confiable – el conjunto de componentes de cuya corrección descansa la seguridad de todo el sistema. La conferencia de Rutkowska “Security Through Distrusting” enuncia la filosofía sin rodeos: el impulso convencional de hacer “confiables” los componentes es “demasiado ingenuo y no escalable”, porque en seguridad “confiable” en realidad significa que un componente es “capaz de destruir toda mi integridad de seguridad” si sale mal.⁵ La respuesta correcta es asumir que cualquier componente individual puede estar comprometido, desconfiar de casi todos y diseñar de modo que no haya ningún punto único de fallo.⁵

Puedes ver este principio en las decisiones concretas de Qubes. Al dominio administrativo dom0 se le niega deliberadamente el acceso a la red, porque un dom0 al que se pudiera llegar por la red sería un punto único cuyo compromiso se apodera de la máquina.² La red y el USB se empujan ellos mismos a sus propias qubes aisladas, de modo que un error en el controlador de una tarjeta de red o un dispositivo USB malicioso aterrice en un entorno aislado en lugar de en el núcleo en el que todo confía.² Los archivos que cruzan entre dominios se manejan defensivamente – la misma lógica de “trátalo como potencialmente vulnerado” que Rutkowska aplicó al modo en que Qubes procesa imágenes y PDF.⁵ Y las qubes desechables encarnan la desconfianza de la forma más directa: en lugar de confiar en que un lector de PDF no sea explotado, asumes que lo será, lo ejecutas en una máquina virtual que estás a punto de destruir y dejas que la explosión ocurra en una sala vacía.²

El hilo conductor es la humildad respecto a tu propio código. Un sistema que confía en un componente grande y complejo está haciendo una apuesta grande y compleja. La arquitectura de Rutkowska trabaja para hacer pequeña la apuesta – para reducir la base de computación confiable a un fino hipervisor y un dom0 aislado de la red, y para tratar casi todo lo que está por encima como prescindible, reemplazable y presuntamente hostil.²⁵

Del escritorio a la descentralización

Rutkowska lideró Qubes durante años, y luego se volcó hacia el problema más amplio que el sistema operativo solo resuelve en parte: incluso un escritorio perfectamente compartimentado sigue confiando en la infraestructura que lo rodea – el almacenamiento en la nube, la red, los servicios que albergan tus datos.¹⁵ Su trabajo posterior se orientó hacia la privacidad y la descentralización, extendiendo la misma desconfianza hacia afuera, desde la máquina individual hasta los sistemas con los que habla. La forma y el estado precisos de esos proyectos se toman mejor de su propia escritura actual que parafraseados aquí; lo que se traslada con limpieza es el principio, no el producto. El instinto es constante: asume que la infraestructura está comprometida, y diseña de modo que el supuesto te cueste lo menos posible.⁵

El método

Lee a través de Qubes, Blue Pill, los ataques al SMM y al TXT, y “Security Through Distrusting”, y los mismos compromisos se repiten. El método de Rutkowska es menos un eslogan que un conjunto de hábitos permanentes.

Asume el compromiso; diseña para el radio de la explosión. El movimiento fundacional es conceder que la prevención fallará y preguntar hasta dónde se propaga una brecha.² A escala, esto es el gemelo en seguridad de lo que Werner Vogels hace por la fiabilidad – todo falla todo el tiempo, así que contén el radio de la explosión en lugar de fingir que puedes evitar el fallo. La lección se traslada mucho más allá de Qubes: no diseñes para el caso en que nada entra; diseña de modo que cuando algo entre, quede atrapado en una celda pequeña y desechable. Es la regla de la evidencia aplicada a la seguridad – “nadie ha entrado todavía” no es evidencia; “una brecha aquí no puede alcanzar allá” sí lo es.

Desconfía de la infraestructura y demuestra el límite. Trata cada componente como potencialmente vulnerado y rehúsa otorgar confianza por defecto.⁵ Esto es “Reflections on Trusting Trust” de Thompson convertido en arquitectura de escritorio: no puedes confiar en lo que no has examinado, así que deja de confiar en las capas que no puedes ver y amúrallalas en su lugar. La disciplina consiste en preguntar de cada componente: “si esto está comprometido, ¿qué se apropia?” – y redibujar los límites hasta que la respuesta sea “casi nada”.

Rómpelo tú mismo antes de que lo haga otro. La defensa de Rutkowska está construida sobre una década de ofensiva – Blue Pill, SMM, Doncella Malvada – porque no puedes aislar un límite que no has demostrado primero que es falso.³⁴ Este es el instinto exacto que Adi Shamir llevó a la criptografía: atacar para defender, y confiar solo en lo que sobrevive a un intento serio de romperlo. El hábito permanente es ponerse primero el sombrero del atacante, trazar cuáles de tus supuestos de confianza son mentiras, y diseñar los muros donde estaban las mentiras.

Reduce la base de computación confiable. Cuantas menos líneas de código dependa tu seguridad, más pequeña es tu apuesta.²⁵ Un fino hipervisor y un dom0 aislado de la red son una apuesta inspeccionable; un núcleo monolítico con cada controlador y servicio dentro del límite de confianza es una apuesta a ciegas. Es el producto mínimo digno aplicado a la confianza: la base confiable más limpia es la más pequeña que aún cumple su única tarea. Reduce la confianza a lo que debe ser confiable, y presume hostil al resto.

Sé honesta sobre el compromiso. Rutkowska no exagera – dice claramente que la seguridad mediante la desconfianza “no es una panacea” y cuesta usabilidad y comodidad.⁵ El hábito consiste en nombrar el precio de la seguridad que estás comprando en lugar de ocultarlo, para que el siguiente ingeniero pueda sopesarlo. Esa franqueza es la calidad es la única variable aplicada a la seguridad: la garantía real, enunciada con sus costos, vale más que una promesa cómoda que en silencio no se sostiene. Un límite que comprendiste y elegiste supera a uno que asumiste y heredaste.

Cadena de influencia

Quiénes la formaron

La comunidad de investigación ofensiva de mediados de la década de 2000. Rutkowska ascendió dentro de la cultura del ataque a plataformas de Black Hat y del hacking de sistemas de bajo nivel, donde el trabajo consistía en encontrar el supuesto que nadie cuestionaba y romperlo.³ El reflejo central de esa cultura – desconfía de la capa en la que todos confían – se convirtió en la columna vertebral de su trabajo defensivo. (Influencia formativa)

La ola de la virtualización por hardware. Blue Pill solo fue posible porque AMD-V e Intel VT-x acababan de llevar la virtualización por hardware al uso generalizado.³ La misma tecnología que usó como arma en 2006 se convirtió en el fundamento sobre el que construyó el aislamiento en Qubes, donde Xen convierte el hipervisor de herramienta del atacante en muro del defensor.¹² (Influencia directa)

El linaje de la seguridad de Xen y de los hipervisores. Sus años analizando y atacando Xen le enseñaron exactamente cuán fuerte – y cuán frágil – es el aislamiento de los hipervisores, un conocimiento que dio forma a la decisión de Qubes de mantener dom0 fuera de la red y empujar los controladores a dominios aislados.¹² (Influencia formativa)

A quiénes formó

La computación consciente de la privacidad. Qubes se convirtió en el escritorio recomendado para periodistas, activistas e investigadores de seguridad que necesitan asumir un compromiso dirigido – una herramienta real para personas cuyo modelo de amenaza es un Estado, no un eslogan.²

La mentalidad de la compartimentación. La “seguridad por aislamiento” y “reduce la base de computación confiable” se propagaron mucho más allá de Qubes, hasta cómo se razona sobre el sandboxing, el aislamiento de contenedores y la virtualización por aplicación en toda la industria.²⁵

Los defensores que rompen primero. Rutkowska es un ejemplo permanente de que los arquitectos defensivos más fuertes suelen ser antiguos atacantes – de que trazar los límites de confianza reales rompiéndolos es el requisito previo para dibujarlos correctamente.³⁴

El hilo conductor

Rutkowska es la piedra angular del aislamiento de esta serie – la figura que responde a “el sistema será vulnerado” no con desesperación sino con arquitectura. Adi Shamir ataca para defender en criptografía, confiando solo en lo que sobrevive a un intento real de romperlo; Rutkowska ejecuta ese mismo bucle una capa más abajo, rompiendo hipervisores y cadenas de arranque para poder construir un escritorio que sobreviva a su compromiso.³⁴ Thompson y Ritchie nos dieron la advertencia de que no puedes confiar en lo que no construiste y examinaste tú mismo; el “desconfía de la infraestructura” de Rutkowska es esa advertencia convertida en un sistema operativo en funcionamiento, donde las capas no confiables están amuralladas en lugar de ser objeto de esperanza.⁵ Y donde Werner Vogels dice todo falla todo el tiempo, así que contén el radio de la explosión para la fiabilidad, Rutkowska dice lo mismo para la seguridad: Radia Perlman diseñó redes asumiendo que el caso hostil y que falla es el centro del diseño, y Rutkowska diseña máquinas de esa manera. Donde Vogels contiene un disco que falla y Perlman contiene un enlace que falla, Rutkowska dice: el atacante ya está dentro – así que aísla cada dominio, desconfía de cada capa y haz de la brecha una sala desechable que puedas tirar a la basura. (Puente de la serie)

Lo que me llevo de esto

La lección que conservo de Rutkowska es diseñar para la brecha, no contra ella. Mi instinto, como el de la mayoría de los constructores, es reforzar la cosa – validar la entrada, parchear la dependencia, bloquear la configuración – y tratar la seguridad como un muro que intento hacer lo bastante alto. “Todo software contiene errores” es el reproche: el muro será vulnerado, porque siempre hay un error más, y la pregunta que de verdad importa es qué alcanza el atacante una vez que está al otro lado. Así que cuando ahora construyo algo – un límite de autenticación, un servicio que ejecuta entrada no confiable, una funcionalidad que toca dinero – intento preguntar “cuando esto sea comprometido, ¿cuál es el radio de la explosión?” antes de preguntar “¿cómo lo mantengo fuera?”. La versión honesta de seguro no es “no veo cómo esto se rompe”. Es “cuando se rompa, el daño queda atrapado en una sala que puedo eliminar”.

La segunda lección es una paranoia razonable respecto a aquello en lo que me veo obligado a confiar. Es fácil dejar pasar un componente como “confiable” y seguir adelante, pero Rutkowska redefinió esa palabra para mí: llamar algo confiable es admitir que puede destruirlo todo si falla. Eso cambió cómo trazo los límites. Cada biblioteca que incorporo, cada servicio del que dependo, cada capa sobre la que me ejecuto es una apuesta a que es correcta – y el tamaño de la apuesta es el tamaño de mi base de computación confiable. Así que intento mantener esa base pequeña e inspeccionable, empujar lo arriesgado y lo complejo a entornos aislados que presumo hostiles, y ser honesto, como lo es ella, en que el aislamiento me cuesta comodidad. La paranoia no es pesimismo. Es la disciplina de saber exactamente en qué estoy confiando, y hacer esa lista tan corta como me sea posible.

FAQ

¿Qué es Qubes OS?

Qubes OS es un sistema operativo de escritorio gratuito, de código abierto y orientado a la seguridad, creado por Joanna Rutkowska, descrito por el proyecto como “un sistema operativo razonablemente seguro”.² Usa el hipervisor Xen para dividir tu computación en máquinas virtuales aisladas llamadas qubes – compartimentos separados para actividades como el trabajo, la banca, la navegación personal y la apertura de archivos no confiables. Como las qubes están aisladas, un compromiso en una no puede alcanzar a las demás, así que el daño de cualquier brecha individual queda contenido. También admite qubes desechables que se autodestruyen tras su uso, y le da a cada dominio un borde de ventana de color infalsificable para que puedas ver a qué compartimento pertenece una ventana.¹²

¿Qué es la seguridad por aislamiento (compartimentación)?

La seguridad por aislamiento, o compartimentación, es el principio en el corazón de Qubes: en lugar de intentar que el software esté libre de errores, asumes que el compromiso ocurrirá y contienes el daño dividiendo el sistema en dominios aislados.² La introducción de Qubes hace la analogía con la vida física – naturalmente separas las actividades en habitaciones distintas – y la aplica a una computadora donde, de lo contrario, todo compartiría un único límite de confianza.² La mitad complementaria es “desconfía de la infraestructura”: trata cada componente como potencialmente comprometido, elimina los puntos únicos de fallo y mantén la base de computación confiable tan pequeña como sea posible.⁵

¿Qué era Blue Pill?

Blue Pill era un rootkit de prueba de concepto que Joanna Rutkowska demostró en la Black Hat el 3 de agosto de 2006. Usaba la virtualización por hardware de AMD (AMD-V) para arrancar un fino hipervisor malicioso en una máquina en ejecución y migrar el sistema operativo vivo a una máquina virtual por debajo de él, de modo que el hipervisor pudiera interceptar y falsear la visión que el sistema operativo tenía del hardware, las interrupciones e incluso la hora del sistema.³ La afirmación de Rutkowska de que tal rootkit podía ser “100 % indetectable” fue disputada, ya que otros investigadores propusieron una detección basada en tiempos. Era una demostración de investigación de una superficie de ataque – el supuesto de que la capa por debajo de tu sistema operativo es benigna – no malware encontrado en circulación.³

¿Qué es el ataque de la Doncella Malvada?

El ataque de la Doncella Malvada es una técnica de acceso físico que Joanna Rutkowska nombró en una entrada de blog de 2009. Si un atacante consigue un breve acceso sin supervisión a una laptop cifrada y desatendida – en la habitación de un hotel, por ejemplo – puede manipular el código de arranque no cifrado para que capture en secreto la frase de contraseña de cifrado de disco completo del usuario la próxima vez que se introduzca.⁴ Los sistemas de cifrado de disco completo como TrueCrypt eran vulnerables porque el cargador de arranque no podía autenticarse ante el usuario, así que la víctima no tenía forma de distinguir el cargador comprometido del legítimo.⁴ Es una demostración vívida de que el cifrado por sí solo no protege una máquina que un adversario puede tocar físicamente.

Fuentes