Entao existem prestadores e outros prestadores desse servico, e a seguranca dos dados durante o processo de backup ‘e um fator muito discutido. Uma busquinha no google por online backup apresenta um milhao de empresas que oferecem o servico.

Em ambiente Trusted e’ possivel garantir que apenas um, e tao somente um processo, seja este do root ou nao, acesse uma determinada particao de disco. E se esse mesmo processo desmontar essa particao quando terminar o trabalho? Pois bem, esse eh o ambiente ideal.

No Brasil a unica empresa que eu sei que oferece servico desse tipo eh a FBSD Brasil, eles ate colocam uma explicacao simplista de como isso acontece aqui:

http://www.freebsdbrasil.com.br/home.php?area=18&conteudo=41&sub=75

Na verdade nem eh tao simplista, um usuario final nao entenderia nada.

Mas entao existe sim, a possibilidade de ter um device criptografado montado e que ainda assim garanta a seguranca do acesso a esses dados, restringindo ate mesmo o root. Logico que se o root puder trocar de kernel ou carregar modulos, a coisa muda de figura. Mas num ambiente seguro assumimos que isso tambem seja dificultado. No FreeBSD o modulo MAC BSD Partition e o bsd_extended permitem esse nivel de controle. No Mac OS X Leopard tambem ha esse tipo de controle. Igualmente ha no Solaris e no HP-UX. Portanto sequer eh algo novo ou exclusive de sistema X, Y ou Z.

Por exemplo, imaginemos que o recem roubado laptop da Petrobras contendo informacoes privilegiadas sobre a camada de pre-sal na bacia de Santos tenha esses dados em uma particao criptografada, e, apos um Cold Boot a memoria seja fisicamente removida e colocada em um outro device que nao tenha essa sua BIOS modificada, ou melhor que sequer tenha uma BIOS e a BIOS seja um linux do tipo busybox que controla e faz o memory dump necessario.

Alem do que como eh que se zera qualquer tipo de memoria? Uma coisa eh free(); outra coisa ‘e remover os dados de uma memoria. Impossivel. Teria que ter toda a regiao de memoria regravada. Ja pensou se uma BIOS fizesse isso? Se o usuario ja da ESC pq se irrita com a contagem de memoria, imagina um processo parecido com o mais basico do “memtest.org” pra garantir que a memoria esteja toda repleta de dados inuteis em cada POST?

Enfim, nao acho que a solucao seja por ai. A falha eh na implementacao de software, e eh a implementacao que deve ser melhorada.

Mesmo porque Cold Reboot ‘e so o foco do Research publicado. Nos sabemos que fazer dump completo da memoria nao eh um problema que requer um Cold Reboot e um sistema especial como o paper descreve.

Se alguma pessoa, quem quer q seja, sentar na frente do meu laptop agora, e eu esquecer de dar um lock, ou deslogar, ou ele simplesmente conhecer a senha de root conseguira fazer um memory dump.

Lembro ate de uma historia pra ilustrar isso, quando foi lancado o Battletoads, devido a dificuldade do jogo era previsivel que tentassem modificar o comportamento do game, e entao criaram uma chave de seguranca pra evitar a alteracao desses dados em memoria. Porem, a ideia da chave foi ma implementada e logo o Gamegenie (wrapper pra mod de games direto no console) conseguia modificar esses comportamentos e por exemplo colocar vida infinita pros sapos, permitir fases mais dificiceis como as do fundo do mar ficar invenciveis e a corrido dos jet ski flutuante ser em camera lenta e com mapa.
Ai a RARE games soltou uma segunda leva do mesmo jogo que fazia derivacao de funcoes pra codificar a area de memoria onde essas informacoes ficam. A derivacao por chave garantia que a cada nova inicializacao uma mesma chave geraria uma segunda chave com base em uma terceira chave aleatoria. Ou seja, uma constante e uma aleatoriedade geraria uma outra chave, imprevisivel. O Game Genie passou a nao funcionar mais nos cartuchos Battletoads mais novos, depois disso, e um Cold Boot permitia acesso a chave – a constante – e tambem a chave aleatoria bem como a chave resultante das duas. Porem, na proxima inicializacao do game a chave aleatoria seria outra, portanto resultando em uma terceira chave – a efetiva – tambem imprevisivel, ainda que a chave constante fosse sempre a mesma.

Essa historinha ‘e so’ pra ilustrar que a seguranca esta diretamente relacionada a capacidade, o prazer e o empenho de quem faz um sistema.

Agora voltando ao Topico, essa abordagem no Battle toads ‘e equivalente a especificada na Sessao 5 da RFC 2898 (Funcoes de Derivacao de Chave).

No FreeBSD o GELI criptografa os dados dessa maneira, permitindo que o usuario entre com uma passphrase ou um token, ou que ainda leia a chave de um arquivo. Seja como for essa nao e a chave de criptografia utilizada nas operacoes, a chave utilizada ‘e oriunda de um processo que obtem 2 outras chaves, uma com um algoritimo proprio e aleatoriedade baseada no /dev/random e outra com um algoritimo de derivacao indicado na RFC 2898. Portanto um padrao de fato (RFC) e algo exclusivo da implementacao, 2 chaves imprevisiveis, uma constante, resultando em uma quarta chave que ‘e de fato que vai codificar o acesso aos dados. Ainda que todas as 4 chaves sejam copiadas da memoria so 1 eh constante – a do input do usuario – e as outras nunca mais serao utilizadas. A nova inicializacao do device sera com chaves totalmente distintas.

Mas no FreeBSD existe outra implementacao, o GBDE. Dependendo da forma como o GBDE Device ‘e criado, alem de acontecer um processo similar ao do GELI, a chave de fato (aque efetivamente realiza a criptografia) alem de ser gerada de uma combinacao de chave constante com chaves derivadas, ainda requer que periodicamente (por padrao a cada 300 segundos) a chave de fato seja regerada.

Ou seja, escolha sua implementacao FreeBSD, seja qual for nao ‘e sucetivel a essa falha. Agora so me surpreende (negativamente) no Mac OS X nao ter implementacoes baseadas no GELI ou GBDE.

Ah, detalhe, no caso do GELI se disponivel, a chave e’ derivada do hardware de crypto (HIFN da Soekris por exemplo).

O interessante ‘e que o artigo so menciona as implementacoes vulneraveis. Nao disserta sobre as nao vulneraveis e os motivos.

BIOS = macho. Sistema Básico de Entrada/Saída.

Porque encriptar um HD de um servidor? Só o deixaria lento. Se o invasor conseguir acesso remoto ele não vai nem perceber a criptografia porque já vai estar acessando um disco “mountado”. A aplicação da criptografia em disco é mais comum para notebook.