Cold boot attack

Na segurança de computadores, um ataque de cold boot (ou, em menor grau, um ataque de reinicialização de plataforma) é um tipo de ataque de canal lateral no qual um invasor com acesso físico a um computador realiza um dump de memória da memória de acesso aleatório (RAM) de um computador executando um reinício forçado (hard reset) da máquina alvo. Normalmente, os ataques de cold boot são usados para recuperar chaves de criptografia de um sistema operacional em execução por motivos maliciosos ou de investigação criminal. O ataque baseia-se na propriedade de remanência de dados de DRAM e SRAM para recuperar conteúdos da memória que permanecem legíveis nos segundos a minutos seguintes ao desligamento da energia.

Um invasor com acesso físico a um computador em execução normalmente executa um ataque de cold boot realizando um boot a frio na máquina e iniciando um sistema operacional leve a partir de um disco removível para despejar o conteúdo da memória física pré-inicialização em um arquivo. O invasor fica então livre para analisar os dados despejados da memória para encontrar dados sensíveis, como as chaves, usando várias formas de ataques de busca de chaves. Como os ataques de cold boot visam a memória de acesso aleatório, esquemas de criptografia de disco total, mesmo com um módulo de plataforma confiável (TPM) instalado, são ineficazes contra esse tipo de ataque. Isso ocorre porque o problema é fundamentalmente de hardware (memória insegura) e não uma questão de software. No entanto, o acesso malicioso pode ser evitado limitando o acesso físico e usando técnicas modernas para evitar o armazenamento de dados sensíveis na memória de acesso aleatório.

Detalhes técnicos

Nitrogênio líquido, spray congelante (mostrado) ou latas de ar comprimido podem ser improvisados para resfriar módulos de memória e, assim, retardar a degradação da memória volátil

Os módulos de memória DIMM perdem dados gradualmente ao longo do tempo conforme perdem energia, mas não perdem todos os dados imediatamente quando a energia é cortada. Com certos módulos de memória, a janela de tempo para um ataque pode ser estendida para horas ou até uma semana ao resfriá-los com spray congelante e nitrogênio líquido. Além disso, à medida que os bits desaparecem na memória com o tempo, eles podem ser reconstruídos, pois desaparecem de maneira previsível. Consequentemente, um invasor pode realizar um dump de memória de seu conteúdo executando um ataque de cold boot. A capacidade de executar o ataque de cold boot com sucesso varia consideravelmente entre diferentes sistemas, tipos de memória, fabricantes de memória e propriedades da placa-mãe, e pode ser mais difícil de realizar do que métodos baseados em software ou um Ataque de DMA. Embora o foco da pesquisa atual seja a criptografia de disco, qualquer dado sensível mantido na memória é vulnerável ao ataque.

Invasores executam ataques de cold boot reiniciando de forma forçada e abrupta uma máquina alvo e, em seguida, iniciando um sistema operacional pré-instalado a partir de um pendrive, CD-ROM ou através da rede. Em casos onde não é prático reiniciar a máquina alvo, um invasor pode, alternativamente, remover fisicamente os módulos de memória do sistema original e colocá-los rapidamente em uma máquina compatível sob o controle do invasor, que é então inicializada para acessar a memória. Uma análise posterior pode então ser realizada contra os dados despejados da RAM.

Um tipo semelhante de ataque também pode ser usado para extrair dados da memória, como um Ataque de DMA que permite que a memória física seja acessada através de uma porta de expansão de alta velocidade, como FireWire. Um ataque de cold boot pode ser preferido em certos casos, como quando há alto risco de danos ao hardware. O uso da porta de expansão de alta velocidade pode causar curto-circuito ou danificar fisicamente o hardware em certos casos.

Usos

Ataques de cold boot são normalmente usados para investigações forenses digitais, fins maliciosos como roubo e recuperação de dados, embora a simples diversão não possa ser descartada.

Computação forense

Em certos casos, um ataque de cold boot é usado na disciplina de computação forense para preservar de forma forense os dados contidos na memória como evidência criminal. Por exemplo, quando não é prático preservar os dados na memória por outros meios, um ataque de cold boot pode ser usado para realizar um despejo dos dados contidos na memória de acesso aleatório. Por exemplo, um ataque de cold boot é usado em situações em que um sistema está protegido e não é possível acessar o computador. Um ataque de cold boot também pode ser necessário quando um disco rígido é criptografado com criptografia de disco total e o disco potencialmente contém evidências de atividade criminosa. Um ataque de cold boot fornece acesso à memória, que pode fornecer informações sobre o estado do sistema no momento, como quais programas estavam em execução.

Intenção maliciosa

Um ataque de cold boot pode ser usado por invasores para obter acesso a informações criptografadas, como informações financeiras ou segredos comerciais, com intenção maliciosa.

Contornando a criptografia de disco total

Um propósito comum dos ataques de cold boot é contornar a criptografia de disco baseada em software. Ataques de cold boot, quando usados em conjunto com ataques de busca de chaves, demonstraram ser um meio eficaz de contornar esquemas de criptografia de disco total de vários fornecedores e sistemas operacionais, mesmo onde um coprocessador seguro Trusted Platform Module (TPM) é usado.

No caso de aplicativos de criptografia de disco que podem ser configurados para permitir que o sistema operacional inicialize sem a inserção de um PIN de pré-inicialização ou a presença de uma chave de hardware (por exemplo, BitLocker em uma configuração simples que usa um TPM sem um PIN de autenticação de dois fatores ou chave USB), o intervalo de tempo para o ataque não é limitante de forma alguma.

BitLocker

O BitLocker em sua configuração padrão usa um módulo de plataforma confiável que não requer nem um PIN, nem uma chave externa para descriptografar o disco. Quando o sistema operacional inicia, o BitLocker recupera a chave do TPM, sem qualquer interação do usuário. Consequentemente, um invasor pode simplesmente ligar a máquina, esperar o sistema operacional começar a inicializar e então executar um ataque de cold boot contra a máquina para recuperar a chave. Devido a isso, a autenticação de dois fatores, como um PIN de pré-inicialização ou um dispositivo USB removível contendo uma chave de inicialização junto com um TPM, deve ser usada para contornar essa vulnerabilidade na implementação padrão do BitLocker. No entanto, essa solução alternativa só evita um ataque de cold boot se a máquina estivesse desligada antes de o invasor obter acesso físico. Se a máquina já tivesse inicializado e estivesse em execução, ela não impede que um invasor recupere dados sensíveis da memória, nem que recupere chaves de criptografia armazenadas em cache na memória.

Mitigação

Como um dump de memória pode ser facilmente realizado executando um ataque de cold boot, o armazenamento de dados sensíveis na RAM, como chaves de criptografia para criptografia de disco total, é inseguro. Várias soluções foram propostas para armazenar chaves de criptografia em áreas que não sejam a memória de acesso aleatório. Embora essas soluções possam reduzir a chance de quebrar a criptografia de disco total, elas não fornecem proteção para outros dados sensíveis armazenados na memória.

Armazenamento de chaves baseado em registros

Uma solução para manter as chaves de criptografia fora da memória é o armazenamento de chaves baseado em registros. As implementações desta solução são TRESOR e Loop-Amnesia. Ambas as implementações modificam o kernel de um sistema operacional para que os registradores da CPU (no caso do TRESOR, os registradores de depuração x86 e, no caso do Loop-Amnesia, os registradores de perfil AMD64 ou EMT64) possam ser usados para armazenar chaves de criptografia, em vez da RAM. As chaves armazenadas neste nível não podem ser lidas facilmente do espaço do usuário[carece de fontes]? e são perdidas quando o computador reinicia por qualquer motivo. Tanto o TRESOR quanto o Loop-Amnesia devem usar a geração de chave de rodada em tempo real devido ao espaço limitado disponível para armazenar tokens criptográficos dessa maneira. Para segurança, ambos desabilitam interrupções para evitar que as informações das chaves vazem para a memória a partir dos registradores da CPU enquanto a criptografia ou descriptografia está sendo realizada, e ambos bloqueiam o acesso aos registradores de depuração ou perfil.

Existem duas áreas potenciais em processadores x86 modernos para armazenar chaves: os registradores SSE, que poderiam ser tornados privilegiados desabilitando todas as instruções SSE (e necessariamente, quaisquer programas que dependam delas), e os registradores de depuração, que eram muito menores, mas não apresentavam tais problemas.

Uma distribuição prova de conceito chamada 'paranoix', baseada no método de registrador SSE, foi desenvolvida. Os desenvolvedores afirmam que "executando o TRESOR em uma CPU de 64 bits que suporte AES-NI, não há penalidade de desempenho em comparação com uma implementação genérica de AES", e roda um pouco mais rápido do que a criptografia padrão, apesar da necessidade de recálculo de chave. A principal vantagem do Loop-Amnesia em relação ao TRESOR é que ele suporta o uso de várias unidades criptografadas; as principais desvantagens são a falta de suporte para x86 de 32 bits e o pior desempenho em CPUs que não suportam AES-NI.

Armazenamento de chaves baseado em cache

O "cache congelado" (às vezes conhecido como "cache como RAM") pode ser usado para armazenar chaves de criptografia com segurança. Funciona desabilitando o cache L1 de uma CPU e usando-o para armazenamento de chaves; no entanto, isso pode degradar significativamente o desempenho geral do sistema a ponto de ser muito lento para a maioria dos propósitos.

Uma solução semelhante baseada em cache foi proposta por Guan et al. (2015) empregando o modo de cache WB (Write-Back) para manter os dados nos caches, reduzindo os tempos de computação de algoritmos de chave pública.

Mimosa no IEEE S&P 2015 apresentou uma solução mais prática para computações criptográficas de chave pública contra ataques de cold boot e ataques de DMA. Ele utiliza a memória transacional de hardware (HTM), que foi originalmente proposta como um mecanismo de acesso especulativo à memória para aumentar o desempenho de aplicativos multithread. A garantia de atomicidade forte fornecida pela HTM é utilizada para derrotar acessos concorrentes ilegais ao espaço de memória que contém dados sensíveis. A chave privada RSA é criptografada na memória por uma chave AES que é protegida pelo TRESOR. Mediante solicitação, uma computação de chave privada RSA é conduzida dentro de uma transação HTM: a chave privada é primeiro descriptografada na memória e, em seguida, a descriptografia ou assinatura RSA é realizada. Como uma chave privada RSA em texto simples só aparece como dados modificados em uma transação HTM, qualquer operação de leitura desses dados interromperá a transação - a transação retornará ao seu estado inicial. Observe que a chave privada RSA é criptografada no estado inicial e é o resultado de operações de gravação (ou descriptografia AES). Atualmente, a HTM é implementada em caches ou buffers de armazenamento, ambos localizados em CPUs, não em chips de RAM externos. Assim, os ataques de cold boot são evitados. O Mimosa derrota ataques que tentam ler dados sensíveis da memória (incluindo ataques de cold boot, ataques de DMA e outros ataques de software) e introduz apenas uma pequena sobrecarga de desempenho.

Desmontagem de discos criptografados

As melhores práticas recomendam desmontar quaisquer discos criptografados que não sejam do sistema quando não estiverem em uso, já que a maioria dos softwares de criptografia de disco é projetada para apagar com segurança as chaves armazenadas em cache na memória após o uso. Isso reduz o risco de um invasor conseguir recuperar chaves de criptografia da memória executando um ataque de cold boot. Para minimizar o acesso a informações criptografadas no disco rígido do sistema operacional, a máquina deve ser completamente desligada quando não estiver em uso para reduzir a probabilidade de um ataque de cold boot bem-sucedido. No entanto, os dados podem permanecer legíveis por dezenas de segundos a vários minutos, dependendo do dispositivo de RAM física na máquina, permitindo potencialmente que alguns dados sejam recuperados da memória por um invasor. Configurar um sistema operacional para desligar ou hibernar quando não estiver em uso, em vez de usar o modo de suspensão, pode ajudar a mitigar o risco de um ataque de cold boot bem-sucedido.

Contra-medidas eficazes

Prevenção do acesso físico

Normalmente, um ataque de cold boot pode ser evitado limitando o acesso físico de um invasor ao computador ou tornando cada vez mais difícil a realização do ataque. Um método envolve a soldagem ou colagem dos módulos de memória na placa-mãe, para que eles não possam ser facilmente removidos de seus soquetes e inseridos em outra máquina sob o controle de um invasor. No entanto, isso não impede que um invasor inicialize a máquina da vítima e realize um dump de memória usando um pendrive removível. Uma mitigação como o UEFI Secure Boot ou abordagens de verificação de boot semelhantes pode ser eficaz para evitar que um invasor inicialize um ambiente de software personalizado para despejar o conteúdo da memória principal soldada.

Criptografia de memória total

Criptografar a memória de acesso aleatório (RAM) mitiga a possibilidade de um invasor conseguir obter chaves de criptografia ou outro material da memória por meio de um ataque de cold boot. Essa abordagem pode exigir alterações no sistema operacional, nos aplicativos ou no hardware. Um exemplo de criptografia de memória baseada em hardware foi implementado no Microsoft Xbox. Implementações em hardware x86-64 mais recente estão disponíveis na AMD e nos Intel Willow Cove e posteriores.

A criptografia de memória total baseada em software é semelhante ao armazenamento de chaves baseado em CPU, já que o material da chave nunca é exposto à memória, mas é mais abrangente, pois todos os conteúdos da memória são criptografados. Em geral, apenas páginas imediatas são descriptografadas e lidas em tempo real pelo sistema operacional. As implementações de soluções de criptografia de memória baseadas em software incluem: um produto comercial da PrivateCore. e o RamCrypt, um patch de kernel para o kernel Linux que criptografa dados na memória e armazena a chave de criptografia nos registradores da CPU de maneira semelhante ao TRESOR.

Desde a versão 1.24, o VeraCrypt suporta criptografia de RAM para chaves e senhas.

Mais recentemente, vários artigos foram publicados destacando a disponibilidade de processadores comerciais x86 e ARM com segurança aprimorada. Nesse trabalho, um processador ARM Cortex A8 é usado como substrato sobre o qual uma solução de criptografia de memória total é construída. Segmentos de processo (por exemplo, pilha, código ou heap) podem ser criptografados individualmente ou em composição. Este trabalho marca a primeira implementação de criptografia de memória total em um processador comercial de propósito geral. O sistema fornece proteções de confidencialidade e integridade de código e dados que são criptografados em todos os lugares fora dos limites da CPU.

Apagamento seguro da memória

Como os ataques de cold boot visam a memória de acesso aleatório não criptografada, uma solução é apagar os dados sensíveis da memória quando eles não estiverem mais em uso. A "Especificação de Mitigação de Ataque de Reinicialização de Plataforma TCG", uma resposta da indústria a este ataque específico, força o BIOS a sobrescrever a memória durante o POST se o sistema operacional não foi desligado de forma limpa. No entanto, esta medida ainda pode ser contornada removendo o módulo de memória do sistema e lendo-o em outro sistema sob o controle do invasor que não suporte estas medidas.

Um recurso eficaz de apagamento seguro seria que, se a energia for interrompida, a RAM seja limpa em menos de 300 ms antes que a energia seja perdida, em conjunto com um BIOS seguro e um controlador de disco rígido/SSD que criptografe dados nas portas M.2 e SATA. Se a RAM em si não contivesse presença serial ou outros dados e os tempos fossem armazenados no BIOS com alguma forma de segurança exigindo uma chave de hardware para alterá-los, seria quase impossível recuperar qualquer dado e também seria imune a ataques TEMPEST, "man-in-the-RAM" e outros métodos de infiltração possíveis. Alguns sistemas operacionais, como o Tails, fornecem um recurso que grava dados aleatórios de forma segura na memória do sistema quando o sistema operacional é desligado para mitigar um ataque de cold boot. No entanto, o apagamento da memória de vídeo ainda não é possível e, até 2022, ainda era um chamado aberto no fórum do Tails. Ataques potenciais que poderiam explorar essa falha são:A geração de um par de chaves GnuPG e a visualização da chave privada em um editor de texto poderia levar à recuperação da chave.

  • Uma semente (seed) de criptomoeda poderia ser vista, contornando a carteira (mesmo que criptografada) e permitindo o acesso aos fundos.
  • Digitar uma senha com visibilidade ativada pode mostrar partes dela ou até mesmo a chave inteira. Se um arquivo de chave (keyfile) for usado, ele pode ser exibido para reduzir o tempo necessário para um ataque de senha.
  • Rastros de volumes criptografados montados ou abertos com negação plausível podem ser exibidos, levando à descoberta deles.
  • Se conectado a um serviço .onion, a URL pode ser exibida e levar à sua descoberta, o que de outra forma seria extremamente difícil.

O uso de um programa específico pode mostrar os padrões do usuário. Por exemplo, se um programa de esteganografia for usado e aberto, pode-se presumir que o usuário está escondendo dados. Da mesma forma, se um mensageiro instantâneo estiver sendo usado, uma lista de contatos ou mensagens pode ser exibida.

Armazenamento de chave externa

Um ataque de cold boot pode ser evitado garantindo que nenhuma chave seja armazenada pelo hardware sob ataque.

O usuário insere a chave de criptografia de disco manualmente.

Uso de uma unidade de disco rígido totalmente criptografada fechada, onde as chaves de criptografia são mantidas em hardware separado da unidade de disco rígido.

Contra-medidas ineficazes

O Embaralhamento de memória pode ser usado para minimizar efeitos parasitários indesejáveis de semicondutores como um recurso dos processadores Intel Core modernos. No entanto, como o embaralhamento é usado apenas para descorrelacionar quaisquer padrões dentro do conteúdo da memória, a memória pode ser desembaralhada por meio de um ataque de desembaralhamento. Portanto, o embaralhamento de memória não é uma mitigação viável contra ataques de cold boot.

O Modo de suspensão não oferece proteção adicional contra um ataque de cold boot porque os dados normalmente ainda residem na memória enquanto estão nesse estado. Como tal, os produtos de criptografia de disco total ainda são vulneráveis ao ataque porque as chaves residem na memória e não precisam ser inseridas novamente uma vez que a máquina retorne de um estado de baixa energia.

Embora limitar as opções de dispositivo de boot no BIOS possa tornar um pouco mais difícil inicializar outro sistema operacional, o firmware em chipsets modernos tende a permitir que o usuário ignore o dispositivo de boot durante o POST pressionando uma tecla de atalho especificada. Limitar as opções de dispositivo de boot também não impedirá que o módulo de memória seja removido do sistema e lido em um sistema alternativo. Além disso, a maioria dos chipsets fornece um mecanismo de recuperação que permite que as configurações do BIOS sejam redefinidas para o padrão, mesmo que estejam protegidas com uma senha. As configurações do BIOS também podem ser modificadas enquanto o sistema está em execução para contornar quaisquer proteções impostas por ele, como a limpeza de memória ou o bloqueio do dispositivo de boot.

Smartphones

O ataque de cold boot pode ser adaptado e realizado de maneira semelhante em smartphones Android. Um cold boot pode ser realizado desconectando a bateria do telefone para forçar um reinício total ou mantendo pressionado o botão liga/desliga. O smartphone é então carregado (flashed) com uma imagem de sistema operacional que pode realizar um dump de memória. Normalmente, o smartphone é conectado à máquina de um invasor usando uma porta USB.

Normalmente, os smartphones Android apagam com segurança as chaves de criptografia da memória de acesso aleatório quando o telefone é bloqueado. Isso reduz o risco de um invasor conseguir recuperar as chaves da memória, mesmo que tenha sucesso na execução de um ataque de cold boot contra o telefone.

Ver também

Referências

  1. ↑ MacIver, Douglas (21 de setembro de 2006). Penetration Testing Windows Vista BitLocker Drive Encryption (PDF). HITBSecConf2006, Malaysia. Microsoft. Consultado em 23 de setembro de 2008. Cópia arquivada (PDF) em 6 de setembro de 2023
  2. 1 2 3 4 5 6 7 8 9 10 11 12 13 Halderman, J. Alex; Schoen, Seth D.; Heninger, Nadia; Clarkson, William; Paul, William; Calandrino, Joseph A.; Feldman, Ariel J.; Appelbaum, Jacob; Felten, Edward W. (1 de maio de 2009). «Lest we remember: cold-boot attacks on encryption keys» (PDF). Communications of the ACM. 52 (5): 91–98. ISSN 0001-0782. doi:10.1145/1506409.1506429. Cópia arquivada (PDF) em 19 de junho de 2026
  3. 1 2 3 4 5 6 7 8 Carbone, Richard; Bean, C; Salois, M (janeiro 2011). An in-depth analysis of the cold boot attack (PDF). Defence Research and Development Canada. Cópia arquivada (PDF) em 8 de janeiro de 2026
  4. ↑ Skorobogatov, Sergei (junho 2002). Low temperature data remanence in static RAM (PDF). University of Cambridge
  5. 1 2 3 MacIver, Douglas (25 de fevereiro de 2008). «System Integrity Team Blog: Protecting BitLocker from Cold Attacks (and other threats)». Microsoft. Consultado em 24 de junho de 2020
  6. ↑ «Memory Research Project Source Code». Center for Information Technology Policy. 16 de junho de 2008. Consultado em 6 de novembro de 2018. Arquivado do original em 5 de junho de 2013
  7. ↑ «Passware Software Cracks BitLocker Encryption Open» (Nota de imprensa). PR Newswire. 1 de dezembro de 2009
  8. ↑ Hargreaves, C.; Chivers, H. (março 2008). «Recovery of Encryption Keys from Memory Using a Linear Scan». 2008 Third International Conference on Availability, Reliability and Security. 2008 Third International Conference on Availability, Reliability and Security. pp. 1369–1376. ISBN 978-0-7695-3102-1. doi:10.1109/ARES.2008.109
  9. ↑ Carbone, R.; Bean, C; Salois, M. (janeiro 2011). [[linksuspeitoremovido] «An In-depth Analysis of the Cold Boot Attack: Can it be Used for Sound Forensic Memory Acquisition?»] Verifique valor |url= (ajuda) (pdf). Defense Technical Information Center. suspeito removido%5d Cópia arquivada em 8 de abril de 2013 Verifique valor |arquivourl= (ajuda)
  10. 1 2 Gruhn, Michael (24 de novembro de 2016). «Forensically Sound Data Acquisition in the age of Anti-Forensic Innocence». Erlangen, Germany: Friedrich-Alexander-Universität Erlangen-Nürnberg. Cópia arquivada em 10 de setembro de 2024
  11. ↑ «BitLocker Drive Encryption Technical Overview». Microsoft. 2008. Consultado em 19 de novembro de 2008. Cópia arquivada em 9 de janeiro de 2018
  12. 1 2 3 TRESOR USENIX paper, 2011 Arquivado em 2012-01-13 no Wayback Machine
  13. ↑ Simmons, Patrick (5 de dezembro de 2011). Security through amnesia: a software-based solution to the cold boot attack on disk encryption (PDF). Proceedings of the 27th Annual Computer Security Applications Conference. ACM. pp. 73–82. ISBN 978-1-4503-0672-0. doi:10.1145/2076732.2076743. Consultado em 6 de novembro de 2018. Arquivado do original (PDF) em 6 de novembro de 2018
  14. ↑ Müller, Tilo (31 de maio de 2010). «Cold-Boot Resistant Implementation of AES in the Linux Kernel» (PDF). Aachen, Germany: RWTH Aachen University
  15. ↑ Friedrich-Alexander-Universität Erlangen-Nürnberg. «Tresor / TreVisor / Armored: TRESOR Runs Encryption Securely Outside RAM / The TRESOR Hypervisor / for Android-driven Devices». Consultado em 6 de novembro de 2018
  16. ↑ Tews, Erik (dezembro 2010). FrozenCache – Mitigating cold-boot attacks for Full-Disk-Encryption software. 27th Chaos Communication. Cópia arquivada em 4 de maio de 2026
  17. ↑ Frozen Cache Blog
  18. ↑ Guan, Le; Lin, Jingqiang; Luo, Bo; Jing, Jiwu (fevereiro 2014). Copker: Computing with Private Keys without RAM (PDF). 21st ISOC Network and Distributed System Security Symposium (NDSS). Consultado em 1 de março de 2016. Arquivado do original (PDF) em 3 de agosto de 2016
  19. ↑ Guan, L.; Lin, J.; Luo, B.; Jing, J.; Wang, J. (maio 2015). «Protecting Private Keys against Memory Disclosure Attacks Using Hardware Transactional Memory» (PDF). 2015 IEEE Symposium on Security and Privacy. 2015 IEEE Symposium on Security and Privacy. pp. 3–19. ISBN 978-1-4673-6949-7. doi:10.1109/SP.2015.8. Cópia arquivada (PDF) em 11 de novembro de 2025
  20. ↑ Dean, Sarah (11 de novembro de 2009). «Cold Boot Attacks on Encryption Keys (aka "DRAM attacks")». Consultado em 11 de novembro de 2008. Cópia arquivada em 15 de setembro de 2012
  21. ↑ «Encryption Still Good; Sleeping Mode Not So Much, PGP Says». Wired. 21 de fevereiro de 2008. Consultado em 22 de fevereiro de 2008. Cópia arquivada em 4 de abril de 2009
  22. ↑ Weis S, PrivateCore (25 de junho de 2014). Protecting Data In-Use from Firmware and Physical Attacks. (PDF). Black Hat USA 2014 (em inglês). Palo Alto, California, U. S. A. p. 2. Cópia arquivada (PDF) em 18 de março de 2026
  23. ↑ B. Huang "Keeping Secrets in Hardware: The Microsoft Xbox Case Study", "CHES 2002 Lecture Notes in Notes in Computer Science Volume 2523", 2003
  24. 1 2 Götzfried, Johannes; Müller, Tilo; Drescher, Gabor; Nürnberger, Stefan; Backes, Michael (2016). «RamCrypt: Kernel-based Address Space Encryption for User-mode Processes» (PDF). Proceedings of the 11th ACM on Asia Conference on Computer and Communications Security. ASIA CCS '16. New York, NY, USA: ACM. pp. 919–924. ISBN 978-1-4503-4233-9. doi:10.1145/2897845.2897924. Consultado em 7 de novembro de 2018. Cópia arquivada (PDF) em 18 de março de 2026
  25. ↑ Y. Hu, G. Hammouri, and B. Sunar "A fast real-time memory authentication protocol", "STC '08 Proceedings of the 3rd ACM workshop on Scalable trusted computing", 2008
  26. ↑ G. Duc e R. Keryell, "CryptoPage: an efficient secure architecture with memory encryption, integrity and information leakage protection", Dec. 2006
  27. ↑ X. Chen, R. P. Dick e A. Choudhary "Operating system controlled processor-memory bus encryption", "Proceedings of the conference on Design, automation and test in Europe", 2008
  28. ↑ «VeraCrypt Release Notes». Cópia arquivada em 17 de maio de 2025
  29. ↑ M. Henson e S. Taylor "Beyond full disk encryption:protection on security-enhanced commodity processors", "Proceedings of the 11th international conference on applied cryptography and network security", 2013
  30. ↑ M. Henson e S. Taylor "Memory encryption: a survey of existing techniques", "ACM Computing Surveys volume 46 issue 4", 2014
  31. ↑ «TCG Platform Reset Attack Mitigation Specification». Trusted Computing Group. 28 de maio de 2008. Consultado em 10 de junho de 2009. Cópia arquivada em 7 de dezembro de 2022
  32. ↑ Teague, Ryne (2017). «Evidence Verification Complications with Solid-State Drives». Association of Digital Forensics, Security and Law. 12: 75–85
  33. ↑ «Tails - Protection against cold boot attacks». Consultado em 7 novembro 2018
  34. ↑ «Erase video memory on shutdown (#5356) · Issues · tails / Tails · GitLab»
  35. ↑ «The Palinopsia Bug». hsmr.cc. 17 de abril de 2022. Consultado em 17 de abril de 2022. Cópia arquivada em 24 de fevereiro de 2022
  36. ↑ «Tor: Onion Service Protocol». 2019.www.torproject.org. 17 de abril de 2022. Consultado em 17 de abril de 2022. Cópia arquivada em 5 de abril de 2022
  37. ↑ Dingledine, Roger; Mathewson, Nick; Syverson, Paul. «Tor: The Second-Generation Onion Router» (PDF). Consultado em 15 agosto 2025
  38. ↑ «2nd Generation Intel Core Processor Family Desktop, Intel Pentium Processor Family Desktop, and Intel Celeron Processor Family Desktop» (PDF). Junho 2013. p. 23. Consultado em 3 de novembro de 2015. Cópia arquivada (PDF) em 3 de março de 2026
  39. ↑ «2nd Generation Intel Core Processor Family Mobile and Intel Celeron Processor Family Mobile» (PDF). Setembro 2012. p. 24. Consultado em 3 de novembro de 2015
  40. ↑ Michael Gruhn, Tilo Muller. «On the Practicability of Cold Boot Attacks» (PDF). Consultado em 28 de julho de 2018
  41. ↑ Johannes Bauer; Michael Gruhn; Felix C. Freiling (2016). «Lest we forget: Cold-boot attacks on scrambled DDR3 memory». Digital Investigation. 16: S65–S74. doi:10.1016/j.diin.2016.01.009Acessível livremente
  42. ↑ Salessawi Ferede; Yitbarek Misiker; Tadesse Aga. «Cold Boot Attacks are Still Hot: Security Analysis of Memory Scramblers in Modern Processors» (PDF). Consultado em 28 de julho de 2018
  43. ↑ kpacquer (14 de maio de 2018). «Boot to UEFI Mode or Legacy BIOS mode». Microsoft. Consultado em 6 de novembro de 2018. Cópia arquivada em 10 de outubro de 2021
  44. ↑ S, Ray (8 de dezembro de 2015), Booting to the Boot Menu and BIOS, University of Wisconsin-Madison, consultado em 6 de novembro de 2018
  45. ↑ Dell Inc. (9 de outubro de 2018). «How to Perform a BIOS or CMOS Reset and/or Clear the NVRAM on your Dell System | Dell Australia». Dell Support. Cópia arquivada em 24 de janeiro de 2019
  46. ↑ Michael, Gruhn (2016). Forensically Sound Data Acquisition in the Age of Anti-Forensic Innocence (Tese) (em inglês). Friedrich-Alexander-Universität Erlangen-Nürnberg (FAU). 67 páginas
  47. ↑ Schramp, R. (março 2017). «Live transportation and RAM acquisition proficiency test». Digital Investigation. 20: 44–53. ISSN 1742-2876. doi:10.1016/j.diin.2017.02.006
  48. 1 2 3 Bali, Ranbir Singh (julho 2018). Cold Boot Attack on Cell Phones. Concordia University of Edmonton: [s.n.]

Ligações externas

Lest We Remember: Cold Boot Attacks on Encryption Keys no YouTube

Prova de Conceito da McGrew Security

Especialistas congelam telefone para quebrar criptografia de dispositivo Android

Skorobogatov, Sergei (junho 2002). «Low temperature data remanence in static RAM». University of Cambridge. doi:10.48456/tr-536Acessível livremente. Consultado em 27 de fevereiro de 2008. Cópia arquivada em 23 de março de 2026