Limpe a RAM no desligamento para evitar que o Cold Boot Attack

Question

Meu sistema é criptografado usando Full Disk Encryption, ou seja, tudo, exceto que / boot é criptografado usando dmcrypt / luks. Estou preocupado com Cold Boot Attacks , onde os pesquisadores demonstrada , esse conteúdo pode ser extraído para cerca de 5 minutos .

Por favor, forneça instruções sobre:

• como acionar o kexec em um novo kernel nas últimas etapas do processo de desligamento / reinicialização (para garantir a desmontagem limpa, para evitar corrupção do sistema de arquivos, para garantir que o kernel antigo seja sobrescrito)
• como criar esse kernel, que limpa todo o ram

i.e. Você pode explicar por favor, como fazer o mesmo no Ubuntu?

Como detectar o desligamento? Como iniciar o RAM Wipe? A RAM deve ser apagada quando o usuário clicar em "shutdown" ou se ele iniciar um "script de pânico".

Obrigado pelos seus esforços!

Trabalho anterior:

• Introdução ao Tails RAM Wipe
• Mais informações sobre a implementação do RAM Wipe no
• Introdução à Liberação de RAM do Liberte Linux
• Mais detalhes de implementação sobre a implementação do Liberte Linux RAM Wipe
• memtest não está excluindo tudo
• Teste se o RAM Wipe está funcionando
• discussão da lista de discussão do Tails
• Outra discussão da lista de discussão do Tails
• Relatório de erros do kernel

Se você quiser ver o recurso se tornar realidade, vote no Ubuntu Brainstorm!

link

    

Answer 1

Se você não estiver usando memória RAM antiga como DDR2, 512 MB ou 1024 MB, não deve se preocupar com o CBA.

Dê uma olhada na pesquisa original aqui (PDF).

Se você for ler com atenção, descobrirá que apenas DDR2 e mais antigos são propensos a esse ataque. DDR3 perde tensão muito rápido para permitir que o computador desmonte e congele o procedimento. Então, basta puxar o plugue antes de atender a porta.

Além disso, este documento confirma que DDR3 não é suscetível a um CBA. Se, de fato, você quiser se proteger, porque tem RAM DDR2, ative na BIOS:

1. Autostart after Power loss
2. Verificação de RAM no momento da inicialização

e faça o mesmo que com o DDR3, mas depois de puxar o plugue, conecte-o novamente. O seu computador iniciará automaticamente e limpará o ram, verificando-o. Se ele não for limpo com eficiência suficiente, o processo de inicialização carregará o sistema na RAM novamente. Será rápido demais para permitir o CBA.

No link que você forneceu nos comentários:

Therefore, in conclusion, the cold boot attack should not be viewed as the primary method for acquiring a suspect computer system’s memory. Instead, other techniques including both software and hardware-based acquisition (i.e. FireWire) should be attempted prior to carrying out a cold boot attack against said system. However, should a situation occur where the aforementioned techniques are either not available (i.e. lack of FireWire connection or system login console or remote memory acquisition is not possible) or are ineffectual, then the cold boot attack may be administered assuming that the investigator understands both how and where problem may arise and go awry.
As this study has shown, the cold boot attack cannot be established as being particularly forensically sound or reliable since in most of the experiments conducted herein memory-resident encryption keys could not be consistently found or extracted although they should have been. The same can also be said for the various strings and keyword searches which should have turned up far more strings and keywords than were found for most of the experiments. Moreover, as has been demonstrated, merely the act of flash-freezing computer memory does not guarantee the successful acquisition of said memory. Other factors and variables already examined have fully examined these issues and their underlying causes. Thus, it is the opinion of the authors of this study that the cold boot attack can be useful in some cases to acquire a suspect system’s memory but that this method should not be considered a panacea and instead should be used as a last resort when all other avenues have been exhausted.
Finally, even a successful acquisition which has suffered little to no degradation will likely not stand up in a court of law as sound evidence, at least until jurisprudence has occurred and the integrity of the acquired memory can be demonstrated to be intact using a sound and understandable methodology. The search continues to establish a more proper and reliable way of acquiring the memory of a suspect’s computer...

Além disso, se você verificar os resultados da experiência, perceberá que eles extraíram com sucesso as chaves AES apenas no sistema 2 e 6 e que foram ataques de inicialização a quente quando você olha as especificações do sistema 2 - 1024 MB RAM 533 MHz - isso é coisa velha. O outro sistema - sistema 6 com 256 RAM / 128 RAM - eu acho que este é auto-explicativo.

É exatamente por isso que a conclusão deles foi:

The search continues to establish a more proper and reliable way of acquiring the memory of a suspect’s computer...

Na verdade, creio que, se você tiver dados muito, muito, muito importantes, você deve não apenas usar a Criptografia de Unidade Completa, mas também mantê-la em um arquivo criptografado separado. Criptografado com algoritmos em cascata e uma senha diferente daquela usada durante a criptografia de disco. Você quer uma maneira segura de desligar o PC? Aqui está:

1. Mantenha dados seguros no arquivo criptografado do algoritmo em cascata True Crypt
2. Use serpente
3. Crie um script para lidar com o encerramento:

Para o Windows:

truecrypt.exe /wipecache
shutdown -s -f -t 1

Para Linux:

truecrypt /wipecache
shutdown -h now

Limpar o cache garante que nenhum dado vulnerável permaneça na RAM após o desligamento. Se alguém executar o Cold Boot Attack, eles terão acesso ao seu Sistema na melhor das hipóteses. Eles não terão dados armazenados em um arquivo criptografado separadamente.

    

Answer 2

Peter A. Peterson, da UCLA, escreveu uma prova de conceito de tecnologia e desenvolveu a teoria para executar com segurança seu sistema com RAM criptografada, e a solução foi expressamente projetada para evitar ataques de inicialização a frio. O nome do seu trabalho é Cryptkeeper. Não sei se ele disponibiliza o software para download ou se é possível licenciá-lo na UCLA. No entanto, aparentemente, é possível, pelo menos em princípio, projetar um sistema de criptografia para RAM que seja seguro, mesmo se todo o conteúdo da RAM for divulgado.

O impacto de desempenho medido desta solução está entre uma sobrecarga de 9% e uma desaceleração por um fator de 9 , dependendo de quão "patológico" é o cenário. A cifra de 9% é citada como aplicável à navegação na web com o Firefox, mas eles não indicaram qual caso de uso retardaria o desempenho por um fator de 9.

A solução de Peterson não "limpa" a RAM como você sugere. Em vez disso, ele usa um "mecanismo seguro de ocultação de chaves" para impedir que a chave de descriptografia seja divulgada apenas em virtude da obtenção do conteúdo da RAM. Não tenho certeza dos detalhes da implementação, mas suponho que isso seja explicado no documento.

O artigo foi publicado em 2010.

Está disponível para compra no site ieeexplore do IEEE. Ele também está disponível para download direto em PDF, gratuitamente, no site de alguém; está lá em cima nos resultados de pesquisa do Google para "cryptkeeper RAM" ... mas não tenho certeza de quanto tempo esse resultado vai ficar lá em cima.

Fiquei tentada a fazer disso um comentário em vez de uma resposta, porque essa solução não "limpa" a RAM como você pediu. No entanto, acredito que, se a pesquisa de Peterson estiver tecnicamente correta, isso terá o mesmo efeito prático - ou possivelmente um efeito "melhor" - do que apagar a RAM. A razão é que um invasor físico habilidoso provavelmente poderia interromper a tentativa do programa do sistema de limpar a memória RAM se eles esperassem que tal operação ocorresse - por exemplo, puxando a bateria para fora da unidade ou pressionando o botão liga / desliga antes que a operação pudesse completo. A solução da Peterson é mais segura porque não se baseia em uma janela de tempo necessária sob a qual o computador pode continuar executando instruções para concluir a limpeza. Em vez disso, a memória é constantemente protegida, mesmo que a própria CPU seja instantaneamente eliminada por algum feito incrível de tecnologia antes que você tenha a chance de reagir ao invasor.

E por "incrível façanha de tecnologia" quero dizer algo como o Stuxnet.

    

Answer 3

Eu imagino que memtest86 seria muito bom em limpar a memória RAM. Eu sempre quis experimentar o abaixo, mas não o fiz. Se eu tentar, vou atualizá-lo.

Leia a página kexec man . E não tente kexec o .iso, mas você precisa descompactar o iso e prender o binário inicializável. No site memtest86 acima, você pode simplesmente baixar o binário.

Você tem que usar um comando kexec para carregar o que você está inicializando primeiro.

Acho que o que você pode fazer é:

kexec -l {path-to-memtest86-bootable-binary} --append=console=ttyS0,115200n8

e quando você estiver pronto para ativar o gatilho:

kexec -e

Estou pensando (mas posso estar errado) que o --append=console=ttyS0,115200n8 faz o memtest86 funcionar na porta serial. Portanto, se você tiver uma, poderá verificar se ela está funcionando, mesmo que ela não apareça na saída de vídeo, o que é uma possibilidade, já que o memtest86 não executa a inicialização de vídeo. Matar todas as instâncias em execução do X provavelmente é uma boa ideia.

O pacote Debian kexec-tools (também disponível no Ubuntu) conecta isto aos scripts de desligamento, então se você editar /etc/default/kexec você pode dizer ao processo de desligamento para invocar kexec como a última coisa ao invés de reinicializar. Isto é, se você estiver interessado em um desligamento limpo.

Em uma emergência, um sync; kexec -e funcionaria.

No entanto, é possível que alguns chipsets, uma vez inicializados, causem travamentos quando certas áreas da memória são endereçadas. Eu não sei como isso funcionaria na prática.

Um bom compromisso se kexec não funcionar é instalar o memtest86 em seu gerenciador de inicialização, colocá-lo como o item de inicialização padrão e ter um atraso de 1 segundo até a escolha automática (ou nenhum atraso e depender de um pressionamento de tecla para abrir o memu). Isso pode levá-lo para o memtest86 de uma condição de "inicialização recente" com bastante rapidez, mas não instantaneamente.

Observe que isso não leva em conta a RAM de vídeo. Uma solução para isso é configurar sua RAM de vídeo como um dispositivo de bloco , e gerar /dev/random para o dispositivo de bloco por algumas iterações.

    

Answer 4

Essa é uma pergunta antiga, mas acho que posso contribuir. Como dito anteriormente, uma limpeza de memória baseada em software não é a melhor solução, simplesmente porque a energia pode ser cortada repentinamente, para que o software de limpeza não seja executado.

Posso imaginar o melhor cenário para ilustrar o problema: você administra negócios ilegais no seu computador em sua casa. Um dia, a energia elétrica de repente desaparece, e então um esquadrão do FBI invade a porta de sua casa, prende você e então um técnico de nerd rapidamente abre a caixa do seu computador e usa dentro dele um gás frio para congelar o estado da memória e comprar hora de fazer um ataque a frio.

Assim, a melhor maneira de resolver este problema é tornar o gabinete do computador mais seguro, dificultando a abertura (algo como um cofre), ou até mesmo destruindo a memória aquecendo a placa usando uma resistência alimentada por bateria, inflamada por um interruptor de tamper no caso. Poucos segundos a altas temperaturas podem destruir os dados, ou mesmo destruir os chips, o que não é um grande problema nesta situação.

    

Answer 5

O problema é se o seu computador está em execução e a tela está bloqueada. Neste ponto, a chave AES é armazenada na RAM e o usuário está longe do computador. Um intruso poderia abrir o gabinete do computador e remover os módulos de RAM, mantendo-os energizados e colocando-os em um dispositivo separado que lê o conteúdo. Não há necessidade de desligar o sistema ou congelar os módulos antes da extração. RAM não é confiável para manter a chave AES, mas o cache do processador é, como a solução chamada TRESOR. Infelizmente, isso requer um kernel Linux antigo e conhecimento avançado de correção e compilação do kernel.

    

Answer 6

Desculpe, mas você está sendo paranóico. Primeiro, como outros usuários indicaram, aparentemente o Cold Boot Attack só funciona em hardware mais antigo.

Se você ainda acha que é uma ameaça, a limpeza não é a solução.

O ataque Cold Boot envolve:

• inicialização a frio da máquina
• inicializando um sistema operacional leve para limpar as chaves de criptografia da memória

Se alguém conseguir executar a inicialização a frio, obviamente seu limpador não terá a oportunidade de ser executado. Por isso, não faz sentido instalar um.

Este é o caso principal do ataque. Vamos supor agora que o invasor não quer inicializar a frio o servidor em execução (por exemplo, porque isso acionaria um alerta de monitoramento), em vez disso, ela espera executar o ataque dentro de 5 'de um desligamento normal. Neste caso:

• Um limpador genérico de memória RAM também não faz bem a você. Como se presume que o invasor esteja fisicamente presente para ligar a máquina e limpar as chaves, ela também pode inicializar a máquina a frio antes que o limpador comece a funcionar. (Alertas de monitoramento neste momento são esperados.)
• Um programa especializado que primeiro limpa a localização exata das chaves de criptografia do FS antes de limpar o restante da RAM (por exemplo, truecrypt /wipecache mencionado pelo mnmnc) pode dificultar o trabalho do invasor. Ainda:
  • O invasor ainda conseguirá limpar alguns dos conteúdos da RAM, não permitindo que o limpador percorra toda a RAM. Mas pelo menos a maior parte dos dados do FS seria segura.
  • A solução não seria 100% infalível - só tornaria mais difícil para o atacante avaliar o tempo de inicialização a frio.

Então, se você está realmente preocupado com este ataque, eu sugiro que você aprenda kung-fu e fique de guarda por 5 'ao lado da máquina toda vez que você a desligar. Ou talvez use uma senha de boot na sua BIOS? Ambas as medidas sugeridas não precisam ser 100% eficazes: os invasores ainda podem vencê-lo e ler a senha do BIOS do seu MB usando meios técnicos. Você só precisa atrasá-los por 5 'para que a janela de tempo de ataque expire.

Por fim, se você está preocupado com o fato de alguém realizar a façanha remotamente, você já está muito empenhado.