DEFCON 21. Senhas por si só não são suficientes, ou por que a criptografia de disco “quebra” e como isso pode ser corrigido. Parte 1Existem coisas engraçadas, como contadores de aumento monotônico, com os quais você pode controlar a atividade do TMP e, em seguida, verificar os valores recebidos. Há um pequeno intervalo de memória não volátil que pode ser usada para suas necessidades, não é tão grande quanto um kilobyte, mas também pode ser útil. Existe um contador de relógio que permite determinar há quanto tempo o sistema está funcionando desde a última inicialização. Existem comandos que você pode fornecer ao TMP para que ele faça as coisas em seu nome, incluindo limpar sua própria memória, se necessário.
Em seguida, queremos desenvolver um protocolo que o usuário possa executar no computador para garantir que o computador não tenha sido invadido, antes de se autenticar no computador e começar a usá-lo. O que é útil para esse protocolo, podemos tentar "selar" nos registros de configuração da plataforma?
Tenho algumas sugestões: esses são tokens para senhas de usuário únicas, uma imagem ou animação exclusiva, por exemplo, sua foto, algo original que não é fácil de encontrar em outro lugar. Você também pode desativar a "saída de vídeo" no seu computador quando estiver no modo de solicitação e autenticação.
Você também pode querer "selar" parte da chave do disco e há vários motivos pelos quais deseja fazer isso. Sob certas premissas de segurança, isso garante que o sistema seja inicializado apenas em algumas configurações de software aprovadas que você controla como proprietário do computador. Por fim, isso significa que qualquer pessoa que queira atacar seu sistema deve fazer isso através do TMP de hackers ou na caixa de proteção que você criou para eles. Obviamente, essa não é uma proteção criptográfica particularmente forte, porque você não terá um protocolo que permita ao usuário autenticar com segurança com o mesmo nível de segurança que a AES fornece, por exemplo. Mas se você não conseguir organizar algo como a criptografia RSA em sua própria cabeça, isso nunca será perfeito.
Mencionei que no TPM existe um comando de auto-exclusão que pode ser executado por meio de software. Como o TPM requer uma certa configuração do sistema, antes de revelar "segredos", você pode fazer algo interessante, por exemplo, autodestruição. Você pode desenvolver um software e criar seu próprio protocolo para limitar o número de falhas de inicialização do computador, definir um tempo limite após a senha estar na tela por um determinado período ou limitar o número de tentativas para inserir a senha incorreta.
Você pode definir o limite de tempo para reiniciar o computador após o ciclo de trabalho anterior, se o computador estiver no "estado congelado" por uma ou duas semanas, restringir o acesso ao computador durante o período em que estiver indo para o exterior - você o bloqueia enquanto estiver no exterior. estrada para desbloquear o mais cedo possível quando você chegar ao hotel.
Você também pode fazer algumas coisas engraçadas, por exemplo, deixar pequenos "canários" em um disco que contém dados críticos do ponto de vista da segurança. De fato, essas serão simplesmente "estrias", cujo acionamento levará a uma alteração nos valores do contador monótono dentro do TPM.
Você também pode criar uma senha de autodestruição ou código forçado para executar automaticamente um comando de redefinição. Como um invasor pode atacar de duas maneiras: invadir um módulo de plataforma confiável ou executar um software mal-intencionado, você pode forçá-lo a seguir essas regras e realizar uma autodestruição eficaz.
O Trusted Platform Module foi projetado especificamente para ser muito difícil de copiar; portanto, não é possível cloná-lo. Dessa forma, você pode usar itens como contadores monótonos para detectar qualquer ataque de recuperação ou reprodução de disco. E assim que o comando clear for executado no TPM, para um invasor que deseja acessar seus dados, o jogo terminará.
Existem algumas semelhanças com o sistema que Jacob Appelbaum discutiu na conferência Chaos Communication Congress muitos anos atrás, em 2005. Ele sugeriu o uso de um servidor de rede remota para implementar muitas dessas opções, mas reconheceu que seria difícil usar na prática. Como o TPM é um componente integrado do sistema, você pode obter muitos benefícios apenas com o módulo TPM interno, e não o módulo localizado no servidor remoto. Uma abordagem híbrida é potencialmente possível. Você pode configurar o sistema, digamos, como no departamento de TI, quando bloqueia temporariamente o sistema, e ele pode ficar disponível somente depois que você o conecta à rede, ligue para o administrador de TI e eles o desbloquearão. Hesito em empurrar a pilha de rede no início do processo de inicialização, simplesmente porque aumenta significativamente a superfície de ataque. Mas ainda é possível.
Quero esclarecer que um invasor só pode fazer isso, assumindo que ele não será capaz de quebrar facilmente o TPM. O próximo slide mostra uma imagem do design do chip TPM, feito por Chris Tarnovsky com um microscópio. Chris conversou com a DefCon no ano passado e fez uma apresentação na conferência BlackHat sobre a segurança do TPM alguns anos atrás.
Ele realmente fez um ótimo trabalho para entender o quão difícil é quebrar essa coisa. Ele listou as contramedidas, descobriu o que seria necessário para quebrar essa coisa e depois testou o chip inteiro. Existem detectores de luz, grades ativas na placa do TPM, vários esquemas completamente malucos são implementados para enganar o invasor sobre o que esse módulo realmente faz.
Mas se você gastar tempo e recursos suficientes e for cuidadoso o suficiente, poderá contornar a maioria das medidas de proteção. Você pode remover o chip, colocá-lo com um microscópio eletrônico em uma estação de trabalho, descobrir onde o ônibus com dados não criptografados está localizado e extrair todos os segredos dele. No entanto, esse ataque, mesmo que você o tenha preparado com cuidado e descubra onde está localizado usando um microscópio caro, ainda precisará de tempo e esforço para remover a proteção física do chip e não acidentalmente "fritá-lo" durante a desmontagem. .
Considere um ataque de reinicialização. Mencionei anteriormente que, em quase todos os casos, o TPM é um chip separado na placa-mãe. Este é um link muito baixo na hierarquia do sistema. Não faz parte da CPU, como é feito com o DRM nos consoles de vídeo. Portanto, se um hacker conseguir reiniciar o TPM, isso não terá um efeito irreversível no sistema. Isso é ruim, porque esse ataque pode passar despercebido para você.
Geralmente, é um chip localizado fora do barramento do computador LPC, que por si só é um barramento obsoleto e está localizado fora da ponte sul da placa-mãe. Nos sistemas modernos, as únicas coisas localizadas na superfície da placa-mãe são TPM, BIOS, controladores de teclado, mas acho que, na verdade, controladores flexíveis não o usam mais. E se você encontrar uma maneira de reiniciar o barramento com um pequeno número de contatos, redefinirá o TPM para o estado de inicialização do “novo sistema operacional”. Você provavelmente perderá o acesso ao teclado através do conector PS / 2, mas isso não é um grande problema, mas você pode reproduzir a sequência de inicialização do TPM na qual os dados secretos são "selados" sem realmente executar uma sequência segura e pode ser usada para extrair os dados.
Existem vários ataques que tentam usar esse método. Se o TPM usar um modo antigo chamado SRTM (Static Root of Trust for Measurement), você poderá fazer isso facilmente. Não vi nenhuma pesquisa sobre ataques bem-sucedidos contra novas tecnologias confiáveis para implementar as opções de ativação do módulo Intel. Provavelmente ainda é possível capturar o barramento LPC e o que ele passa para a CPU é uma área que precisa de mais pesquisas. Essa pode ser outra maneira de atacar um módulo de plataforma confiável.
Então, vejamos um diagrama do que precisamos para ter um sistema de inicialização a frio com uma configuração confiável. Existem muitos componentes bastante vulneráveis na arquitetura do PC.
Por exemplo, no BIOS você pode capturar a tabela de vetores de interrupção e modificar os direitos de leitura do disco, ou interceptar a entrada do teclado, mascarar todas as funções dos registros da CPU - existem muitas opções de ataque. Na minha opinião, você não precisa fazer uma verificação de segurança no modo de inicialização real, basta medir o desempenho do processo de inicialização.
Assim que você entra no modo "pré-inicialização", que é realmente apenas o seu sistema operacional, como o disco RAM inicial do Linux, você começa a executar seu protocolo e faz essas coisas. Quero dizer, assim que você começar a usar os recursos do sistema operacional, o que alguém faz no nível do BIOS, operando com a tabela de interrupções, não afetará você de forma alguma. Você realmente não vai se importar.
Você pode verificar o desempenho dos registros. Por exemplo, se você trabalha com o processador Core i5, sabe que ele oferecerá suporte a coisas como o bit de proibição de execução, registros de depuração e outras coisas que as pessoas podem tentar mascarar nos recursos de registro.
Este slide mostra como deve ser o diagrama do sistema quando iniciado em uma configuração funcional.
Havia um projeto chamado BitVisor que implementava muitos aspectos da segurança de criptografia de disco usando registros do processador e proteção IOMMU na memória principal. O problema é que o BitVisor é um programa bastante específico e raramente usado.
O Xen é um tipo de hipervisor de código aberto canônico que participa de muitos estudos de segurança, durante os quais as pessoas estão convencidas de que ele funciona. Na minha opinião, devemos usar o hipervisor Xen como a interface de hardware de nível básico e, em seguida, adicionar o domínio administrativo Linux dom0 a ele para inicializar seu hardware.
Novamente, no Xen, todos os seus domínios virtualizados funcionam no modo sem privilégios; portanto, você não tem acesso direto aos registros de depuração; essa é uma das coisas que já foram feitas. O Xen faz chamadas hipercalóricas que dão acesso a essas coisas, mas você pode desativar esse recurso no software.
Portanto, a abordagem que eu uso é colocar a chave mestra nos registros de depuração. Distinguimos os dois primeiros registradores de depuração para armazenar a chave AES de 128 bits, que é a nossa chave mestra.
Essa coisa nunca deixa os registros da CPU após serem inseridos por um processo que aceita credenciais do usuário. Em seguida, usamos os dois segundos registradores como registros específicos da máquina virtual - eles podem ser usados como registros de depuração comuns ou, como neste caso, podemos usá-los para criptografar a memória principal. Nesse caso em particular, precisamos ter vários dispositivos conectados diretamente ao domínio administrativo. Este é um processador gráfico, que é um dispositivo PCI, teclado, TPM - tudo isso deve estar diretamente acessível.
Você não pode usar a proteção IOMMU para essas coisas, mas pode configurá-la para um controlador de rede, controlador de armazenamento, dispositivos arbitrários no barramento PCI, ou seja, para componentes que não têm acesso ao domínio administrativo ou aos espaços de memória do hipervisor. Você pode acessar coisas como uma rede colocando o controlador de rede em uma máquina virtual Net VM dedicada. Essas coisas serão mapeadas para dispositivos específicos que têm a segurança do IOMMU configurada, para que esse dispositivo possa acessar apenas a área de memória dessa máquina virtual.
Você pode fazer o mesmo com o Storage Controller e, em seguida, executar todos os aplicativos em APP VMs com acesso direto absolutamente zero ao hardware. Assim, mesmo que alguém assuma o controle do seu navegador da Web ou envie um arquivo PDF malicioso, ele não receberá nada que comprometa seriamente a criptografia de disco.
Não posso me responsabilizar por esse projeto arquitetônico, porque, na verdade, é a base de um excelente projeto chamado Qubes OS.
Seus desenvolvedores descrevem esse projeto como uma formação pragmática do Xen, Linux e várias ferramentas personalizadas para implementar muitas das coisas que acabei de falar. O Qubes OS implementa uma política de convidados sem privilégios e cria um ambiente de sistema unificado, de modo que parece que você está trabalhando com o mesmo sistema, mas na verdade existem várias máquinas virtuais "sob o mesmo teto". Eu uso essa idéia para implementar minha base de código.
Então, a ferramenta que estou desenvolvendo é um código experimental que confirma esse conceito, denominado Phalanx. Este é um Xen corrigido que permite implementar a criptografia de disco usando a tecnologia que descrevi.
A chave mestra está localizada nos 2 primeiros registradores de depuração DR1-2, os dois segundos registradores de depuração DR2-3 são absolutamente ilimitados pelo domU. Por motivos de segurança, o XMM registra de 0 a 12, usado como memória operacional, DR2-3, e a chave é criptografada quando a máquina virtual alterna o contexto. Também fiz uma implementação de criptografia muito simples usando o módulo do kernel Linux zRAM, porque é um elemento interno que faz quase tudo, exceto criptografia, portanto, para a criptografia, acabei de adicionar um pequeno pedaço de código em cima dele. Como você sabe, o código mais seguro é o código que você não precisa escrever. Uma boa característica do zRAM é que ele fornece vários bits necessários para implementar com segurança coisas como o modo contador AES.
Temos vários requisitos de hardware. Você precisa de um sistema que suporte as novas instruções AES, que são bastante comuns, mas nem todo sistema as possui. Provavelmente, se você possui um processador Intel i5 ou i7, essas instruções são suportadas.
Mas o restante do "hardware" deve ser verificado para garantir que ele suporte todas as funções necessárias. As extensões de hardware de virtualização HVE se espalharam por volta de 2006. Será um pouco mais difícil encontrar um computador com o IOMMU. Isso não é indicado na especificação da unidade do sistema, e você precisará se aprofundar em suas características, além de descobrir qual é a diferença entre VTX e VTD e assim por diante. Portanto, talvez você precise procurar um sistema que suporte essas coisas. E você, é claro, precisa de um sistema com um módulo de plataforma TPM confiável, porque, caso contrário, você não poderá medir as métricas de carga. Geralmente, você olha para computadores de classe comercial, onde pode verificar a disponibilidade dos componentes necessários. Se você encontrar a tecnologia Intel TXT com Trusted Execution, ela terá quase tudo o que você precisa. A equipe do Qubes em seu Wiki apresenta uma excelente lista de compatibilidade de hardware, que lista detalhes de muitos sistemas que implementam essas coisas.
Portanto, para garantir a segurança, temos várias suposições sobre alguns componentes do sistema. O TPM, é claro, é um componente muito importante para garantir a integridade da inicialização. Você precisa garantir que não haja backdoor que possa redefinir a NVRAM, manipular contadores monótonos ou fazer o sistema pensar que está usando um estado confiável, embora, na realidade, não esteja. Com base nos comentários de Tarnovsky, que realizou a engenharia reversa desses chips, defina um limite de cerca de 12 horas de acesso exclusivo ao computador, o que é necessário se você deseja iniciar um ataque de TPM a ele para buscar todos os segredos.
\
Existem várias suposições sobre o processador, o controlador de memória e o IOMMU, principalmente em relação ao fato de não serem hackeados e implementarem corretamente suas funções. Algumas dessas suposições não precisam ser muito rigorosas, porque a Intel pode contornar algumas dessas coisas facilmente, e não temos como descobrir.
Algumas das premissas de segurança dizem respeito ao Xen. Este é um software que realmente possui um sistema de segurança muito poderoso, mas nada é perfeito, e algumas vezes as vulnerabilidades surgem mesmo em um sistema seguro. Dado que o Xen tem uma posição privilegiada no sistema, é muito importante garantir que ele esteja em um estado seguro.
Portanto, com essas premissas de segurança, temos um tipo de base para o modelo de ameaça. , , , , - . , . , .
, – . , , , , .
, , , . , , , — , , , .
— , . FDE , RAM.
, IOMMU, . TPM NVRAM, , – , , .
, , , 12 . , .
, , . , .
TPM — NVRAM, / LPC. TPM , , , , .
RAM . , RAM RAM, , , . , , Sony PS3.
, . , . , , , , , TPM . , , , , , RIPA – , .
. , , , . .
-, . OpenSSL , API, .
Qubes OS.
: , . .
– .
, , -. , , , . Obrigado pela atenção!
Obrigado por ficar conosco. Você gosta dos nossos artigos? Deseja ver materiais mais interessantes? Ajude-nos fazendo um pedido ou recomendando a seus amigos, um
desconto de 30% para os usuários da Habr em um análogo exclusivo de servidores básicos que inventamos para você: Toda a verdade sobre o VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps da US $ 20 ou como dividir o servidor? (as opções estão disponíveis com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).
VPS (KVM) E5-2650 v4 (6 núcleos) 10 GB DDR4 240 GB SSD de 1 Gbps até a primavera, gratuitamente, ao pagar por meio ano, você pode fazer o pedido
aqui .
Dell R730xd 2 vezes mais barato? Somente nós temos
2 TVs Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 a partir de US $ 249 na Holanda e nos EUA! Leia sobre
Como criar um prédio de infraestrutura. classe usando servidores Dell R730xd E5-2650 v4 custando 9.000 euros por um centavo?