Filosofia de engenharia: Joanna Rutkowska

Principais conclusões

• Ela construiu um sistema operacional de desktop partindo do pressuposto de que ele seria comprometido. Joanna Rutkowska é a pesquisadora de segurança polonesa que criou o Qubes OS – “um sistema operacional razoavelmente seguro” – em torno do princípio da segurança por compartimentação. Em vez de tentar deixar o sistema livre de bugs, o Qubes divide sua vida digital em máquinas virtuais isoladas chamadas “qubes” (trabalho, pessoal, banco, não confiável), de modo que uma brecha em uma fica contida e não consegue alcançar as outras.¹²
• Sua reputação ofensiva veio primeiro – ela quebra sistemas para aprender a isolá-los. Na Black Hat de 2006 ela apresentou o Blue Pill, um rootkit de prova de conceito que usava a virtualização por hardware da AMD para deslizar um fino hipervisor malicioso por baixo de um sistema operacional em execução, prendendo-o dentro de uma máquina virtual que ele não conseguia ver. Atacar as camadas mais profundas da plataforma foi o que lhe ensinou em quais camadas você nunca deve confiar.³
• Ela transformou “desconfie da infraestrutura” em arquitetura. Em uma palestra intitulada “Security Through Distrusting”, Rutkowska argumentou que o hábito da indústria de tornar componentes “confiáveis” é ingênuo e não escala – é melhor tratar qualquer componente individual como potencialmente comprometido, desconfiar de quase todos eles e não ter nenhum ponto único de falha.⁵ O Qubes é esse argumento compilado em um desktop funcional.²
• Ela sondou as camadas da plataforma em que todos os outros confiavam cegamente. Além do Blue Pill, ela fez um trabalho pioneiro atacando o System Management Mode e a Intel Trusted Execution Technology, e em 2009 cunhou o ataque da “Empregada Malvada” (Evil Maid), derrotando a criptografia de disco completo como o TrueCrypt por meio de um breve acesso físico. Cada ataque mapeava um limite de confiança que se revelava uma mentira.¹⁴

O princípio

“Todo software contém bugs… Em vez de tentar prevenir cada exploração possível, o Qubes assume que a exploração vai acontecer e foca em conter o dano.” – a introdução do Qubes OS, parafraseando sua justificativa fundadora²

A maior parte da engenharia de segurança persegue um alvo impossível. Você audita o código, corrige os buracos, reforça a configuração e diz a si mesmo que, se for cuidadoso o bastante, o sistema será seguro. A trajetória de Rutkowska é uma demonstração longa e paciente de que esse alvo é uma miragem. Um desktop moderno executa dezenas de milhões de linhas de código – kernel, drivers, navegador, leitor de PDF, firmware – e cada uma dessas linhas é um lugar onde um bug pode se esconder. Você não vai encontrar todos, e seu adversário só precisa de um. Então a pergunta honesta não é “como faço para isto ficar livre de bugs?”, mas “quando – não se – algo entrar, até onde ele consegue chegar?”²

A resposta que Rutkowska construiu é a segurança por isolamento. Se você não consegue prevenir um comprometimento, você pode decidir de antemão até onde ele se espalha. O Qubes divide a máquina em máquinas virtuais separadas – uma para o trabalho, uma para o banco, uma para a navegação pessoal, uma para abrir anexos suspeitos – cada uma rodando sobre o hipervisor Xen com seu próprio limite. Abra um link malicioso na qube não confiável e o malware cai em uma sala lacrada. Ele nunca compartilhou um limite de confiança com sua qube de banco, então não consegue alcançar suas credenciais, e você pode simplesmente descartar a qube comprometida.¹² O mundo físico já funciona assim: você não vota, dorme e guarda dinheiro no mesmo cômodo sem divisórias, e o Qubes pergunta por que o seu computador faz isso.²

Há uma segunda metade do princípio, e ela é a mais difícil: desconfie da infraestrutura e reduza aquilo em que você é obrigado a confiar. Em sua palestra “Security Through Distrusting”, Rutkowska argumentou que chamar um componente de “confiável” não é um elogio – é admitir que o componente é “capaz de destruir toda a minha integridade de segurança” se falhar.⁵ Então a disciplina é tratar quase todos os componentes como potencialmente comprometidos, remover pontos únicos de falha e manter a base de computação confiável – o código de cuja correção tudo o mais depende – tão pequena quanto você possivelmente conseguir.⁵² No fim, você vai confiar em alguma coisa. A arte está em fazer com que essa alguma coisa seja minúscula, inspecionável e em pouca quantidade.

Contexto

Joanna Rutkowska nasceu em 1981 em Varsóvia, na Polônia, e obteve um mestrado em ciência da computação pela Universidade de Tecnologia de Varsóvia.¹ Ela não surgiu como defensora, mas como pesquisadora ofensiva, e uma famosamente boa – em meados dos anos 2000 ela estava sondando as camadas mais baixas e de maior confiança da plataforma x86, as camadas que a segurança defensiva costuma tratar como terreno sólido.

Seu grande momento foi o Blue Pill, demonstrado nas Black Hat Briefings em 3 de agosto de 2006, ao lado de um trabalho que mostrava como derrotar os mecanismos de proteção do kernel do Windows Vista. A eWeek a nomeou uma das “Cinco hackers que deixaram sua marca em 2006”.¹³ Em abril de 2007 ela fundou o Invisible Things Lab em Varsóvia, a consultoria e oficina de pesquisa que se tornou o lar de seu trabalho em segurança de plataformas.¹ Ao longo dos anos seguintes, ela e seus colaboradores – Alexander Tereshkin e Rafal Wojtczuk entre eles – publicaram ataques contra o hipervisor Xen, contra a Intel Trusted Execution Technology e contra o System Management Mode, o modo de execução profundamente privilegiado de “ring -2” situado abaixo até mesmo do kernel do sistema operacional.¹ Em 2009 ela cunhou o ataque da Empregada Malvada, uma técnica de acesso físico que compromete o processo de inicialização de um laptop para roubar a frase secreta da criptografia de disco completo, como o TrueCrypt.⁴

Então ela fez o que pesquisadores ofensivos raramente fazem: construiu a defesa. O trabalho no Qubes OS começou por volta de 2010 com Wojtczuk, e o Qubes 1.0 foi lançado em 3 de setembro de 2012, construído sobre o princípio da segurança por compartimentação.¹ Ela liderou o projeto por anos, e a abordagem recebeu endossos públicos de figuras tão variadas quanto Edward Snowden e o criptógrafo Daniel J. Bernstein.² Em anos posteriores ela se voltou para o trabalho em privacidade e descentralização; os detalhes de seus projetos mais recentes são mais bem lidos em seus próprios canais atuais do que resumidos de segunda mão, e este texto se atém ao que está firmemente documentado.¹

O trabalho

Qubes OS: segurança por compartimentação

Comece por aqui, porque o Qubes é o princípio transformado em algo que você realmente pode executar. O projeto começa concedendo a guerra que a maioria das ferramentas de segurança finge estar vencendo: todo software tem bugs, e alguns desses bugs são exploráveis.² O Qubes não tenta ser o sistema inquebrável. Ele tenta ser o sistema em que uma quebra não importa muito.

O mecanismo é o hipervisor Xen. Por baixo de tudo fica um fino hipervisor e um domínio administrativo especial chamado dom0, que controla a tela e o hardware mas é deliberadamente mantido fora da rede. Acima dele rodam suas qubes – máquinas virtuais leves, cada uma delimitada a um propósito e a um nível de confiança.¹² Você poderia manter uma qube de “trabalho”, uma qube de “banco”, uma qube “pessoal” e uma qube “não confiável” para abrir qualquer coisa que tenha chegado de um estranho. As janelas de cada qube carregam uma borda colorida infalsificável, de modo que você pode ver de relance a qual domínio de segurança uma dada janela pertence.² De forma crucial, as qubes compartilham sistemas de arquivos raiz por meio de um sistema de templates, então elas se mantêm leves e são corrigidas em conjunto, enquanto seus dados privados ficam isolados.² E para as tarefas mais arriscadas existem as qubes descartáveis – máquinas virtuais que sobem para abrir um único PDF ou um único link e depois se autodestroem, levando junto qualquer infecção.²

Por que isso importa como engenharia: o Qubes redefine a unidade de segurança, passando-a de “a máquina” para “o domínio”. Em um desktop normal, cada aplicativo que você executa compartilha um único espaço de confiança – seu navegador, seu software de impostos e o anexo que você não deveria ter aberto estão todos a um bug ruim de distância uns dos outros. O Qubes torna o limite entre domínios um muro imposto por hardware, em vez de uma convenção esperançosa. O custo é real – mais RAM, mais atrito, a disciplina de decidir a qual qube uma tarefa pertence – e Rutkowska é franca ao reconhecer que a segurança pela desconfiança “não é uma panaceia” porque negocia com a usabilidade.⁵ Mas a recompensa é que o pior caso deixa de ser catastrófico. Um comprometimento não é mais “eles dominaram meu computador”. É “eles dominaram uma sala descartável que eu estou prestes a apagar”.

Quebrando a plataforma: Blue Pill, SMM e a Empregada Malvada

Você não consegue projetar bons limites de isolamento até saber exatamente quais limites são falsos, e Rutkowska aprendeu isso atacando-os. O Blue Pill, sua demonstração na Black Hat de 2006, é o caso mais claro. Era um rootkit de prova de conceito que explorava a virtualização por hardware da AMD (AMD-V) para fazer algo audacioso: iniciar um fino hipervisor em uma máquina em execução e migrar o sistema operacional vivo para uma máquina virtual abaixo dele, em tempo real.³ De dentro dessa máquina virtual, o sistema operacional veria um mundo normal – mas o hipervisor abaixo dele podia interceptar “interrupções de hardware, requisições de dados e até a hora do sistema”, entregando ao sistema operacional preso as respostas que bem entendesse.³

Vale a pena ser preciso sobre o que o Blue Pill era e não era. Era uma prova de conceito, não um malware encontrado em circulação, e sua afirmação mais ousada – que tal rootkit de hipervisor poderia ser feito “100% indetectável” – foi contestada, com outros pesquisadores propondo uma detecção baseada em tempo.³ Mas a manchete controversa não é a lição. A lição é a superfície de ataque que ele expôs: o pressuposto, embutido em todo sistema operacional, de que a camada sobre a qual ele roda é benigna. O Blue Pill mostrou que a virtualização podia transformar a camada de maior privilégio no território do atacante – e que aquilo em que você confia que está “abaixo” de você é exatamente o que você não consegue verificar de “cima”.

O mesmo instinto conduziu o resto de seu trabalho ofensivo. Com colaboradores, ela atacou o System Management Mode, o obscuro e hiperprivilegiado modo de firmware que roda abaixo do kernel, e a Intel Trusted Execution Technology, um recurso cujo propósito inteiro era estabelecer confiança.¹ E em 2009 ela cunhou o ataque da Empregada Malvada: deixe um laptop criptografado sem supervisão em um quarto de hotel, e uma “empregada” com um breve acesso físico pode adulterar o carregador de inicialização não criptografado para que ele capture sua frase secreta na próxima vez que você a digitar.⁴ A criptografia de disco completo como o TrueCrypt era vulnerável porque o código de inicialização não conseguia se autenticar ante o usuário – você não tinha como saber se o carregador que pedia sua frase secreta ainda era o seu.⁴ Cada um desses ataques é um mapa de um limite de confiança que não se sustentou. A arquiteta defensiva que mais tarde construiu o Qubes já sabia, por dentro, quais muros eram estruturais e quais eram apenas pintados.

Desconfie da infraestrutura: reduzindo a base de computação confiável

O Qubes não é só “rode tudo em máquinas virtuais”. O princípio de projeto mais profundo é minimizar e desconfiar da base de computação confiável – o conjunto de componentes de cuja correção repousa a segurança de todo o sistema. A palestra de Rutkowska “Security Through Distrusting” enuncia a filosofia sem rodeios: o impulso convencional de tornar componentes “confiáveis” é “ingênuo demais e não escalável”, porque, em segurança, “confiável” na verdade significa que um componente é “capaz de destruir toda a minha integridade de segurança” se der errado.⁵ A resposta correta é assumir que qualquer componente individual pode estar comprometido, desconfiar de quase todos eles e projetar de modo que não haja nenhum ponto único de falha.⁵

Você pode ver esse princípio nas escolhas específicas do Qubes. Ao domínio administrativo dom0 é deliberadamente negado o acesso à rede, porque um dom0 que pudesse ser alcançado pela rede seria um ponto único cujo comprometimento domina a máquina.² A rede e o USB são eles próprios empurrados para suas próprias qubes isoladas, de modo que um bug no driver de uma placa de rede ou um dispositivo USB malicioso caia em um ambiente isolado em vez de no kernel em que tudo confia.² Arquivos que cruzam entre domínios são tratados defensivamente – a mesma lógica de “trate-o como potencialmente invadido” que Rutkowska aplicou ao modo como o Qubes processa imagens e PDFs.⁵ E as qubes descartáveis encarnam a desconfiança da forma mais direta: em vez de confiar que um leitor de PDF não será explorado, você assume que ele será, executa-o em uma máquina virtual que você está prestes a destruir e deixa a explosão acontecer em uma sala vazia.²

O fio condutor é a humildade em relação ao seu próprio código. Um sistema que confia em um componente grande e complexo está fazendo uma aposta grande e complexa. A arquitetura de Rutkowska trabalha para tornar a aposta pequena – para reduzir a base de computação confiável a um fino hipervisor e a um dom0 isolado da rede, e para tratar quase tudo acima disso como descartável, substituível e presumidamente hostil.²⁵

Do desktop à descentralização

Rutkowska liderou o Qubes por anos, e então se voltou para o problema mais amplo que o sistema operacional só resolve em parte: mesmo um desktop perfeitamente compartimentado ainda confia na infraestrutura ao seu redor – o armazenamento em nuvem, a rede, os serviços que guardam seus dados.¹⁵ Seu trabalho posterior se voltou para a privacidade e a descentralização, estendendo a mesma desconfiança para fora, da máquina individual para os sistemas com os quais ela conversa. A forma e o estado precisos desses projetos são mais bem extraídos de sua própria escrita atual do que parafraseados aqui; o que se transfere com clareza é o princípio, não o produto. O instinto é constante: assuma que a infraestrutura está comprometida e projete de modo que o pressuposto lhe custe o mínimo possível.⁵

O método

Leia atravessando o Qubes, o Blue Pill, os ataques ao SMM e à TXT, e “Security Through Distrusting”, e os mesmos compromissos se repetem. O método de Rutkowska é menos um slogan do que um conjunto de hábitos permanentes.

Assuma o comprometimento; projete para o raio da explosão. O movimento fundador é conceder que a prevenção vai falhar e perguntar até onde uma brecha se espalha.² Em escala, isso é o gêmeo, em segurança, do que Werner Vogels faz pela confiabilidade – tudo falha o tempo todo, então contenha o raio da explosão em vez de fingir que você consegue evitar a falha. A lição se transfere para muito além do Qubes: não projete para o caso em que nada entra; projete de modo que, quando algo entrar, fique preso em uma cela pequena e descartável. É a régua da evidência aplicada à segurança – “ninguém invadiu ainda” não é evidência; “uma brecha aqui não consegue alcançar lá” é.

Desconfie da infraestrutura e prove o limite. Trate cada componente como potencialmente invadido e recuse conceder confiança por padrão.⁵ Isto é o “Reflections on Trusting Trust” de Thompson transformado em arquitetura de desktop: você não consegue confiar no que não examinou, então pare de confiar nas camadas que você não consegue ver e murale-as no lugar disso. A disciplina é perguntar de cada componente: “se isto for comprometido, o que ele domina?” – e redesenhar os limites até que a resposta seja “quase nada”.

Quebre você mesmo antes que outro o faça. A defesa de Rutkowska é construída sobre uma década de ofensiva – Blue Pill, SMM, Empregada Malvada – porque você não consegue isolar um limite que não provou primeiro ser falso.³⁴ Este é exatamente o instinto que Adi Shamir levou à criptografia: atacar para defender, e confiar apenas no que sobrevive a uma tentativa séria de quebrá-lo. O hábito permanente é vestir primeiro o chapéu do atacante, mapear quais dos seus pressupostos de confiança são mentiras e projetar os muros onde as mentiras estavam.

Reduza a base de computação confiável. Quanto menos linhas de código sua segurança depender, menor é a sua aposta.²⁵ Um fino hipervisor e um dom0 isolado da rede são uma aposta inspecionável; um kernel monolítico com cada driver e serviço dentro do limite de confiança é uma aposta cega. É o produto mínimo digno aplicado à confiança: a base confiável mais limpa é a menor que ainda cumpre sua única função. Reduza a confiança ao que precisa ser confiável e presuma o resto hostil.

Seja honesta sobre o trade-off. Rutkowska não exagera as vantagens – ela diz claramente que a segurança pela desconfiança “não é uma panaceia” e custa usabilidade e conveniência.⁵ O hábito é nomear o preço da segurança que você está comprando, em vez de escondê-lo, para que o próximo engenheiro possa pesá-lo. Essa franqueza é a qualidade é a única variável aplicada à segurança: a garantia real, declarada com seus custos, vale mais do que uma promessa confortável que silenciosamente não se sustenta. Um limite que você compreendeu e escolheu supera um que você assumiu e herdou.

Cadeia de influência

Quem a moldou

A comunidade de pesquisa ofensiva de meados dos anos 2000. Rutkowska ascendeu dentro da cultura de ataque a plataformas da Black Hat e do hacking de sistemas de baixo nível, onde o trabalho era encontrar o pressuposto que ninguém questionava e quebrá-lo.³ O reflexo central dessa cultura – desconfie da camada em que todos confiam – tornou-se a espinha dorsal de seu trabalho defensivo. (Influência formativa)

A onda da virtualização por hardware. O Blue Pill só foi possível porque a AMD-V e a Intel VT-x acabavam de tornar a virtualização por hardware predominante.³ A mesma tecnologia que ela usou como arma em 2006 tornou-se a fundação sobre a qual ela construiu o isolamento no Qubes, onde o Xen transforma o hipervisor de ferramenta do atacante em muro do defensor.¹² (Influência direta)

A linhagem de segurança do Xen e dos hipervisores. Seus anos analisando e atacando o Xen lhe ensinaram exatamente quão forte – e quão frágil – é o isolamento dos hipervisores, conhecimento que moldou a decisão do Qubes de manter o dom0 fora da rede e empurrar os drivers para domínios isolados.¹² (Influência formativa)

Quem ela moldou

A computação consciente da privacidade. O Qubes tornou-se o desktop recomendado para jornalistas, ativistas e pesquisadores de segurança que precisam assumir um comprometimento direcionado – uma ferramenta real para pessoas cujo modelo de ameaça é um Estado, não um slogan.²

A mentalidade da compartimentação. A “segurança por isolamento” e “reduza a base de computação confiável” se propagaram muito além do Qubes, alcançando o modo como o sandboxing, o isolamento de contêineres e a virtualização por aplicativo são raciocinados em toda a indústria.²⁵

Os defensores que quebram primeiro. Rutkowska é um exemplo permanente de que os arquitetos defensivos mais fortes costumam ser ex-atacantes – de que mapear os limites de confiança reais quebrando-os é o pré-requisito para desenhá-los corretamente.³⁴

O fio condutor

Rutkowska é a pedra angular do isolamento desta série – a figura que responde a “o sistema será invadido” não com desespero, mas com arquitetura. Adi Shamir ataca para defender na criptografia, confiando apenas no que sobrevive a uma tentativa real de quebrá-lo; Rutkowska executa esse mesmo ciclo uma camada abaixo, quebrando hipervisores e cadeias de inicialização para poder construir um desktop que sobreviva ao comprometimento deles.³⁴ Thompson e Ritchie nos deram o aviso de que você não consegue confiar no que não construiu e examinou você mesmo; o “desconfie da infraestrutura” de Rutkowska é esse aviso transformado em um sistema operacional em funcionamento, onde as camadas não confiáveis são muradas em vez de objeto de esperança.⁵ E onde Werner Vogels diz tudo falha o tempo todo, então contenha o raio da explosão para a confiabilidade, Rutkowska diz o mesmo para a segurança: Radia Perlman projetou redes assumindo que o caso hostil e que falha é o centro do projeto, e Rutkowska projeta máquinas desse jeito. Onde Vogels contém um disco que falha e Perlman contém um enlace que falha, Rutkowska diz: o atacante já está dentro – então isole cada domínio, desconfie de cada camada e faça da brecha uma sala descartável que você pode jogar fora. (Ponte da série)

O que eu levo disso

A lição que guardo de Rutkowska é projetar para a brecha, não contra ela. Meu instinto, como o da maioria dos construtores, é reforçar a coisa – validar a entrada, corrigir a dependência, travar a configuração – e tratar a segurança como um muro que tento deixar alto o bastante. “Todo software contém bugs” é a repreensão: o muro será invadido, porque sempre há mais um bug, e a pergunta que de fato importa é o que o atacante alcança depois de estar do outro lado. Então, quando construo algo agora – um limite de autenticação, um serviço que executa entrada não confiável, um recurso que toca dinheiro – tento perguntar “quando isto for comprometido, qual é o raio da explosão?” antes de perguntar “como eu o mantenho de fora?”. A versão honesta de seguro não é “não consigo ver como isto quebra”. É “quando quebrar, o dano fica preso em uma sala que eu posso apagar”.

A segunda lição é uma paranoia razoável quanto àquilo em que sou obrigado a confiar. É fácil deixar passar um componente como “confiável” e seguir em frente, mas Rutkowska redefiniu essa palavra para mim: chamar algo de confiável é admitir que ele pode destruir tudo se falhar. Isso mudou como eu desenho os limites. Cada biblioteca que eu incorporo, cada serviço de que dependo, cada camada sobre a qual eu rodo é uma aposta de que ela está correta – e o tamanho da aposta é o tamanho da minha base de computação confiável. Então tento manter essa base pequena e inspecionável, empurrar o arriscado e o complexo para ambientes isolados que presumo hostis, e ser honesto, do jeito que ela é, em que o isolamento me custa conveniência. A paranoia não é pessimismo. É a disciplina de saber exatamente em que estou confiando, e de tornar essa lista tão curta quanto eu possivelmente conseguir.

FAQ

O que é o Qubes OS?

O Qubes OS é um sistema operacional de desktop gratuito, de código aberto e orientado à segurança, criado por Joanna Rutkowska, descrito pelo projeto como “um sistema operacional razoavelmente seguro”.² Ele usa o hipervisor Xen para dividir sua computação em máquinas virtuais isoladas chamadas qubes – compartimentos separados para atividades como trabalho, banco, navegação pessoal e a abertura de arquivos não confiáveis. Como as qubes são isoladas, um comprometimento em uma não consegue alcançar as outras, então o dano de qualquer brecha individual fica contido. Ele também oferece qubes descartáveis que se autodestroem após o uso, e dá a cada domínio uma borda de janela colorida infalsificável para que você possa ver a qual compartimento uma janela pertence.¹²

O que é a segurança por isolamento (compartimentação)?

A segurança por isolamento, ou compartimentação, é o princípio no coração do Qubes: em vez de tentar deixar o software livre de bugs, você assume que o comprometimento vai acontecer e contém o dano dividindo o sistema em domínios isolados.² A introdução do Qubes faz a analogia com a vida física – você naturalmente separa atividades em cômodos diferentes – e a aplica a um computador onde, de outro modo, tudo compartilharia um único limite de confiança.² A metade complementar é “desconfie da infraestrutura”: trate cada componente como potencialmente comprometido, remova os pontos únicos de falha e mantenha a base de computação confiável tão pequena quanto possível.⁵

O que era o Blue Pill?

O Blue Pill era um rootkit de prova de conceito que Joanna Rutkowska demonstrou na Black Hat em 3 de agosto de 2006. Ele usava a virtualização por hardware da AMD (AMD-V) para iniciar um fino hipervisor malicioso em uma máquina em execução e migrar o sistema operacional vivo para uma máquina virtual abaixo dele, de modo que o hipervisor pudesse interceptar e falsificar a visão que o sistema operacional tinha do hardware, das interrupções e até da hora do sistema.³ A afirmação de Rutkowska de que tal rootkit poderia ser “100% indetectável” foi contestada, com outros pesquisadores propondo uma detecção baseada em tempo. Era uma demonstração de pesquisa de uma superfície de ataque – o pressuposto de que a camada abaixo do seu sistema operacional é benigna – não um malware encontrado em circulação.³

O que é o ataque da Empregada Malvada?

O ataque da Empregada Malvada é uma técnica de acesso físico que Joanna Rutkowska nomeou em uma postagem de blog de 2009. Se um atacante consegue um breve acesso sem supervisão a um laptop criptografado e sem vigilância – em um quarto de hotel, digamos – ele pode adulterar o código de inicialização não criptografado para que ele capture secretamente a frase secreta de criptografia de disco completo do usuário na próxima vez que ela for digitada.⁴ Sistemas de criptografia de disco completo como o TrueCrypt eram vulneráveis porque o carregador de inicialização não conseguia se autenticar ante o usuário, então a vítima não tinha como distinguir o carregador comprometido do legítimo.⁴ É uma demonstração vívida de que a criptografia sozinha não protege uma máquina que um adversário pode tocar fisicamente.

Fontes