Data-at-rest encryption (Português)

Artigos relacionados
dm-crypt
TrueCrypt
eCryptfs
EncFS
gocryptfs
fscrypt
Tomb
tcplay
GnuPG
Self-Encrypting Drives
Status de tradução:
Esse artigo é uma tradução de
Data-at-rest encryption
. Data da última tradução: 2020-07-31. Você pode ajudar a sincronizar a tradução, se houver
alterações
na versão em inglês.
Este artigo discute sobre software de
criptografia
de
dados em repouso
(data-at-rest) que des-/criptografa dados escritos/lidos de um
dispositivo de bloco
,
partição de disco
ou diretório. Exemplos de dispositivos de blocos são discos rígidos, unidade flash e DVDs.
Criptografia de dados em repouso deve ser somente vista como um complemento para mecanismos de segurança já existentes do sistema operacional - focado em prevenir acesso físico, enquanto confia em
outras
partes do sistema que proveem coisas como segurança de rede e acesso baseado no usuário.
Para encriptação total de disco (full-disk encryption, FDE), veja
dm-crypt/Criptografando todo um sistema
.
Por que criptografar?
Criptografia de dados em repouso assegura que os arquivos são sempre salvos em sua forma criptografada. Os arquivos somente se tornam disponíveis para o sistema operacional e programas em forma legível enquanto o sistema está em execução e aberto para um usuário confiável (dados
em uso
ou
em trânsito
). Uma pessoa não autorizada olhando para o conteúdo do disco diretamente vai somente achar dados ilegíveis que parecem randômicos.
Por exemplo, isto impede a visualização não autorizada de dados quando o computador ou disco é/está:
em um local com pessoas não confiáveis que podem tentar acessá-lo quando você não está por perto
perdido ou roubado, como ocorre com notebooks ou discos externos
na loja de conserto
descartado depois do fim de sua vida útil
Em adição, criptografia de dados em repouso pode também ser usada para adicionar alguma segurança contra tentativas não autorizadas de adulteração do sistema operacional - por exemplo, a instalação de keyloggers ou cavalos Trojan por atacantes que podem ganhar acesso físico ao sistema operacional enquanto você está fora.
Atenção
Criptografia de dados em repouso não protege seus dados de todas as ameaças.
Você ainda vai ser vulnerável a:
Atacantes que podem entrar no seu sistema (exemplo, pela internet) depois que você já abriu e montou as partes criptografadas do disco.
Atacantes que conseguem acesso físico ao computador enquanto este está ligado (até mesmo se você usar um bloqueador de tela), ou um pouco
depois
que ele está ligado, se eles têm recursos para fazer um
cold boot attack
.
Uma entidade governamental, que não somente tem recursos para facilmente fazer as coisas citadas acima como também pode simplesmente forçar você a desistir de suas chaves/senhas usando várias técnicas de
coerção
. Na maioria dos países não democráticos, como também no EUA e Reino Unido, pode ser legal para agências que aplicam a lei fazer isso se eles suspeitam que você pode estar escondendo algo de interesse deles.
Rubber-hose cryptanalysis
. Veja também
XKCD #538
Uma configuração de encriptação de disco muito forte (exemplo, encriptação total de disco com autentificação e partição de boot criptografada) é necessária se deseja ter uma chance contra atacantes profissionais que podem adulterar seu sistema
antes
de você usá-lo. No entanto, não é possível prevenir todos os tipos de adulteração (exemplo, keyloggers no hardware). O melhor remédio pode ser
encriptação total de disco baseada no hardware
e
Computação confiável
.
Atenção
Criptografia de dados em repouso também não vai lhe proteger contra
limpeza de disco
.
Backups regulares
são recomendados para manter seus dados seguros.
Criptografia de dados do sistema
Apesar de que criptografar somente os dados dos usuários (normalmente dentro do diretório home, ou em uma mídia removível como DVD), ser o mais simples e menos intrusivo método, existem pontos a ponderar.
Em sistemas de operacionais modernos, muitos processos podem fazer cache e guardar informações sobre dados do usuário ou partes desses dados em áreas não criptografadas, como:
partições swap
(soluções potenciais: desabilitar a troca rápida, swapping, ou usar
swap criptografada
)
/tmp
(arquivos temporários criados pelos programas do usuário)
(soluções potenciais: evite tais programas; monte
/tmp
dentro de um
ramdisk
)
/var
(arquivos de log e bancos de dados e semelhantes; por exemplo,
locate
guarda um índice de todos os arquivos em
/var/lib/plocate/plocate.db
)
A solução é criptografar ambos o sistema e dados do usuário, prevenindo acesso físico não autorizado de dados privados. No entanto, isto vem com a desvantagem de abrir partes criptografadas do disco durante a inicialização. Outro benefício é que isto complica a instalação de malware como
keyloggers
ou rootkits para alguém com acesso físico.
Métodos disponíveis
This article or section needs expansion.
Reason:
Ext4
,
ZFS
e outros sistemas de arquivos possíveis oferecem encriptação (nativa). (Discuss in
talk:disk encryption
)
Todos os métodos de criptografia de dados em repouso operam de tal maneira que apesar do disco ter os dados criptografados, o sistema operacional e programas "veem" isto como os dados normais correspondentes enquanto o container criptografado (exemplo, a parte lógica do disco que possui os dados criptografados) estiver "aberto" e montado.
Para isto acontecer, alguma "informação secreta" (normalmente em forma de uma keyfile e/ou senha) precisa ser dada pelo usuário, pela qual a chave de encriptação pode ser derivada (e guardada no chaveiro do kernel durante a sessão).
Se você não é familiar com este tipo de operação, leia a seção
#Como a criptografia funciona
abaixo.
Os métodos de criptografia  de dados em repouso podem ser separados em dois tipos, por sua camada de operação:
Encriptação empilhada no sistema de arquivos
Soluções de encriptação empilhada no sistema de arquivos são implementadas como uma camada que se empilha em cima de um sistema de arquivos existente, causando a todos os arquivos de dado diretório sejam criptografados antes o sistema de arquivos os grave no disco. Desta maneira, os arquivos são guardados em sua forma criptografada pelo sistema de arquivos (significando que seu conteúdo, e normalmente nomes de arquivos e diretórios, são trocados por dados aparentemente randômicos de aproximadamente o mesmo tamanho), mas se não fosse por isso, eles ainda existiriam no sistema de arquivos como eles deveriam sem encriptação, como arquivos / symlinks / hardlinks / etc.
Da maneira que é implementado, o diretório que guarda os arquivos criptografados no sistema de arquivos ("diretório inferior") é aberto e montado (usando um especial pseudo sistema de arquivos empilhado) nele mesmo ou opcionalmente em outro diretório ("diretório superior"), onde os mesmos arquivos então aparecem em forma legível - até ser desmontado ou o sistema seja desligado.
Soluções disponíveis nesta categoria são
eCryptfs
e
EncFS
.
Armazenamento na nuvem optimizado
Se você está fazendo encriptação empilhada no sistema de arquivos para conseguir sincronização com conhecimento-zero em locais controlados por terceiros como serviços de armazenamento na nuvem, você pode considerar alternativas ao eCryptfs e EncFS, desde que estes não são otimizados para a transmissão de arquivos pela internet. Algumas soluções que tem essa proposta são:
gocryptfs
cryptomator
AUR
(multiplataforma)
cryfs
Note que alguns serviços de armazenamento em nuvem oferecem criptografia de conhecimento-zero através de suas
aplicações cliente
.
Encriptação de dispositivo de bloco
Métodos de encriptação de dispositivo de bloco operam
abaixo
da camada do sistema de arquivos e garantem que tudo escrito para certo dispositivo de bloco (exemplo, todo o disco, uma partição ou um arquivo agindo como
dispositivo de loop
é criptografado. Isto significa que enquanto o dispositivo de bloco não está sendo usado, todo seu conteúdo parece com um aglomerado de dados randômicos, sem forma de determinar que tipo de sistema de arquivos e dados ele contém. O acesso dos dados é feito quando o container criptografado (nesse caso um dispositivo de bloco) está montado em uma localização arbitrária de uma maneira especial.
As seguintes soluções de "encriptação de dispositivo de bloco" estão disponíveis no Arch Linux:
loop-AES
loop-AES é um descendente do cryptoloop e é uma solução segura e rápida para encriptação de sistema. No entanto, loop-AES é considerado menos amigável que outras opções já que necessita de um suporte não padrão do kernel.
dm-crypt
dm-crypt
é o mapeador de dispositivo da funcionalidade de encriptação padrão do kernel Linux. Pode ser usado diretamente por estes que gostam de ter total controle sobre todos os aspectos da partição e chave. O gerenciamento do dm-crypt é feito com o utilitário do userspace
cryptsetup
. Pode ser usado para os seguintes tipos de encriptação de dispositivo de bloco:
LUKS
(padrão),
plain
, e tem funcionalidades limitadas para dispositivos
loopAES
e
Truecrypt
.
LUKS, usada por padrão, é uma camada adicional de conveniência que guarda todas as informações necessárias para a configuração do dm-crypt no disco e abstrai o gerenciamento de chave e partição na tentativa de facilitar o uso e segurança da criptografia.
modo plain do dm-crypt, sendo uma funcionalidade original do kernel, não emprega uma camada de conveniência. É mais difícil aplicar a mesma força criptográfica a ele. Quando feito, chaves (senhas ou keyfiles) mais longas são o resultado. No entanto tem outras vantagens, como descrito em
#Encriptação de dispositivo de bloco vs encriptação empilhada no sistema de arquivos
.
TrueCrypt/VeraCrypt
Um formato portável, suporta a encriptação de todo um disco/partição ou containers de arquivos, com compatibilidade em todos os sistemas operacionais mais populares.
TrueCrypt
foi descontinuado por seus desenvolvedores em Maio de 2014. O fork VeraCrypt foi auditado em 2016.
Para implicações práticas da camada de operação escolhida, veja
#Encriptação de dispositivo de bloco vs encriptação empilhada no sistema de arquivos
abaixo, também o artigo do
eCryptfs
. Veja
:Categoria:Encriptação
para conteúdos disponíveis do métodos abaixo, como também outras ferramentas não incluídas na tabela.
Encriptação de dispositivo de bloco vs encriptação empilhada no sistema de arquivos
Aspecto
Encriptação de dispositivo de bloco
Encriptação empilhada no sistema de arquivos
Criptografa
Todo dispositivo de bloco
Arquivos
Container para os dados criptografados pode ser...
Uma partição ou disco / um arquivo agindo como dispositivo de loop
Um diretório em um sistema de arquivos existente
Relação com sistema de arquivos
Opera abaixo da camada do sistema de arquivos: não importa se o conteúdo do dispositivo de bloco é um sistema de arquivos, uma tabela de partição, uma configuração do LVM, ou qualquer outra coisa
Adiciona uma camada adicional para um sistema de arquivos existente, para automaticamente des-/criptografar arquivos quando eles são escritos/lidos
Metadados do arquivo (número de arquivos, estrutura do diretório, tamanhos do arquivo, permissões, mtimes, etc.) é criptografada
Sim
Não
(nomes de arquivos e diretórios podem ser criptografados)
Pode ser usado para customizar a encriptação de todo o disco (incluindo tabelas de partições)
Sim
Não
Pode ser usado para criptografar espaço de troca (swap)
Sim
Não
Pode ser usado sem pré-alocar uma quantidade fixada de espaço para o container de dados criptografados
Não
Sim
Pode ser usado para proteger sistemas de arquivos existentes sem acesso ao dispositivo de bloco, exemplo BFS ou compartilhamento do Samba, armazenamento da nuvem, etc.
Não
Sim
Permite backups de dados criptografados baseado em arquivos
Não
Sim
Tabela de comparação
This article or section needs expansion.
Reason:
Completar partes pendentes. Adicionar fontes para verificação. o que é
salt
,
difusão de espaço de chave
(
key-slot diffusion
) ou
limpeza de chave
(
key scrubbing
)? (Discuss in
talk:disk encryption
)
A coluna "dm-crypt +/- LUKS" denota funcionalidades do dm-crypt para os modos de encriptação LUKS ("+") e plain ("-"). Se uma funcionalidade específica precisa do LUKS, é indicado por "(com LUKS)". De mesmo modo "(sem LUKS)" indica que o uso do LUKS é contraprodutivo para a funcionalidade e o modo plain deve ser usado.
Sumário
Loop-AES
dm-crypt
+/- LUKS
TrueCrypt
VeraCrypt
ZFS
eCryptfs
EncFS
gocryptfs
fscrypt
Tipo de encriptação
dispositivo de bloco
dispositivo de bloco
dispositivo de bloco
dispositivo de bloco
nativa do sistema de arquivos ou dispositivo de bloco
empilhado no sistema de arquivos
empilhado no sistema de arquivos
empilhado no sistema de arquivos
nativo do sistema de arquivos
Nota
mais antigo; possivelmente o mais rápido; funciona em sistemas antigos
padrão para encriptação de dispositivo de bloco; muito flexível
muito portável, bem feito mas abandonado
fork do TrueCrypt mantido pela comunidade
suporte relativamente recente (2019); criptografia de dispositivos de bloco provida pelo ZVOL
um pouco mais rápido que EncFS; arquivos criptografados individuais portáveis entre sistemas
mais fácil de usar; suporta administração sem necessidade de superusuário
aspirante sucessor do EncFS
padrão para Chrome OS e Android
disponibilidade no Arch Linux
precisa de um kernel customizado, manualmente compilado
módulos do kernel:
já vem com o kernel padrão;
ferramentas:
device-mapper
,
cryptsetup
truecrypt
AUR
[
link quebrado
: package not found]
veracrypt
ZFS #Instalação
módulos do kernel:
já vem com o kernel padrão;
ferramentas:
ecryptfs-utils
encfs
gocryptfs
módulos do kernel:
já vem com o kernel padrão;
ferramentas:
fscrypt
Licença
GPL
GPL
TrueCrypt License 3.1
Apache License 2.0, partes sujeitas a TrueCrypt License v3.0
CDDL
GPL
GPL
MIT
GPL (kernel), Apache 2.0 (ferramenta no userspace)
Encriptação implementada em...
kernelspace
kernelspace
kernelspace
kernelspace
kernelspace
kernelspace
userspace (
FUSE
)
userspace (
FUSE
)
kernelspace
Metadados criptográficos são guardados no...
?
com LUKS: cabeçalho do LUKS
começo/fim do dispositivo (descriptografado) (
especificação do formato
)
começo/fim do dispositivo (descriptografado) (
especificação do formato
)
DSL (dataset & snapshot layer;
talk
/
slides
)
cabeçalho de cada arquivo criptografado
arquivo de controle no topo de cada container EncFs
?
diretório
.fscrypt
na raiz de cada sistema de arquivos
Chave de encriptação criptografada é guardada no...
?
com LUKS: cabeçalho do LUKS
começo/fim do dispositivo (descriptografado) (
format spec
)
começo/fim do dispositivo (descriptografado) (
especificação do formato
)
DSL (dataset & snapshot layer;
talk
/
slides
)
arquivo chave pode ser guardado em qualquer lugar
arquivo chave pode ser guardado em qualquer lugar
[1]
[2]
?
diretório
.fscrypt
na raiz de cada sistema de arquivos
Recursos de usabilidade
Loop-AES
dm-crypt +/- LUKS
TrueCrypt
VeraCrypt
ZFS
eCryptfs
EncFs
gocryptfs
fscrypt
Usuários normais podem criar/destruir containers de dados criptografados
Não
Não
Não
Não
Sim
limitado
Sim
Sim
Sim
Provê uma interface de usuário gráfica (GUI)
Não
Não
Sim
Sim
Não
Não
Sim
opcional
Não
Não
Suporte a montagem automática no login
?
Sim
Sim
com
systemd e /etc/crypttab
Sim
com
systemd e /etc/crypttab
?
Sim
Sim
Sim
Sim
Suporte a desmontagem automática em caso de inatividade
?
?
?
?
Não
?
Sim
Sim
[3]
Não
Funcionalidades relacionadas a segurança
Loop-AES
dm-crypt +/- LUKS
TrueCrypt
VeraCrypt
ZFS
eCryptfs
EncFs
gocryptfs
fscrypt
Cifras suportadas
AES
AES, Anubis, CAST5/6, Twofish, Serpent, Camellia, Blowfish,… (toda cifra que a API do kernel oferece)
AES, Twofish, Serpent
AES, Twofish, Serpernt, Camellia, Kuznyechik
AES
AES, Blowfish, Twofish...
AES, Blowfish, Twofish, e quaisquer outras cifras disponíveis no sistema
AES
AES, ChaCha12
Integridade
nenhuma
opcional no LUKS2
nenhuma
nenhuma
CCM, GCM
nenhuma
nenhuma (modo normal)
HMAC (modo paranoia)
GCM
nenhuma
Suporte a salting
?
Sim
(com LUKS)
Sim
Sim
Sim
Sim
?
Sim
Sim
Suporte a múltiplas cifras encadeadas
?
não em um dispositivo, mas dispositivos de bloco podem ser
Sim
AES-Twofish, AES-Twofish-Serpent, Serpent-AES, Serpent-Twofish-AES, Twofish-Serpent
Sim
AES-Twofish, AES-Twofish-Serpent, Serpent-AES, Serpent-Twofish-AES, Twofish-Serpent
Não
?
Não
Não
Não
Suporte a difusão de espaço de chave
?
Sim
(com LUKS)
?
?
?
?
?
?
Não
Proteção contra leitura de teclas
Sim
Sim
(sem LUKS)
?
?
?
?
?
?
Não
Suporte a múltiplas chaves (independentemente revogáveis) para os mesmos dados criptografados
?
Sim
(com LUKS)
?
?
Não
?
Não
?
Sim
Funcionalidades relacionadas com performance
Loop-AES
dm-crypt +/- LUKS
TrueCrypt
VeraCrypt
ZFS
eCryptfs
EncFs
gocryptfs
fscrypt
Suporte a multithreading
?
Sim
[4]
Sim
Sim
Sim
?
?
Sim
Sim
Encriptação com suporte no hardware
Sim
Sim
Sim
Sim
Sim
Sim
[5]
Sim
Sim
Sim
Específico para Encriptação de dispositivo de bloco
Loop-AES
dm-crypt +/- LUKS
TrueCrypt
VeraCrypt
ZFS
Suporte para redimensionamento (manual) do dispositivo de bloco criptografado sem desmontá-lo
?
Sim
Não
Não
Sim
Específico para encriptação empilhada no sistema de arquivos
ZFS
eCryptfs
EncFs
gocryptfs
fscrypt
Suportado pelo sistemas de arquivos
ZFS
ext3, ext4, xfs (com ressalvas), jfs, nfs...
ext3, ext4, xfs (com ressalvas), jfs, nfs, cifs...
[6]
qualquer
ext4, F2FS, UBIFS
Habilidade para criptografar nomes de arquivos
Sim
zfs(8)
Sim
Sim
Sim
Sim
Habilidade para
não
criptografar nomes de arquivos
Não
Sim
Sim
Sim
[7]
Não
Manuseio otimizado de arquivos espalhados
Sim
Não
Sim
Sim
Sim
Compatibilidade & prevalência
Loop-AES
dm-crypt +/- LUKS
TrueCrypt
VeraCrypt
ZFS
eCryptfs
EncFs
gocryptfs
fscrypt
Versões suportadas do kernel Linux
2.0 ou posterior
CBC-mode desde 2.6.4, ESSIV 2.6.10, LRW 2.6.20, XTS 2.6.24
?
?
2.6.32 ou posterior (desde 0.8.3)
?
2.4 ou posterior
?
4.1 ou posterior
Dados criptografados podem ser acessados pelo Windows
?
?
Sim
Sim
Sim
OpenZFS no Windows
(
repositório
)
?
Não (precisa de poderes administrativos)
Sim (porte cppcryptfs)
Não
Dados criptografados podem ser acessados pelo Mac OS X
?
?
Sim
Sim
Sim
OpenZFS no OS X
(
repositório
)
?
Sim
[8]
Sim (em beta)
Não
Dados criptografados podem ser acessados pelo FreeBSD
?
?
Sim
(com VeraCrypt)
Sim
Sim
ZFS no FreeBSD
(nativo;
repositório
)
?
Sim
[9]
?
Não
Usado pelo
?
instalador do Debian/Ubuntu (encriptação de sistema)
Instalador do Fedora
?
?
?
?
?
?
Android, Chrome OS
Um único arquivo pode ser usado como um container (dispositivo virtual de loop-back!) mas então não estaria mais usando o sistema de arquivos (e suas funcionalidades)
Preparação
Escolhendo uma configuração
Que configuração de encriptação é apropriada para você vai depender de seus objetivos (leia
#Por que criptografar?
) e parâmetros do sistema.
Entre outras coisas, você vai precisar responder as seguintes perguntas:
Que tipo de "atacante" você quer se proteger?
Usuário casual bisbilhotando seu disco quando o sistema está desligado / foi roubado / etc.
Um profissional que pode ter acesso de leitura/escrita repetidamente antes ou depois de você usar o seu sistema
Qualquer um entre os dois
O que você quer criptografar?
Somente dados do usuário
Dados do usuário e do sistema
Somente dados sensíveis
Como swap,
/tmp
, etc. deveriam ser tratadas?
Desabilite ou monte como ramdisk
Swap criptografada como
Um arquivo swap, parte de uma encriptação total de disco
Uma partição separada
Como deveriam as partes criptografadas do disco serem abertas?
Senhas
Mesma senha de login
Diferente e específica
Keyfile
(exemplo, em um pendrive, que você mantém num local seguro ou carrega consigo)
Ambas
Quando
deveriam as partes criptografadas do disco serem abertas?
Antes do processo de inicialização
Durante o processo de inicialização
No login
Manualmente, em demanda
(depois do login)
Como múltiplos usuários deveriam ser acomodados?
De forma alguma
Usando senha (ou keyfile) compartilhada entre todos os usuários
Senhas (ou keyfile) independentes e revogáveis para a mesma parte criptografada do disco
Partes criptografadas do disco separadas para diferentes usuários
E então você pode fazer as escolhas técnicas necessárias (veja
#Métodos disponíveis
acima, e
#Como a criptografia funciona
abaixo), de acordo com:
encriptação de dispositivo de bloco vs encriptação empilhada no sistema de arquivos
gerenciamento de chaves
cifra e modo de operação
armazenamento de metadados
localização do "diretório inferior" (em caso da encriptação empilhada no sistema de arquivos)
Exemplos
Na prática, pode se tornar algo assim:
Exemplo 1
Encriptação simples dos dados do usuário (disco interno de armazenamento) com
EncFS
, usando o diretório virtual
~/Privado
no diretório home do usuário
versão criptografada dos arquivos guardados no disco em
~/.Privado
aberto em demanda com senha dedicada
Exemplo 2
Encriptação parcial do sistema no diretório home de cada usuário com
ECryptfs
aberto no login do respectivo usuário, usando a senha do login
as partições
swap
e
/tmp
são criptografadas com
Dm-crypt com LUKS
, usando uma chave descartável gerada para a sessão automaticamente
indexação/cache do conteúdo do
/home
pelo
slocate
(e programas similares) desabilitada.
Exemplo 3
Encriptação do sistema - todo o disco rígido exceto a partição
/boot
(no entanto,
/boot
pode ser criptografada e lida pelo
GRUB
) usando
Dm-crypt com LUKS
aberto durante a inicialização, usando senhas ou pendrive com keyfiles
talvez diferentes senhas/chaves por usuário - independentemente revocáveis
talvez criptografia em múltiplas unidades de armazenamento ou design de partições flexíveis com
LUKS dentro do LVM
Exemplo 4
Encriptação oculta/simples do sistema - todo o disco rígido é criptografado com
dm-crypt
inicialização com pelo USB, usando senha dedicada e pendrive com keyfile
integridade de dados checada antes de montar
partição de
/boot
no já mencionado pendrive
Exemplo 5
Encriptação de arquivo container - um arquivo com tamanho pré-alocado que serve como um container criptografado para dados do usuário
Um arquivo como
~/.volume.img
é criptografado com
Dm-crypt (Português)/Encrypting a non-root file system (Português)#Dispositivo de loop
Backup ocasional ao copiar todo o container para um host remoto
Muitas outras combinações são possíveis. Você deve escolher cuidadosamente que tipo de configuração será apropriada para seu sistema.
Escolhendo uma senha forte
Veja
Segurança#Senhas
.
Preparando o disco
Antes de criptografar o disco (ou de parte dele), considere limpá-lo primeiro. Isto consiste de sobrescrever toda a unidade de armazenamento ou partição com bytes zero ou randômicos, isto é feito por uma das seguintes razões:
Prevenir a recuperação de dados guardados anteriormente
Encriptação de disco não muda o fato de que setores são somente sobrescritos em demanda, quando o sistema de arquivos cria ou modifica os dados que estes setores guardam (veja
#Como a criptografia funciona
abaixo). Setores que o sistema de arquivos considera "atualmente não usados" não são tocados, e podem ainda conter dados remanescentes. A única forma de ter certeza que todos os dados que você previamente guardou na unidade de armazenamento não podem ser recuperados
recuperados
, é manualmente apagá-los.
Para isso não importa se são usados bytes zero ou randômicos (apesar que a limpeza com bytes zero vai ser muito mais rápida).
Prevenir a descoberta de padrões usados na unidade de armazenamento
Idealisticamente, toda a parte criptografada do disco não deve ser discernível de dados randômicos uniformes. Desta maneira, nenhuma pessoa não autorizada pode saber quais e quantos setores contém dados criptografados - que pode ser um objetivo desejável por si só (como parte de verdadeira confiabilidade), e também serve como uma barreira adicional contra os atacantes que tentarem quebrar a sua encriptação.
Para satisfazer esse objetivo, limpar o disco com bytes randômicos de alta qualidade é crucial.
O segundo objetivo somente faz sentido em combinação com encriptação de dispositivo de bloco, no caso da encriptação empilhada no sistema de arquivos, os dados criptografados podem ser facilmente localizados (em forma de arquivos distintos no sistema de arquivos). Note também que nesse caso mesmo se você deseja criptografar um diretório específico, você vai ter que apagar toda a partição se quiser eliminar o que foi previamente guardado naquele particular diretório (devido a
fragmentação de disco
). Se tem outros diretórios na mesma partição, você vai ter de fazer o backup deles e depois movê-los de volta.
Uma vez que você decidiu que tipo de limpeza de disco deseja, veja o artigo
Securely wipe disk
para instruções técnicas.
Dica
Na decisão de que método usar para apagar o disco com segurança, se lembre que isto vai ser feito somente uma vez enquanto a unidade de armazenamento estiver criptografada.
Como a criptografia funciona
Esta seção tem como objetivo uma introdução de alto nível sobre conceitos e processos que são o coração da encriptação de disco normal.
Não vão ter detalhes matemáticos ou técnicos (consulte materiais apropriados para isso), mas deve prover a um administrador de sistemas um entendimento básico de como diferentes escolhas de configuração (especialmente sobre gerenciamento de chaves) podem afetar a usabilidade e segurança.
Princípio básico
Para propostas da encriptação de disco, cada dispositivo de bloco (ou arquivo individual no caso de encriptação empilhada no sistema de arquivos) é dividido em
setores
de igual comprimento, por exemplo 512 bytes (4,096 bits). A encriptação/desencriptação então é feita por setores, então o nº setor do dispositivo de bloco ou arquivo no disco vai guardar a versão criptografada do nº setor dos dados originais.
Quando o sistema operacional ou um programa pede um certo fragmento de dados do dispositivo de bloco/arquivo, todos os setores (ou setor) que possuem os dados serão lidos do disco, descriptografados, e temporariamente guardados na memória:
╔═══════╗
  setor 1  ║"???.."║
           ╠═══════╣         ╭┈┈┈┈┈╮
  setor 2  ║"???.."║         ┊chave┊
           ╠═══════╣         ╰┈┈┬┈┈╯
           :       :            │
           ╠═══════╣            ▼                 ┣┉┉┉┉┉┉┉┫
  setor n  ║"???.."║━━━━━━━(decifragem)━━━━━━━━━▶┋"abc.."┋ setor n
           ╠═══════╣                              ┣┉┉┉┉┉┉┉┫
           :       :
           ╚═══════╝

           arquivo ou dispositivo de               dados não criptografados
    	   bloco criptografado no disco            na RAM
Similarmente, em cada operação de escrita, todos os setores que são afetados devem ser criptografados completamente de novo (enquanto o resto dos setores não são modificados).
Para ser possível de/criptografar dados, o sistema de encriptação de disco precisa saber o segredo único associado ("chave"). Quando o dispositivo de bloco ou diretório em questão é montado, sua chave correspondente (a partir de agora chamada de "chave mestre") deve ser fornecida.
A entropia da chave é de extrema importância para a segurança da encriptação. Uma string de bytes randomicamente gerada de certo comprimento, por exemplo 32 bytes (256 bits), tem propriedades desejadas mas não é praticável se lembrar e colocá-la manualmente durante a montagem.
Por este motivo, duas técnicas são usadas como auxiliares. A primeira é o programa de criptografia aumentar a propriedade de entropia da chave mestre, normalmente envolvendo uma senha separada amigável para humanos. Para diferentes tipos de criptografia a
#Tabela de comparação
lista as respectivas funcionalidades. O segundo método é criar uma keyfile com grande entropia e guardá-la num dispositivo separado do disco a ser criptografado.
Veja também
Wikipedia:Authenticated encryption
.
Chaves, keyfiles e senhas
Os exemplos a seguir são sobre como guardar e assegurar criptograficamente uma chave mestre com uma keyfile:
Guardada em uma keyfile de texto puro
Simplesmente guardar a chave mestre num arquivo (em forma legível) é a opção mais simples. O arquivo - chamado de "keyfile" - pode ser colocada em um pendrive que você pode manter num local seguro e somente conectá-lo no computador quando você quer montar as partes criptografadas do disco (exemplo, durante a inicialização ou login).
Guardada e protegida por senha em uma keyfile ou no próprio disco
A chave mestre (e assim os dados criptografados) pode ser protegida com uma senha secreta, que você vai se lembrar e digitar toda vez que quiser montar o dispositivo de bloco ou diretório. Veja
#Metadados criptográficos
abaixo para detalhes.
Randômicamente gerada para cada sessão
Em alguns casos, exemplo swap criptografada ou uma partição
/tmp
, não é necessário manter uma chave mestre persistente. Uma nova chave descartável pode ser gerada para cada sessão, sem precisar de qualquer interação do usuário. Isto significa que uma vez desmontada, todos os arquivos escritos para a partição em questão nunca podem ser descriptografados novamente por
qualquer um
- que nesse uso é perfeitamente aceitável.
Metadados criptográficos
Normalmente, técnicas de encriptação usam funções criptográficas para aumentar a segurança da chave mestre. Na montagem do dispositivo criptografado, a senha ou keyfile é passada por estas e somente o resultado pode abrir a chave mestre para descriptografar os dados.
Uma configuração comum é aplicar a chamada "key stretching"(alongamento de chave) para a senha (com a "key derivation function"), e usar a chave resultante para descriptografar a chave mestre (que previamente foi guardada em forma criptografada):
╭┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈╮                                ╭┈┈┈┈┈┈┈┈┈┈┈╮
 ┊senha de montagem ┊━━━━━⎛função de derivação ⎞━━━▶┊   chave   ┊
 ╰┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈╯ ,───⎝ de chave           ⎠     ╰┈┈┈┈┈┬┈┈┈┈┈╯
 ╭──────╮            ╱                                     │
 │ salt │───────────´                                      │
 ╰──────╯                                                  │
 ╭────────────────────────────╮                            ▼         ╭┈┈┈┈┈┈┈┈┈┈┈┈┈┈╮
 │ chave mestre criptografada │━━━━━━━━━━━━━(descriptografar)━━━━━━▶┊ chave mestre ┊
 ╰────────────────────────────╯                                      ╰┈┈┈┈┈┈┈┈┈┈┈┈┈┈╯
A
função de derivação de chave
("key derivation function", exemplo: PBKDF2 ou scrypt) é deliberamente lenta (aplica várias iterações de uma função hash, por exemplo: 1000 iterações do HMAC-SHA-512), fazendo ataques de força bruta não viáveis. Para o uso normal de um usuário autorizado, vai ser somente necessário calculá-la uma vez por sessão, então uma pequena espera não é um problema.
Também é utilizado o aglomerado de dados, chamado "
salt
", como um argumento - este é gerado randômicamente uma vez durante a configuração da encriptação do disco e guardada (sem ser criptografada) como parte dos metadados criptográficos. Devido a ter diferentes valores por configuração, não é viável para atacantes fazer uso de tabelas pré-computadas para a função de derivação de chave.
A
chave mestre criptografada
("encrypted master key") pode ser guardada no disco junto com os dados criptografados. Desta maneira, a confiabilidade dos dados criptografados depende da senha secreta.
Segurança adicional pode ser alcançada ao guardar a chave mestre criptografada em uma keyfile em, por exemplo, um pendrive. Isto provê
autentificação de dois fatores
: Para acessar dados criptografados é necessário algo que somente você
sabe
(a senha), e algo que somente você
tem
(a keyfile).
Outra maneira de conseguir autentificação de dois fatores é aumentar o esquema de recuperação de chave acima para "combinar" matematicamente a senha com os bytes lidos dos dados de um ou mais arquivos externos (localizado em um pendrive ou similar), antes de passá-lo para a função de derivação de chave. Os arquivos em questão podem ser qualquer coisa, exemplo, imagens JPEG normais, que podem ser benéficas para
#Negação plausível
. Apesar deles ainda serem chamados de "keyfiles" neste contexto.
Depois de derivada, a chave mestre é guardada com segurança na memória (exemplo, no chaveiro do kernel), enquanto o dispositivo de bloco ou diretório criptografado é montado.
Apesar que normalmente não é usada para des-/criptografar os dados do disco diretamente.
Por exemplo, no caso da encriptação empilhada no sistema de arquivos, cada arquivo pode ser automaticamente atribuído para sua própria chave de encriptação. Quando o arquivo é lido/modificado, esta primeiro precisa ser descriptografada usando a chave mestre, antes que esta possa ser usada para de-/criptografar o conteúdo do arquivo:
╭┈┈┈┈┈┈┈┈┈┈┈┈╮
                                     ┊chave mestre┊
   arquivo no disco:                 ╰┈┈┈┈┈┬┈┈┈┈┈┈╯
  ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐              │
  ╎╭───────────────────────╮╎              ▼            ╭┈┈┈┈┈┈┈┈┈┈╮
  ╎│ chave do arquivo      │━━━━━━(descriptografar)━━━▶┊ chave do ┊
  ╎│ criptografada         │╎                           ┊ arquivo  ┊
  ╎╰───────────────────────╯╎                           ╰┈┈┈┈┬┈┈┈┈┈╯
  ╎┌───────────────────────┐╎                                ▼            ┌┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┐
  ╎│ conteúdo criptografado│◀━━━━━━━━━━━━━━━━(des-/criptografar)━━━━━━━▶┊ conteúdo légivel ┊
  ╎│ do arquivo            │╎                                             ┊ do arquivo       ┊
  ╎└───────────────────────┘╎                                             └┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┘
  └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘
De maneira similar, uma chave separada (exemplo, uma por diretório) pode ser usada para a encriptação de nomes de arquivos no caso de encriptação empilhada no sistema de arquivos.
No caso da encriptação do dispositivo de bloco uma chave mestre é usada por dispositivo e, consequentemente, todos os dados. Alguns métodos oferecem funcionalidades para atribuir múltiplas senhas/keyfiles para o mesmo dispositivo e outros não. Alguns usam funções mencionadas acima para aumentar a segurança da chave mestre e outros dão todo o controle da segurança da chave para o usuário. Dois exemplos são explicados pelos parâmetros criptográficos usados pelo
dm-crypt
nos modos plain ou LUKS.
Ao comparar os parâmetros usados por ambos os modos, é possível observar que o modo plain tem parâmetros relacionados a localização da keyfile (exemplo,
--keyfile-size
,
--keyfile-offset
). O LUKS não precisa disso, porquê cada dispositivo de bloco contém um cabeçalho com os metadados criptográficos no início. O cabeçalho inclui a cifra usada, a chave mestre criptografada e parâmetros necessários para sua função de derivação de chave. Os últimos parâmetros resultam de opções usadas durante a encriptação inicial da chave mestre (exemplo,
--iter-time
,
--use-random
).
Para as vantagens e desvantagens, veja a
#Tabela de comparação
ou navegue páginas específicas.
Veja também:
Wikipedia:Passphrase
Wikipedia:Key (cryptography)
Wikipedia:Key management
Wikipedia:Key derivation function
Cifras e modos de operação
O algoritmo usado para traduzir pedaços de dados criptografados e os não (chamados de "ciphertext" e "plaintext", respectivamente), que correspondem entre si de acordo com dada chave de encriptação, é chamado de "
cifra
".
Encriptação de disco emprega "cifras de bloco", que operam em um tamanho definido de bloco de dados, exemplo 16 bytes (128 bits). No tempo que este artigo foi escrito, os predominentemente usados são:
tamanho do bloco
tamanho da chave
comentário
AES
128 bits
128, 192 ou 256 bits
aprovado pela NSA por porteger informações do governo do EUA classificadas como "SECRET" e "TOP SECRET" (quando o tamanho de chave usado foi 192 e 256 bits)
Blowfish
64 bits
32–448 bits
uma das primeiras cifras seguras sem patente que se tornou publicamente disponível, muito bem estabelecida no Linux
Twofish
128 bits
128, 192 ou 256 bits
desenvolvida como sucessora do Blowfish, mas não conseguiu tanta popularidade
Serpent
128 bits
128, 192 ou 256 bits
Considerado o finalista mais seguro de cinco competições do AES
[10]
[11]
[12]
.
Criptografar (ou descriptografar) um setor (
veja acima
) é alcançado ao dividi-lo em pequenos blocos de tamanho igual ao bloco da cifra, e seguindo um conjunto de regras (chamado de "
modo de operação
") de como consecutivamente aplicar a cifra aos blocos individuais.
Simplesmente aplicar isto para cada bloco separadamente sem modificações (apelidado como modo "
electronic codebook (ECB)
") seria inseguro, se os mesmos 16 bytes de plaintext sempre produzem os mesmos 16 bytes de ciphertext, um atacante poderia facilmente reconhecer os padrões guardados no disco.
O modo de operação mais básico (e comum) usado em prática é o "
cipher-block chaining (CBC)
". Antes da encriptação de um setor com este modo, cada bloco de dados plaintext é combinado em uma forma matemática com o ciphertext do bloco anterior. Para o primeiro bloco, já que este não tem um ciphertext anterior, um especial bloco de dados pré-gerado guardado junto com os metadados criptográficos, e chamado de "
initialization vector (IV)
"(vetor de inicialização), é usado:
╭──────────────╮
                                   │vetor de      │
                                   │inicialização │
                                   ╰────────┬─────╯
           ╭  ╠══════════╣        ╭─chave   │      ┣┉┉┉┉┉┉┉┉┉┉┫        
           │  ║          ║        ▼         ▼      ┋          ┋         . COMEÇO
           ┴  ║"????????"║◀━━━━(cifra)━━━━(+)━━━━━┋"Hello, W"┋ bloco  ╱╰────┐
   setor n do ║          ║                         ┋          ┋ 1      ╲╭────┘
   arquivo ou ║          ║──────────────────╮      ┋          ┋         ' 
   dispositivo╟──────────╢        ╭─chave   │      ┠┈┈┈┈┈┈┈┈┈┈┨
           ┬  ║          ║        ▼         ▼      ┋          ┋
           │  ║"????????"║◀━━━━(cifra)━━━━(+)━━━━━┋"orld !!!"┋ bloco
           │  ║          ║                         ┋          ┋ 2
           │  ║          ║──────────────────╮      ┋          ┋
           │  ╟──────────╢                  │      ┠┈┈┈┈┈┈┈┈┈┈┨
           │  ║          ║                  ▼      ┋          ┋
           :  :   ...    :        ...      ...     :   ...    : ...

              texto cifrado                         texto puro
                no disco                              na RAM
Para descriptografar o procedimento é o revertido analogamente.
Uma coisa legal de se notar é a geração do único vetor de inicialização para cada setor. A escolha mais simples é calcular isto em um jeito preditivo de um valor prontamente disponível como o número do setor. No entanto, isso permite que um atacante com repetidos acessos ao sistema faça o chamado
watermarking attack
. Para prevenir isto, um método chamado "Encrypted salt-sector initialization vector (
ESSIV
)" pode ser usado para gerar os vetores de inicialização de uma maneira que o faz parecer completamente randômica para um atacante em potencial.
Existem outros, mais complicados, modos de operação disponíveis para a encriptação de disco, que já oferecem nativamente segurança contra tais ataques (e não precisam do ESSIV).
Alguns também podem garantir autentificação dos dados criptografados (exemplo, confirmar que não foi modificado/corrompido por alguém que não tem acesso a chave).
Veja também:
Wikipedia:Disk encryption theory
Wikipedia:Block cipher
Wikipedia:Block cipher modes of operation
Negação plausível
Veja
Wikipedia:Plausible deniability
.
Backup para cenários de criptografia de disco
Faça
backup
dos dados do usuário para se proteger contra a perda destes. Normalmente, o backup deve ser criptografado também.
Encriptação do dispositivo de bloco
Existem múltiplas opções, você pode fazer backup da encriptação do dispositivo de bloco onde o container criptografado reside como uma imagem, exemplo
/dev/sd
x
, você pode copiar o sistema de arquivos dentro do container, exemplo
/dev/mapper/
nome_dm
, ou fazer backup dos arquivos, com
rsync
por exemplo. As seguintes seções listam as vantagens e desvantagens de cada opção.
Backup da encriptação do dispositivo de bloco
Um backup do dispositivo de bloco do disco é:
criptografado com o mesmo nível de segurança do original
contém seu cabeçalho do LUKS
do mesmo tamanho do seu dispositivo de bloco do disco
não permite, de forma fácil, estratégias de backup como backup incremental, compactação, ou eliminação de dados duplicados
facilmente restaurado para um novo disco, e também para o container criptografado
Backup do sistema de arquivos ou arquivos
Um backup do sistema de arquivos ou arquivos:
não
é criptografado do jeito que está
necessita de esforço adicional, deve ser criptografado antes de ser transferido pela rede, ou salvo no disco
não é necessariamente criptografado com o mesmo nível de segurança do original
não contém seu cabeçalho do LUKS
seu tamanho máximo é o espaço usado no sistema de arquivos, por exemplo, veja
partclone
permite estratégias avançadas como backup incremental, compactação ou eliminação de dados duplicados
precisa de restauração manual do container criptografado para um novo disco, por exemplo ao restaurar o backup do cabeçalho do LUKS
Backup do cabeçalho do LUKS
Se está usando LUKS é possível fazer
backup do seu cabeçalho
: faz sentido periodicamente checar e sincronizá-lo, especialmente se chaves foram removidas.
Se no entanto, você tem um backup dos dados, e quer restaurá-los, você pode criar novamente a partição criptografada com LUKS e então restaurar, já que fazer backup do cabeçalho do LUKS é menos importante do que o dos dados.