Portanto, o shredutilitário supostamente permite excluir um arquivo "com segurança", sobrescrevendo-o repetidamente com dados aleatórios.
Obviamente, em sistemas de arquivos copy-on-write, é quase impossível apagar completamente os dados que já foram gravados nele.
No entanto, li que sistemas de arquivos registrados em diário como EXT3/4 e XFS também são shredineficazes.
Suponha que eu quisesse um sistema de arquivos onde a principal prioridade fosse a capacidade de excluir arquivos da forma mais segura possível. Quais sistemas de arquivos seriam melhores para esse propósito?
Estou ciente da criptografia de unidade, mas quando você descriptografa uma unidade, entendo que você pode fazer a recuperação de arquivos na unidade como se ela não estivesse criptografada. Quero ter proteção para arquivos excluídos confidenciais, mesmo que um invasor consiga passar pela criptografia da unidade.
shrednão foi feito para HDDs ou SSDs modernos. Seu design é baseado em um documento de tempos passados, quando os discos rígidos não continham seus próprios controladores. Se as ideias de design subjacentesshredainda se aplicam ou não aos discos rígidos modernos, está sujeito a um debate contínuo. Eu irei com "pessoalmente, acho que não".De qualquer forma, sua melhor aposta é a criptografia em um SSD e o uso da capacidade de descarte do sistema de arquivos junto com a recriptografia regular.
A princípio, usar um SSD parece contra-intuitivo: os SSDs são, por natureza, "cópia na gravação" nos bastidores: os blocos de memória apresentados a você são mapeados para blocos ordenados arbitrariamente na memória flash física. Quando você deseja modificar um byte em um bloco, você precisa apagar todo o bloco (ou seja, defini-lo completamente como 0) e então inverter apenas os bits corretos. Esse apagamento é um processo que desgasta as células flash, portanto, em vez de apagar os mesmos blocos físicos repetidamente, toda vez que você modifica um bloco, seu conteúdo modificado é gravado em um bloco diferente, já apagado, e o bloco antigo é enfileirado para apagar. O SSD faz tudo isso internamente, o host não percebe nada.
Agora, há uma maneira de interagir com isso: você pode TRIM/descartar um bloco lógico, e isso simplesmente marcará o bloco físico subjacente como não utilizado e o colocará na fila para ser apagado; o bloco lógico é marcado como apoiado por "nulos" e só será atribuído a um bloco apagado quando for gravado (geralmente).
Agora, LUKS/dm-crypt no Linux é inteligente. Quando o seu sistema de arquivos em um volume criptografado reconhece um bloco lógico como "não é mais usado por um arquivo", ele transmite um "descarte este bloco" para o dispositivo de bloco - o próprio dispositivo criptografado pode então entregar essa informação mais abaixo para o SSD.
Portanto, você tem um mecanismo para isso que torna trivial para a camada de criptografia recriptografar rapidamente apenas as partes usadas do dispositivo de bloco (e não o disco completo, incluindo os dados pertencentes a blocos de arquivos excluídos).
Organizado. Então você exclui arquivos, o que descarta os blocos que eles usam, cujo texto cifrado se torna impossível de ler para qualquer pessoa, mas para tornar as coisas ainda mais seguras, você depois diz ao luks para criptografar novamente todo o disco, o que lhe dá uma nova chave , com o qual os dados antigos no "tecnicamente ainda potencialmente em algum lugar dentro do SSD, mas inacessíveis do computador" não podem ser descriptografados porque a chave não existe mais e, na ausência de uma chave, os dados criptografados adequadamente são igualmente prováveis todos os dados não criptografados possíveis. Portanto, mesmo quando sua senha de criptografia luks for quebrada em algum momento e a chave mestra de criptografia atual (muito longa) for recuperada, isso não ajudaria um invasor a recuperar esses dados.